[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #1 from Jonathan Wakely --- It works fine in Clang 9.0.0 though. We've never really set a hard limit on how many old versions of Clang we support, but given that 9 and 10 (and trunk) work, I'm inclined to think that three versions seems enough for new C++20 features.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #2 from Jonathan Wakely --- Changing the _Stop_state_ref default constructor to: _Stop_state_ref() noexcept {} allows it to compile. It shouldn't be needed, but I suppose since the constructor is already non-trivial (due to the default member initializer that is the cause of the error) we could do that.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #3 from Eric Niebler --- It seems like GitHub actions uses the latest libstdc++ by default when testing even with old (e.g., clang-4) toolsets. That seems busted, but regardless, this is now breaking _all_ my Linux clang tests for anything less than clang-9, which is unfortunate.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #4 from Jonathan Wakely --- Github's poor life choices should not be our problem ;-) If clang-8 doesn't ship and doesn't work with GCC's , I would interpret that as you can't test with clang-8.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #5 from Eric Niebler --- > Github's poor life choices should not be our problem ;-) I thought you'd say that. :-) > If clang-8 doesn't ship and doesn't work with GCC's > , I would interpret that as you can't test with > clang-8. Yeah, except I'm not trying to test . I'm just trying to include , which includes and hard-errors. In fact, what I'm _really_ trying to do is include , which includes , which includes , which includes . All roads, it seems, lead to .
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-11-19 --- Comment #6 from Jonathan Wakely --- Ugh, OK, that's more problematic then.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #7 from Jonathan Wakely --- g:f5d9bc8ae81abe46640477bc9e655aa093947f5f removed the dependency from on for most targets.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |10.3 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #8 from Jonathan Wakely --- Backporting that to gcc-10 would break any code implicitly relying on being included by . I generally only do such header dependency changes for major releases. Maybe it's OK, as it's only included for C++17 mode, which isn't considered stable for gcc-10. Separately, shouldn't need when it already declares polymorphic allocator (which is sufficient for and and the other headers with alias templates in std::pmr). It needs it because pmr::string::const_iterator and pmr::wstring::const_iterator require string and wstring to be complete, which requires polymorphic_allocator to be complete. That's avoidable though: --- a/libstdc++-v3/include/std/regex +++ b/libstdc++-v3/include/std/regex @@ -64,7 +64,6 @@ #include #if __cplusplus >= 201703L && _GLIBCXX_USE_CXX11_ABI -#include namespace std _GLIBCXX_VISIBILITY(default) { _GLIBCXX_BEGIN_NAMESPACE_VERSION @@ -74,11 +73,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION using match_results = std::match_results<_BidirectionalIterator, polymorphic_allocator< sub_match<_BidirectionalIterator>>>; -using cmatch = match_results; -using smatch = match_results; +using cmatch = match_results; +using smatch + = match_results<__gnu_cxx::__normal_iterator>; #ifdef _GLIBCXX_USE_WCHAR_T using wcmatch = match_results; -using wsmatch = match_results; +using wsmatch + = match_results<__gnu_cxx::__normal_iterator>; #endif } // namespace pmr _GLIBCXX_END_NAMESPACE_VERSION I think removing that dependency in the gcc-10 branch should be OK too.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:640ebeb336050887cb57417b7568279c588088f0 commit r11-5199-g640ebeb336050887cb57417b7568279c588088f0 Author: Jonathan Wakely Date: Fri Nov 20 11:30:33 2020 + libstdc++: Remove dependency from [PR 92546] Unlike the other headers that declare alias templates in namespace pmr, includes . That was done because the pmr::string::const_iterator typedef requires pmr::string to be complete, which requires pmr::polymorphic_allocator to be complete. By using __normal_iterator instead of the const_iterator typedef we can avoid the completeness requirement. This makes smaller, by not requiring and its dependency, which depends on . Backporting this will also help with PR 97876, where ends up being needed by via . libstdc++-v3/ChangeLog: PR libstdc++/92546 * include/std/regex (pmr::smatch, pmr::wsmatch): Declare using underlying __normal_iterator type, not nested typedef basic_string::const_iterator.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a186d72afd6cfb13efd4a0ec82049d79892334fd commit r10-9056-ga186d72afd6cfb13efd4a0ec82049d79892334fd Author: Jonathan Wakely Date: Thu Nov 19 22:32:54 2020 + libstdc++: Fix compilation error with clang-8 [PR 97876] This fixes a compilation error with clang-8 and earlier. This change is only on the gcc-10 branch, not master, because the header is included indirectly in more places on the branch than on master. PR libstdc++/97876 * include/std/stop_token (_Stop_state_t): Define default constructor as user-provided not defaulted.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cbbc28706164873d0323d1a6c7988be3f4d971c9 commit r10-9057-gcbbc28706164873d0323d1a6c7988be3f4d971c9 Author: Jonathan Wakely Date: Fri Nov 20 11:30:33 2020 + libstdc++: Remove dependency from [PR 92546] Unlike the other headers that declare alias templates in namespace pmr, includes . That was done because the pmr::string::const_iterator typedef requires pmr::string to be complete, which requires pmr::polymorphic_allocator to be complete. By using __normal_iterator instead of the const_iterator typedef we can avoid the completeness requirement. This makes smaller, by not requiring and its dependency, which depends on . Backporting this will also help with PR 97876, where ends up being needed by via . libstdc++-v3/ChangeLog: PR libstdc++/92546 * include/std/regex (pmr::smatch, pmr::wsmatch): Declare using underlying __normal_iterator type, not nested typedef basic_string::const_iterator. (cherry picked from commit 640ebeb336050887cb57417b7568279c588088f0)
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Changing the _Stop_state_ref default constructor to: > > _Stop_state_ref() noexcept {} > > allows it to compile. It shouldn't be needed, but I suppose since the > constructor is already non-trivial (due to the default member initializer > that is the cause of the error) we could do that. I've done this on the gcc-10 branch, but not trunk. That means the same problem will recur with clang-8 and in gcc-11. However, I've also removed the dependency from on gcc-10 and trunk, and already stopped including on trunk. So there are fewer routes to now. Now you just need to wait for Ubuntu to update gcc-10 and for GitHub to deploy that update, which I can't help with.