[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 --- Comment #11 from CVS Commits --- The master branch has been updated by Paolo Carlini : https://gcc.gnu.org/g:83fe2b921830c177e3dee514aa07cbc7c8ceef1c commit r10-5990-g83fe2b921830c177e3dee514aa07cbc7c8ceef1c Author: Paolo Carlini Date: Wed Jan 15 22:28:46 2020 +0100 Fix "PR c++/91073 if constexpr no longer works directly with Concepts." This is a rather serious regression, filed in July 2019. Luckily the fix is simple: is localized to parser.c and cp-tree.h in cp and boils down to only a few lines. Testing OK on x86_64-linux. Approved off-line by Jason Merrill. /cp PR c++/91073 * cp-tree.h (is_constrained_auto): New. * parser.c (cp_parser_maybe_commit_to_declaration): Correctly handle concept-check expressions; take a cp_decl_specifier_seq* instead of a bool. (cp_parser_condition): Update call. (cp_parser_simple_declaration): Likewise. (cp_parser_placeholder_type_specifier): Correctly handle concept-check expressions. /testsuite PR c++/91073 * g++.dg/concepts/pr91073-1.C: New. * g++.dg/concepts/pr91073-2.C: Likewise.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 --- Comment #10 from Paolo Carlini --- I have been making progress on this (I'm in contact with Jason about that) but unfortunately the issue requires additional analysis for the simple reason that if I remove/amend my r260482 changes then in C++17 mode the testcases are accepted again, but in C++2a they are rejected anyway with a different error: "expected ‘auto’ or ‘decltype(auto)’ after ‘HasInit’" for the first testcase, for example. Likewise for the second testcase.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Tue Dec 3 23:57:46 2019 New Revision: 278951 URL: https://gcc.gnu.org/viewcvs?rev=278951=gcc=rev Log: libstdc++: Implement spaceship for std::pair (P1614R2) This defines operator<=> as a non-member function template and does not alter operator==. This contradicts the changes made by P1614R2, which specify both as hidden friends, but that specification of operator<=> is broken and the subject of a soon-to-be-published LWG issue. * include/bits/stl_pair.h [__cpp_lib_three_way_comparison] (operator<=>): Define for C++20. * libsupc++/compare (__cmp2way_res_t): Rename to __cmp3way_res_t, move into __detail namespace. Do not turn argument types into lvalues. (__cmp3way_helper): Rename to __cmp3way_res_impl, move into __detail namespace. Constrain with concepts instead of using void_t. (compare_three_way_result): Adjust name of base class. (compare_three_way_result_t): Use __cmp3way_res_impl directly. (__detail::__3way_cmp_with): Add workaround for PR 91073. (compare_three_way): Use workaround. (__detail::__synth3way, __detail::__synth3way_t): Define new helpers implementing synth-three-way and synth-three-way-result semantics. * testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc: New test. Added: trunk/libstdc++-v3/testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_pair.h trunk/libstdc++-v3/libsupc++/compare
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2019-11-19 00:00:00 |2019-12-3
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> The bug only seems to happen when the concept is variadic.
Or has a default argument, as in the dup I just reported:
template
concept one_or_two = true;
template
concept one = one_or_two;
template
constexpr void
foo()
{
if (one) // OK
{ }
if (one_or_two) // ERROR
{ }
}
gcc-8-branch accepts this with -fconcepts.
gcc-9-branch rejects it with -fconcepts:
92771.cc: In function 'constexpr void foo()':
92771.cc:14:20: error: expected unqualified-id before ')' token
14 | if (one_or_two) // ERROR
|^
trunk accepts it with -std=gnu++14 -fconcepts (since r276764) but still rejects
it with -std=gnu++17 -fconcepts or -std=gnu++2a:
92771.cc: In function 'constexpr void foo()':
92771.cc:14:7: error: expected 'auto' or 'decltype(auto)' after 'one_or_two'
14 | if (one_or_two) // ERROR
| ^
92771.cc:14:20: error: expected unqualified-id before ')' token
14 | if (one_or_two) // ERROR
|^
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #7 from Jonathan Wakely --- *** Bug 92771 has been marked as a duplicate of this bug. ***
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2019-07-03 00:00:00 |2019-11-19 --- Comment #6 from Jonathan Wakely --- N.B. the summary "if constexpr no longer works directly with Concepts" is not true in general. I'm using concepts with if-constexpr extensively in libstdc++ code e.g. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/range_access.h;h=de074460c16189f29fd2d0b31c81e2231843d2a8;hb=HEAD#l402 The bug only seems to happen when the concept is variadic.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 --- Comment #5 from Paolo Carlini --- You are right.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Perhaps more important now that -fconcepts is enabled automatically with -std=c++2a.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.2 |9.3 --- Comment #3 from Jakub Jelinek --- GCC 9.2 has been released.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 --- Comment #2 from Paolo Carlini --- In principle the issue is rather simple. The cp_parser_maybe_commit_to_declaration at the beginning of cp_parser_condition since r260482 thinks erroneously that the just parsed HasInit must be a declaration. In practice, I'm still not sure which is the best way to solve this... well, I'm not even sure we are supposed to actively work now on relatively minor concept-related issues.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.2
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.3.0 Keywords||rejects-valid Last reconfirmed||2019-07-03 CC||paolo at gcc dot gnu.org Ever confirmed|0 |1 Summary|if constexpr no longer |[9/10 Regression] if |works directly with |constexpr no longer works |Concepts|directly with Concepts Known to fail||10.0, 9.1.0 --- Comment #1 from Jonathan Wakely --- Confirmed as a regression (GCC 8 accepts it, if 'concept HasInit' is replaced with 'concept bool HasInit'). It started to be rejected with r260482: PR c++/84588 * parser.c (cp_parser_maybe_commit_to_declaration, cp_parser_check_condition_declarator): New. (cp_parser_simple_declaration): Use the first above. (cp_parser_condition): Use both the above; enforce [stmt.stmt]/2 about the declarator not specifying a function or an array; improve error-recovery.
