[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Thu Oct 31 13:17:48 2019 New Revision: 277667 URL: https://gcc.gnu.org/viewcvs?rev=277667=gcc=rev Log: Remove PR 92268 workaround and fix new test failures With the compiler bug fixed we can simplify the __sizable concept to use a return-type-requirement again. I also realised it was redundantly re-checking a subset of the sized_sentinel_for requirements. The compiler fix also revealed bugs in two tests which started to fail and are fixed by this patch. * include/bits/range_access.h (__sizable): Rename to __sentinel_size. Remove workaround for PR c++/92268 and remove redundant requirements that are already checked by sized_sentinel_for. * testsuite/std/ranges/access/cend.cc: Fix failures. * testsuite/std/ranges/access/end.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/range_access.h trunk/libstdc++-v3/testsuite/std/ranges/access/cend.cc trunk/libstdc++-v3/testsuite/std/ranges/access/end.cc
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #11 from Jonathan Wakely --- Yes those tests exercise some weird, contrived corner cases. I messed some up and will fix them (and remove my workaround for this bug - thanks!)
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #10 from Jason Merrill --- Note that I see > FAIL: std/ranges/access/cend.cc (test for excess errors) > FAIL: std/ranges/access/end.cc (test for excess errors) with this patch, because now we properly catch the substitution failure in -> sentinel_for(__t)))>
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #9 from Jason Merrill --- Author: jason Date: Thu Oct 31 02:01:16 2019 New Revision: 277654 URL: https://gcc.gnu.org/viewcvs?rev=277654=gcc=rev Log: PR c++/92268 - hard error satisfying return-type-requirement Previously we would put the template arguments for the concept-check in a TEMPLATE_ID and then also pass them to constraints_satisfied_p, which meant that we would try to normalize the concept-check with the fully instantiated arguments, leading to sadness. Simply not passing the args to constraints_satisfied_p fixes the problem. I also noticed that we weren't detecting substitution failure in the constraints, but were silently treating it as success. * constraint.cc (type_deducible_p): Check for substitution failure. (diagnose_compound_requirement): Adjust diagnostic. * pt.c (do_auto_deduction): Don't pass cargs to constraints_satisfied_p. Added: trunk/gcc/testsuite/g++.dg/cpp2a/concepts-return-req1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constraint.cc trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/concepts/diagnostic1.C trunk/gcc/testsuite/g++.dg/concepts/placeholder3.C trunk/gcc/testsuite/g++.dg/concepts/placeholder4.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-pr67178.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-requires6.C
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #8 from Jason Merrill --- (In reply to Jason Merrill from comment #6) > But for a constraint with template arguments like, say, same_as, we do, > as we can can run into the same situation as with non-nested requirements: ...except that the draft says — Substitution of template arguments (if any) into the return-type-requirement is performed. This sounds like normal substitution, so we don't need to do normalization at all, just satisfaction.
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 --- Comment #7 from Jason Merrill --- Created attachment 47136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47136=edit patch for the simple case This untested patch fixes my testcase and Jon's, though not the more complex case. Not working on this anymore.
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #6 from Jason Merrill ---
(In reply to Jason Merrill from comment #5)
> On further thought, I'm not sure normalizing the dependent form is really
> necessary, either here or for nested-requirements, as long as we get the
> proper SFINAE behavior for the requires-expression.
Well...for a simple constraint like this we don't need to do any additional
normalization, as we already have the normal form of forward_iterator.
But for a constraint with template arguments like, say, same_as, we do, as
we can can run into the same situation as with non-nested requirements:
template concept is_void = __is_same_as(Tz, void);
template concept same_as = __is_same_as (Tx, Ty);
template concept void_or_same = is_void || same_as;
template concept foo
= requires { { T() } -> void_or_same; };
template void f() requires foo;
int main() { f(); }
Here, we need to normalize void_or_same and then do satisfaction.
[Bug c++/92268] [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Jason Merrill changed: What|Removed |Added Summary|Constraint normalization|[concepts] hard error |substitutes parameter too |satisfying |early |return-type-requirement --- Comment #5 from Jason Merrill --- On further thought, I'm not sure normalizing the dependent form is really necessary, either here or for nested-requirements, as long as we get the proper SFINAE behavior for the requires-expression.
