Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Meson build with Werror #448

Merged
merged 31 commits into from
Sep 5, 2024
Merged

Conversation

WillAyd
Copy link
Contributor

@WillAyd WillAyd commented Apr 30, 2024

This should be a relatively easy way to enforce -Werror in CI; moved the Meson build from a scheduled job to be part of the normal CI runs.

Looks like there are still a few more upstream issues to be fixed before this is ready. Just posting for visibility

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes are not permanent - just setting them up to see what we need for a clean build of Arrow.

@@ -141,9 +141,6 @@ TEST(BufferTest, BufferTestFill) {
}

ArrowBufferReset(&buffer);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These were removed because they won't compile with -Warray-bounds:

In file included from /usr/include/string.h:535,
                 from /usr/include/c++/11/cstring:42,
                 from ../src/nanoarrow/buffer_test.cc:19:
In function ‘void* memcpy(void*, const void*, size_t)’,
    inlined from ‘void ArrowBufferAppendUnsafe(ArrowBuffer*, const void*, int64_t)’ at ../src/nanoarrow/buffer_inline.h:134:11,
    inlined from ‘ArrowErrorCode ArrowBufferAppend(ArrowBuffer*, const void*, int64_t)’ at ../src/nanoarrow/buffer_inline.h:143:26,
    inlined from ‘ArrowErrorCode ArrowBufferAppend(ArrowBuffer*, const void*, int64_t)’ at ../src/nanoarrow/buffer_inline.h:139:30,
    inlined from ‘virtual void BufferTest_BufferTestError_Test::TestBody()’ at ../src/nanoarrow/buffer_test.cc:174:3:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ forming offset [48, 9223372036854775806] is out of the bounds [0, 48] of object ‘buffer’ with type ‘ArrowBuffer’ [-Werror=array-bounds]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/nanoarrow/buffer_test.cc: In member function ‘virtual void BufferTest_BufferTestError_Test::TestBody()’:
../src/nanoarrow/buffer_test.cc:170:22: note: ‘buffer’ declared here
  170 |   struct ArrowBuffer buffer;
      |                      ^~~~~~
cc1plus: all warnings being treated as errors

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would changing them to ArrowBufferReserve() work? (Also fine to remove if neither will compile...testing ENOMEM is hard and we mostly don't test it other places, too).

Copy link
Contributor Author

@WillAyd WillAyd May 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The BufferTestError test checks for ENOMEM using ArrowBufferResize - do you think it would be better to add the ArrowBufferReserve test there for consistency or do you want to keep within this test?

@codecov-commenter
Copy link

codecov-commenter commented May 15, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.21%. Comparing base (9f75836) to head (f149708).
Report is 11 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #448      +/-   ##
==========================================
+ Coverage   89.18%   89.21%   +0.02%     
==========================================
  Files          90       90              
  Lines       16102    16230     +128     
==========================================
+ Hits        14361    14479     +118     
- Misses       1741     1751      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@WillAyd WillAyd marked this pull request as ready for review June 18, 2024 21:51
meson.build Outdated
@@ -30,7 +30,7 @@ project(
)

if meson.get_compiler('cpp').get_id() == 'gcc' or meson.get_compiler('cpp').get_id() == 'clang'
add_project_arguments(['-fvisibility=hidden'], language: 'cpp')
add_project_arguments(['-fvisibility=hidden', '-Wno-unused-parameter'], language: 'cpp')
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these aren't done upstream in Arrow kind of hard to keep things synced; probably just easiest to ignore until we potentially drop the Arrow testing dependency

Comment on lines 48 to 51
curl -L "https://www.apache.org/dyn/closer.lua?action=download&filename=arrow/arrow-${ARROW_CPP_VERSION}/apache-arrow-${ARROW_CPP_VERSION}.tar.gz" | \
curl -L "https://github.com/apache/arrow/archive/refs/heads/main.tar.gz" | \
tar -zxf -
mkdir build && cd build
cmake ../apache-arrow-${ARROW_CPP_VERSION}/cpp \
cmake ../arrow-main/cpp \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the Arrow 17.0.0 release include the upstream changes required to make this work? We can't merge this particular change but we can update the version we use in CI once released.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think so. I fixed a few but they keep popping up, especially after having added metal / ipc support. Can keep trying but I think unless Arrow comprehensively wanted to fix these warnings its going to be hard downstream to keep this clean

An alternate solution may be to treat Arrow as a system include in the build systems so that it doesn't show any warnings from that library. That might allow us to at least keep this clean within nanoarrow

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll pipe the Arrow C++ removal through in the next few weeks. We've let that dependency complicate quite a lot of things and I've mentioned its hypothetical removal quite a lot of times.

Copy link
Contributor Author

@WillAyd WillAyd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going to require #595 going in first, but afterwards I think this might be ready

@@ -161,7 +167,8 @@ if get_option('tests')
# Similarly code coverage has a built in option users should use instead
# https://mesonbuild.com/Unit-tests.html#coverage

arrow_dep = dependency('arrow')
# The system include suppresses compilation warnings from Arrow
arrow_dep = dependency('arrow', include_type: 'system')
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than chasing down the Arrow failures, I figured we can just ignore them

@@ -35,6 +35,12 @@ project(
# add_project_arguments(['-fvisibility=hidden'], language: 'cpp')
# endif

cpp = meson.get_compiler('cpp')
add_project_arguments(
cpp.get_supported_arguments(['-Wno-misleading-indentation']),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This warning was generated by the flatcc_generated header. There are a ton of these.

Perhaps there is a way to have it fixed on generation, but for now figure fine to ignore

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This had been fixed (#420) but we revendored flatcc and regenerated the header. I think ignoring for now is fine (although I'd like to redo the fix at some point since these errors show up when compiling Python and obscure other actual warnings!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know which version of flatcc was generated? Meson still uses flatcc as a subproject which is 0.6.1. However, the generated flatcc_generated.h file in the source tree uses some symbols that don't appear in that release.

Should set the meson subproject up to use the same version as was vendored for CMake I think

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so! We use a git hash right now because @bkietz found a bug/suboptimal behaviour of every flatbuffer implementation except flatcc that forced a change in flatcc. I think using the vendored version is safer but you could probably also use the git hash.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ended up changing the subproject to use the same git hash. Can relook at the design in a separate PR, but the Meson subproject approach does generally make things much simpler from a build configuration standpoint

@@ -98,9 +98,11 @@ TEST(ArrayTest, ArrayTestAllocateChildren) {
ArrowArrayRelease(&array);

ASSERT_EQ(ArrowArrayInitFromType(&array, NANOARROW_TYPE_STRUCT), NANOARROW_OK);
#if !defined(__SANITIZE_ADDRESS__)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did also explicitly add in this code that takes out blocks which are known to be flagged by the sanitizers. This is a bit of "extra credit" but I think generally safer than ignoring a broad class of potential errors.

If we didn't want to use these macros I'm happy to revert. Otherwise, we could look at a suppression file instead of changes to the code:

https://clang.llvm.org/docs/AddressSanitizer.html#issue-suppression

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is OK. We should really have a better system for testing out-of-memory anyway (but that is a not-today battle!)

@paleolimbot paleolimbot merged commit 75ef830 into apache:main Sep 5, 2024
35 checks passed
@WillAyd WillAyd deleted the meson-ci-build branch September 5, 2024 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants