-
Notifications
You must be signed in to change notification settings - Fork 40
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
Conversation
There was a problem hiding this comment.
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.
src/nanoarrow/buffer_test.cc
Outdated
@@ -141,9 +141,6 @@ TEST(BufferTest, BufferTestFill) { | |||
} | |||
|
|||
ArrowBufferReset(&buffer); | |||
|
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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 ReportAll modified and coverable lines are covered by tests ✅
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. |
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') |
There was a problem hiding this comment.
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
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 \ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
20a76be
to
0dfa1e0
Compare
There was a problem hiding this 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') |
There was a problem hiding this comment.
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']), |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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__) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!)
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