-
Notifications
You must be signed in to change notification settings - Fork 36.5k
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: Require C++20 compiler #28349
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. 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. |
Not sure why CI fails. Does |
--- a/depends/Makefile
+++ b/depends/Makefile
@@ -49,7 +49,7 @@ NO_HARDEN ?=
FALLBACK_DOWNLOAD_PATH ?= https://bitcoincore.org/depends-sources
C_STANDARD ?= c11
-CXX_STANDARD ?= c++17
+CXX_STANDARD ?= c++20
BUILD = $(shell ./config.guess)
HOST ?= $(BUILD) ? |
https://cirrus-ci.com/task/5662608053764096:
funny... |
Ok, looks like this is passing. The remaining errors should go away once and if this is rebased on the bump pull requests. |
It seems we should require GCC >= 10 first. See: https://gcc.gnu.org/projects/cxx-status.html. |
Yes, I am aware, see the pull request description and my previous comment. |
FWIW, I get a configure.ac error with clang 14 and libstdc++ 13 --
|
Ugh, that seems like a blocker, given that clang-14 seems still to be the default for the current Debian stable (https://packages.debian.org/bookworm/clang) and even trixie (for now).
If this was the only error, I wonder if it will go away with the cmake transition, or if we can work around it, but I doubt it and expect almost any code to fail to compile. |
I think it's specific to |
Ah, it's worse than that -- clang++-14 can't deal with libstdc++'s chrono header at all in c++20 mode.
Using libc++ with
|
Yeah, that should be a known "issue", unrelated to C++20. |
So to clarify, this is only a bug with clang++-14 and libstdc++-13? If so, the only operating system that ships with this config is Debian 13 Trixie, which is your operating system? If so, I'd suggest to just fix it upstream by bumping the default clang version in Debian. |
Yeah... I guess we could do C++20 with the following options on linux:
Probably want an autoconf macro to check for the latter case? |
Sgtm, but maybe check the status of the autoconf and bdb removal before spending time on this? 😅 |
Yes, this seems correct! Seems like a non-problem then. |
Our depends version of Qt is also going to be a blocker here. We'll need to move along to a more recent point release for improved C++20 support. |
Sorry if I missed something that was mentioned previously, but what is wrong in Qt 5.15.5 with C++20 support? With this diff: diff --git a/depends/Makefile b/depends/Makefile
index 3169117633..319c3498df 100644
--- a/depends/Makefile
+++ b/depends/Makefile
@@ -49,7 +49,7 @@ NO_HARDEN ?=
FALLBACK_DOWNLOAD_PATH ?= https://bitcoincore.org/depends-sources
C_STANDARD ?= c11
-CXX_STANDARD ?= c++17
+CXX_STANDARD ?= c++20
BUILD = $(shell ./config.guess)
HOST ?= $(BUILD)
diff --git a/depends/packages/qt.mk b/depends/packages/qt.mk
index 136ce32579..ef30878e65 100644
--- a/depends/packages/qt.mk
+++ b/depends/packages/qt.mk
@@ -39,7 +39,7 @@ $(package)_config_opts_release += -silent
$(package)_config_opts_debug = -debug
$(package)_config_opts_debug += -optimized-tools
$(package)_config_opts += -bindir $(build_prefix)/bin
-$(package)_config_opts += -c++std c++17
+$(package)_config_opts += -c++std c++2a
$(package)_config_opts += -confirm-license
$(package)_config_opts += -hostprefix $(build_prefix)
$(package)_config_opts += -no-compile-examples everything compiles. Did not test cross-compiling, however. A quick look at https://github.com/qt/qtbase/compare/v5.15.5-lts-lgpl..v5.15.10-lts-lgpl shows that support for C++23 has been added. But we are talking about C++20, right? |
Last I looked there were fixes since 5.15.5 that we needed, and things didn't work.
What do you mean by "everything"? Probably also worth checking cross-compilation before claiming it works? |
Why not just sharing known steps to reproduce "things didn't work"? |
Because I tested it as part of a different change, months ago, and don't have a trivial reproducer on hand. |
The first thing I tested after applying your diff failed to compile. Master (fd8ab08) + #28543 + the diff above: Build type: macx-clang (x86_64, CPU features: cx16 mmx sse sse2 sse3 ssse3 sse4.1)
Compiler: clang (Apple) 15.0.0
Configuration: sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2 avx512f avx512bw avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi avx512vl f16c largefile precompile_header rdrnd rdseed shani silent x86SimdAlways release c++11 c++14 c++17 c++1z c++2a reduce_exports static stl
Build options:
Mode ................................... release
Optimize release build for size ........ no
Building shared libraries .............. no
Using C standard ....................... C11
Using C++ standard ..................... C++2a
Using ccache ........................... no
<snip>
compiling ../../corelib/io/qdir.cpp
compiling ../../corelib/io/qdiriterator.cpp
../../corelib/global/qrandom.cpp:386:30: error: no member named 'is_literal_type' in namespace 'std'
Q_STATIC_ASSERT(std::is_literal_type<SystemAndGlobalGenerators>::value);
~~~~~^
../../../include/QtCore/../../src/corelib/global/qglobal.h:120:57: note: expanded from macro 'Q_STATIC_ASSERT'
# define Q_STATIC_ASSERT(Condition) static_assert(bool(Condition), #Condition)
^~~~~~~~~
../../corelib/global/qrandom.cpp:386:46: error: 'SystemAndGlobalGenerators' does not refer to a value
Q_STATIC_ASSERT(std::is_literal_type<SystemAndGlobalGenerators>::value);
^
../../corelib/global/qrandom.cpp:350:26: note: declared here
struct QRandomGenerator::SystemAndGlobalGenerators
^
../../corelib/global/qrandom.cpp:386:74: error: no member named 'value' in the global namespace
Q_STATIC_ASSERT(std::is_literal_type<SystemAndGlobalGenerators>::value);
~~^
../../../include/QtCore/../../src/corelib/global/qglobal.h:120:57: note: expanded from macro 'Q_STATIC_ASSERT'
# define Q_STATIC_ASSERT(Condition) static_assert(bool(Condition), #Condition)
^~~~~~~~~
compiling ../../corelib/io/qfile.cpp
3 errors generated. Looks like this was fixed upstream in qt/qtbase@df08a21, which we don't yet have until updating. Am I missing something? |
post-merge ACK. Tested this on my NixOS setup. Configure and build works fine, unit tests pass. Reverting in faa4838 makes sense. I see a few `-Wmaybe-uninitialized` warnings not sure if they're related.
|
Post-merge ACK. |
It does :) |
Isn't it just applying the exact same workaround (internally) that we are using? There's no other way to know that GCC supports C++20, because of the bug we discussed above. |
I didn't look into CMake code for that. I only tested it, including the minimum supported CMake 3.16. |
This needs a release note imo. |
Added rel-note todo to the draft wiki. |
This option has ceased to exist since bitcoin#28349.
64722e4 ci: Drop `--enable-c++20` option (Hennadii Stepanov) Pull request description: This option has ceased to exist since #28349. ACKs for top commit: maflcko: ACK 64722e4 Tree-SHA512: bd392c331f775605615e1b236682269b83a1e6363a4d3f09c4d8d54495cf3d22973a921ebf6b8a9f813ba6c024d3324761f3291aaf7f473995f5eaa4c195bc43
It is unclear what the goal of this check is, given that the value may need to be set lower for the mimimum supported version of compilers that forgot to bump the value, see bitcoin/bitcoin#28349 (comment) . The minimum supported compiler versions are already documented in doc/dependencies.md and using an older compiler will already result in a compile failure, so this check can be removed as redundant. Especially given that it is only included in one file, where iwyu suggests to remove it.
fa6e50d fuzz: Use C++20 starts_with in rpc.cpp (MarcoFalke) faa4838 Revert "tracepoints: Disables `-Wgnu-zero-variadic-macro-arguments` to compile without warnings" (MarcoFalke) fae3b77 refactor: Drop unused _Pragma to ignore -Wgnu-zero-variadic-macro-arguments (MarcoFalke) fa02fc0 refactor: modernize-use-default-member-init for bit-fields (C++20) (MarcoFalke) fa67f09 build: Require C++20 compiler (MarcoFalke) Pull request description: C++20 allows to write safer code, because it allows to enforce more stuff at compile time (`constinit`, `conteval`, `constexpr`, `std::span`, ...). Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts). See bitcoin#23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20 With g++-10 (bitcoin#28348) and clang-13 (bitcoin#28210), there is broad support for almost all features of C++20. It should be fine to require a C++20 compiler for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month. This pull request includes three small cleanups to make use of C++20 features. If any issues are detected before or after merge, this should be easy to revert. If no issues arise, it should be fine to make use of more involved C++20 features later on. ACKs for top commit: fanquake: ACK fa6e50d Tree-SHA512: 244d79bfb0b750a4bdd713f40573b9ca33816fb84b6c84a58f027b9d7d4bb0cc4f18642959e4cf3d094808a69e5b8a327ca8521d7c0c08af27dacb5da3e78e71
fa6e50d fuzz: Use C++20 starts_with in rpc.cpp (MarcoFalke) faa4838 Revert "tracepoints: Disables `-Wgnu-zero-variadic-macro-arguments` to compile without warnings" (MarcoFalke) fae3b77 refactor: Drop unused _Pragma to ignore -Wgnu-zero-variadic-macro-arguments (MarcoFalke) fa02fc0 refactor: modernize-use-default-member-init for bit-fields (C++20) (MarcoFalke) fa67f09 build: Require C++20 compiler (MarcoFalke) Pull request description: C++20 allows to write safer code, because it allows to enforce more stuff at compile time (`constinit`, `conteval`, `constexpr`, `std::span`, ...). Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts). See bitcoin#23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20 With g++-10 (bitcoin#28348) and clang-13 (bitcoin#28210), there is broad support for almost all features of C++20. It should be fine to require a C++20 compiler for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month. This pull request includes three small cleanups to make use of C++20 features. If any issues are detected before or after merge, this should be easy to revert. If no issues arise, it should be fine to make use of more involved C++20 features later on. ACKs for top commit: fanquake: ACK fa6e50d Tree-SHA512: 244d79bfb0b750a4bdd713f40573b9ca33816fb84b6c84a58f027b9d7d4bb0cc4f18642959e4cf3d094808a69e5b8a327ca8521d7c0c08af27dacb5da3e78e71
This reverts commit 27a386e.
This option has ceased to exist since bitcoin/bitcoin#28349.
fa6e50d fuzz: Use C++20 starts_with in rpc.cpp (MarcoFalke) faa4838 Revert "tracepoints: Disables `-Wgnu-zero-variadic-macro-arguments` to compile without warnings" (MarcoFalke) fae3b77 refactor: Drop unused _Pragma to ignore -Wgnu-zero-variadic-macro-arguments (MarcoFalke) fa02fc0 refactor: modernize-use-default-member-init for bit-fields (C++20) (MarcoFalke) fa67f09 build: Require C++20 compiler (MarcoFalke) Pull request description: C++20 allows to write safer code, because it allows to enforce more stuff at compile time (`constinit`, `conteval`, `constexpr`, `std::span`, ...). Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts). See bitcoin#23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20 With g++-10 (bitcoin#28348) and clang-13 (bitcoin#28210), there is broad support for almost all features of C++20. It should be fine to require a C++20 compiler for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month. This pull request includes three small cleanups to make use of C++20 features. If any issues are detected before or after merge, this should be easy to revert. If no issues arise, it should be fine to make use of more involved C++20 features later on. ACKs for top commit: fanquake: ACK fa6e50d Tree-SHA512: 244d79bfb0b750a4bdd713f40573b9ca33816fb84b6c84a58f027b9d7d4bb0cc4f18642959e4cf3d094808a69e5b8a327ca8521d7c0c08af27dacb5da3e78e71
fa6e50d fuzz: Use C++20 starts_with in rpc.cpp (MarcoFalke) faa4838 Revert "tracepoints: Disables `-Wgnu-zero-variadic-macro-arguments` to compile without warnings" (MarcoFalke) fae3b77 refactor: Drop unused _Pragma to ignore -Wgnu-zero-variadic-macro-arguments (MarcoFalke) fa02fc0 refactor: modernize-use-default-member-init for bit-fields (C++20) (MarcoFalke) fa67f09 build: Require C++20 compiler (MarcoFalke) Pull request description: C++20 allows to write safer code, because it allows to enforce more stuff at compile time (`constinit`, `conteval`, `constexpr`, `std::span`, ...). Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts). See bitcoin#23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20 With g++-10 (bitcoin#28348) and clang-13 (bitcoin#28210), there is broad support for almost all features of C++20. It should be fine to require a C++20 compiler for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month. This pull request includes three small cleanups to make use of C++20 features. If any issues are detected before or after merge, this should be easy to revert. If no issues arise, it should be fine to make use of more involved C++20 features later on. ACKs for top commit: fanquake: ACK fa6e50d Tree-SHA512: 244d79bfb0b750a4bdd713f40573b9ca33816fb84b6c84a58f027b9d7d4bb0cc4f18642959e4cf3d094808a69e5b8a327ca8521d7c0c08af27dacb5da3e78e71
fa6e50d fuzz: Use C++20 starts_with in rpc.cpp (MarcoFalke) faa4838 Revert "tracepoints: Disables `-Wgnu-zero-variadic-macro-arguments` to compile without warnings" (MarcoFalke) fae3b77 refactor: Drop unused _Pragma to ignore -Wgnu-zero-variadic-macro-arguments (MarcoFalke) fa02fc0 refactor: modernize-use-default-member-init for bit-fields (C++20) (MarcoFalke) fa67f09 build: Require C++20 compiler (MarcoFalke) Pull request description: C++20 allows to write safer code, because it allows to enforce more stuff at compile time (`constinit`, `conteval`, `constexpr`, `std::span`, ...). Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts). See bitcoin#23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20 With g++-10 (bitcoin#28348) and clang-13 (bitcoin#28210), there is broad support for almost all features of C++20. It should be fine to require a C++20 compiler for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month. This pull request includes three small cleanups to make use of C++20 features. If any issues are detected before or after merge, this should be easy to revert. If no issues arise, it should be fine to make use of more involved C++20 features later on. ACKs for top commit: fanquake: ACK fa6e50d Tree-SHA512: 244d79bfb0b750a4bdd713f40573b9ca33816fb84b6c84a58f027b9d7d4bb0cc4f18642959e4cf3d094808a69e5b8a327ca8521d7c0c08af27dacb5da3e78e71
Reverts part of fa67f09, now that we require a minimum of GCC 11. See also: bitcoin#28349 (comment).
232928b build: no-longer allow GCC-10 in C++20 check (fanquake) Pull request description: Reverts part of fa67f09, now that we require a minimum of GCC 11. See also: #28349 (comment). ACKs for top commit: maflcko: utACK 232928b theuni: utACK 232928b Tree-SHA512: 10e0adac2dd6e455aaf97ebfe73c7586430349fc27ac435bc6c0d99a4934a380398d14467aacd9cedf371345da291366b3ab2c3be7db5d97e21ad6212b2c7890
Reverts part of fa67f096bdea9db59dd20c470c9e32f3dac5be94, now that we require a minimum of GCC 11. See also: bitcoin/bitcoin#28349 (comment).
C++20 allows to write safer code, because it allows to enforce more stuff at compile time (
constinit
,conteval
,constexpr
,std::span
, ...).Also, it allows to write less verbose and easier to understand code (C++ 20 Concepts).
See #23363 and https://en.cppreference.com/w/cpp/compiler_support#cpp20
With g++-10 (#28348) and clang-13 (#28210), there is broad support for almost all features of C++20.
It should be fine to require a C++20 compiler for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month.
This pull request includes three small cleanups to make use of C++20 features. If any issues are detected before or after merge, this should be easy to revert. If no issues arise, it should be fine to make use of more involved C++20 features later on.