-
Notifications
You must be signed in to change notification settings - Fork 37.7k
build: make --enable-werror just -Werror #23149
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
build: make --enable-werror just -Werror #23149
Conversation
No longer special case a set of warnings, to make up our own -Werror, just use -Werror outright. This shouldn't really have any effect on existing builders, who were already using --enable-werror, and is more inline with what they would expect --enable-werror to be, which is erroring on any/all warnings. We keep -Wno-error=return-type because we know that is broken when using mingw-w64. It should only be applied when cross-compiling for Windows. Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
I think the reason for having a closed, well-defined set of warnings for Werror is that, say, gcc may introduce a (possibily silly) new warning in a new version and we don't want to get "build error" reports for that. This makes every singly warning into something we need to fix. It's the general problem with Werror of course. |
I agree, and argued somewhat against a similar change to this in #20544 with similar reasoning, especially since there seemed to be misunderstanding around the fact that repeating warning flags for However, at the same time, I think what we are currently doing is somewhat unclear. What warrants being added to I think the risk of disruption in the CI from newly introduced compiler warnings is low, not only due to us having plenty of lead time to fix them if they are legitimate, but also because I think the likelihood of Clang or GCC introducing some horrible new warning spew is also fairly low, given the number of projects that build with |
I think people will complain even when the warning doesn't result in an error. So there is always some action we need to take. Whether that is a code fix, a |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Of course people will complain, but you could want to |
Right, it's much less urgent if it doesn't break the build. I didn't really mean that the complaining is the probem, but the fact there is a build error. |
Guix build: bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
57bbb9c3cd2f9a8c236220c7cafe247c9ae23061d53ece6ce276bb560f96bf0d guix-build-38fd709fa5b7/output/aarch64-linux-gnu/SHA256SUMS.part
02764ffcd00c714594b2a1fc76433314d2c4ef09a213dc588548ff855335aeb7 guix-build-38fd709fa5b7/output/aarch64-linux-gnu/bitcoin-38fd709fa5b7-aarch64-linux-gnu-debug.tar.gz
d25df1401b6c2542ebd1396203d87936b515f949b22be57075be297d2a66e1ad guix-build-38fd709fa5b7/output/aarch64-linux-gnu/bitcoin-38fd709fa5b7-aarch64-linux-gnu.tar.gz
198f72e906ab40091bae6792b4a087ef39ea6b2289aa1565c56a5c91f0993030 guix-build-38fd709fa5b7/output/arm-linux-gnueabihf/SHA256SUMS.part
788da825b9ea310bc1f21d7078b07d283166c519ec078765bbb28f0964c66223 guix-build-38fd709fa5b7/output/arm-linux-gnueabihf/bitcoin-38fd709fa5b7-arm-linux-gnueabihf-debug.tar.gz
cb8500702faa05378afd1c90419312926bb89f77bc12e5080dd688001065d490 guix-build-38fd709fa5b7/output/arm-linux-gnueabihf/bitcoin-38fd709fa5b7-arm-linux-gnueabihf.tar.gz
42996d23fbd9860bcd5d9531568be2be0253d085ac88e6e200be1c2b7b9226a6 guix-build-38fd709fa5b7/output/dist-archive/bitcoin-38fd709fa5b7.tar.gz
9a4e4e5648c8a882297ace93ba8ae7e7e8a12c12ebf19e6d109d57dce9e5d5c7 guix-build-38fd709fa5b7/output/powerpc64-linux-gnu/SHA256SUMS.part
102c4776f27a166a608026cbbbc4130c64fa0dd59dbbfe77c4efc51290b396a4 guix-build-38fd709fa5b7/output/powerpc64-linux-gnu/bitcoin-38fd709fa5b7-powerpc64-linux-gnu-debug.tar.gz
75033b1f6cf42428b493753e20e2a9b1704930be78b12ebf189253ffbfac6d68 guix-build-38fd709fa5b7/output/powerpc64-linux-gnu/bitcoin-38fd709fa5b7-powerpc64-linux-gnu.tar.gz
7a40cda7bf0ecbb534657236dcb9c566f39cb707b47d4dc490b30142688a6521 guix-build-38fd709fa5b7/output/powerpc64le-linux-gnu/SHA256SUMS.part
238a21da145afb5219687c0168c8fa109210a7644a36c1b695add5f6752b60ca guix-build-38fd709fa5b7/output/powerpc64le-linux-gnu/bitcoin-38fd709fa5b7-powerpc64le-linux-gnu-debug.tar.gz
0eb85e09d2e72aa2708ffc7653ec7880d6e9b66a6478d43694b57df4bbbe2ebf guix-build-38fd709fa5b7/output/powerpc64le-linux-gnu/bitcoin-38fd709fa5b7-powerpc64le-linux-gnu.tar.gz
464c41eebccabe01f8eee62da27f4482b79b080ee4f99d14ddb16e57293aea87 guix-build-38fd709fa5b7/output/riscv64-linux-gnu/SHA256SUMS.part
9111778ab8a80a68ef6ecd765ed3508bba7914c1dd526efbfe301722e024c61e guix-build-38fd709fa5b7/output/riscv64-linux-gnu/bitcoin-38fd709fa5b7-riscv64-linux-gnu-debug.tar.gz
6e47d9f8228beff0f6ebbcef4efed4a4b941f1f39b1668e8d32adce1a291a067 guix-build-38fd709fa5b7/output/riscv64-linux-gnu/bitcoin-38fd709fa5b7-riscv64-linux-gnu.tar.gz
fa2198463145e47f4f49069beedd852c134fefb485667a015c5a3920726e4f2b guix-build-38fd709fa5b7/output/x86_64-apple-darwin19/SHA256SUMS.part
29cec31f43dfe883ac03ff4d45661580248c16227414b5dad09172edccec1792 guix-build-38fd709fa5b7/output/x86_64-apple-darwin19/bitcoin-38fd709fa5b7-osx-unsigned.dmg
e6bd9fb4e180d9ce90e37e3a07b079336c370bbb98bf6a3beae87b1055de8819 guix-build-38fd709fa5b7/output/x86_64-apple-darwin19/bitcoin-38fd709fa5b7-osx-unsigned.tar.gz
8c4f8aa7e3dde5acd9611c4d627c397ff885196b8e7b6467a57d0de9a8136ca7 guix-build-38fd709fa5b7/output/x86_64-apple-darwin19/bitcoin-38fd709fa5b7-osx64.tar.gz
d8b0678c38a0ba16c23ef69bad7fbdce3d0443e41a10f900cc78d5276c9535b3 guix-build-38fd709fa5b7/output/x86_64-linux-gnu/SHA256SUMS.part
22c556fc765a60445927689948799d87608ca6451abc5ed91e4170d52569957e guix-build-38fd709fa5b7/output/x86_64-linux-gnu/bitcoin-38fd709fa5b7-x86_64-linux-gnu-debug.tar.gz
6936bc7521fffd9ea4d62991dd816f21d4b63529b9bbbeabfda9c93b6abe403c guix-build-38fd709fa5b7/output/x86_64-linux-gnu/bitcoin-38fd709fa5b7-x86_64-linux-gnu.tar.gz
f03c2a8786b1d0639f6cfcc8a09c046bbfaa7e64bfe83a4dbf57f2e7221c8694 guix-build-38fd709fa5b7/output/x86_64-w64-mingw32/SHA256SUMS.part
54db1a703e8ba93021657e4891214b310adb6311e6c8af02a99f9f6132f83922 guix-build-38fd709fa5b7/output/x86_64-w64-mingw32/bitcoin-38fd709fa5b7-win-unsigned.tar.gz
8103f60e038f9d618f2c9fafbdcc0955c4d632539ef3782315a889cc6db11872 guix-build-38fd709fa5b7/output/x86_64-w64-mingw32/bitcoin-38fd709fa5b7-win64-debug.zip
8f26c2e33273ce7291c453b76365723852dd18fca80441f992664065879df5e1 guix-build-38fd709fa5b7/output/x86_64-w64-mingw32/bitcoin-38fd709fa5b7-win64-setup-unsigned.exe
bbe860791669f86bf3c6edcb7683e016f192d003bec15c9c141f7dfae3d11160 guix-build-38fd709fa5b7/output/x86_64-w64-mingw32/bitcoin-38fd709fa5b7-win64.zip |
Concept ACK.
|
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.
ACK 38fd709 (also see #23149 (comment)), tested:
- on Linux Mint 20.2 (x86_64):
$ ./configure --without-bdb --enable-suppress-external-warnings --enable-werror CC=clang-12 CXX=clang++-12 && make clean && make
# ok
$ ./configure --without-bdb --enable-werror CC=clang-12 CXX=clang++-12 && make clean && make
# [-Werror,-Wsuggest-override] errors as expected
$ ./configure --without-bdb --without-gui --enable-werror CC=clang-12 CXX=clang++-12 && make clean && make
# ok
$ ./configure --without-bdb --enable-suppress-external-warnings --enable-werror CC=gcc-10 CXX=g++-10 && make clean && make
# ok
$ ./configure --without-bdb --enable-werror CC=gcc-10 CXX=g++-10 && make clean && make
# ok
- on macOS 11.6 (20G165, Intel):
% ./configure --enable-suppress-external-warnings --enable-werror && make clean && make
# ok
Guix builds:
|
FWIW, the current master (1790a8d) has 2
Suggesting to postpone merging of this PR until those warnings are addressed. |
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.
Concept ACK 38fd709
AX_CHECK_COMPILE_FLAG([-Werror=suggest-override],[ERROR_CXXFLAGS="$ERROR_CXXFLAGS -Werror=suggest-override"],,[[$CXXFLAG_WERROR]], | ||
[AC_LANG_SOURCE([[struct A { virtual void f(); }; struct B : A { void f() final; };]])]) | ||
AX_CHECK_COMPILE_FLAG([-Werror=unreachable-code-loop-increment],[ERROR_CXXFLAGS="$ERROR_CXXFLAGS -Werror=unreachable-code-loop-increment"],,[[$CXXFLAG_WERROR]]) | ||
AX_CHECK_COMPILE_FLAG([-Werror=mismatched-tags], [ERROR_CXXFLAGS="$ERROR_CXXFLAGS -Werror=mismatched-tags"], [], [$CXXFLAG_WERROR]) |
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 presume this is enabled by default to warrant a removal?
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.
In Clang it's included in -Wmost
which is part of -Wall
.
I'm not seeing this in any of the CIs. If people are seeing these locally, because their GCC is throwing false positives, i.e #23101, I'd suggest they either stop using |
This reverts commit 810cccd.
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.
ACK 38fd709
I checked separately clang and gcc, all of the removed -Werror=foo
are either:
- Enabled explicitly in
configure.ac
via-Wfoo
, or - Enabled implicitly by e.g.
-Wall
in that compiler, or - Not exist in that compiler
Now I can remove a custom build environment I had:
export CPPFLAGS="${CPPFLAGS} -Werror"
No longer special case a set of warnings, to make up our own -Werror,
just use -Werror outright. This shouldn't really have any effect on
existing builders, who were already using
--enable-werror
, and is moreinline with what they would expect
--enable-werror
to be, which iserroring on any/all warnings.
We keep
-Wno-error=return-type
because we know that is broken when usingmingw-w64. It should only be applied when cross-compiling for Windows.
Similar to the change in #20544, but with (hopefully) less work-arounds,
and other bundled changes. A step towards some configure "cleanups".