[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-26 Ever confirmed|0 |1
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #1 from Jason Merrill --- It would also be helpful to explain for static_assert (!Int);
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #2 from Andrew Sutton --- This is tricky because the condition reduces to true/false before the static assertion evaluates it. We could introduce a new binary expression that stores the original expression and it's computed value, and use that to hook into diagnostics from the static assert.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #3 from Jonathan Wakely --- Another idea would be to add a new flag which chooses between brief and verbose explanations of satisfaction failure during overload resolution. By default just say that an overload isn't viable because type X doesn't satisfy std::forward_iterator, but with -fsatisfy-me-harder show that it doesn't satisfy forward_iterator because it doesn't satisfy input_iterator because it doesn't satisfy readable because common_reference_t is an invalid type. That would allow you to debug unexpected satisfaction failures without having to edit the code to add a static_assert. The currently-commented-out code that replays the substitution could be controlled by that new flag.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #4 from Jason Merrill --- (In reply to Andrew Sutton from comment #2) > This is tricky because the condition reduces to true/false before the static > assertion evaluates it. We could introduce a new binary expression that > stores the original expression and it's computed value, and use that to hook > into diagnostics from the static assert. Can we avoid reducing concept checks in finish_id_expression_1? constexpr evaluation already handles them, I'd think we would just need to also handle them in fold or genericize or gimplify.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #5 from Jason Merrill --- Created attachment 47153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47153&action=edit sketch of late evaulation something like this. not continuing to work on it.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #6 from Andrew Sutton --- I'm going to send a patch for this, hopefully this morning, that ties concept diagnostics into static asserts. It wasn't as bad as I thought it was going to be. I didn't implement this: static_assert (!Int); because I'm not sure what would be good to print. It may be possible to completely invert all the diagnostics (e.g., failed because f(x) is valid), but that would likely take some heroic effort.
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 --- Comment #7 from asutton at gcc dot gnu.org --- Author: asutton Date: Wed Nov 27 15:23:02 2019 New Revision: 278775 URL: https://gcc.gnu.org/viewcvs?rev=278775&root=gcc&view=rev Log: 2019-11-27 Andrew Sutton PR c++/92236 Defer evaluation of concept checks so that static assertions can emit more detailed diagnostics. gcc/cp/ * constexpr.c (cxx_eval_call_expression): Handle concept checks. (cxx_eval_constant_expression): Diagnose misuse of function concepts as template-id expressions. Follow the usual return path for results. (cxx_eval_outermost_constant_expr): Avoid calling cp_get_callee_fndecl_nofold for function concepts. * constraint.cc (build_function_check): Fully type the concept check so that we don't ICE in conversions. * cp-gimplify.c (cp_genericize_r) [CALL_EXPR]: Handle concept checks. [TEMPLATE_ID_EXPR] Likewise. * cvt.c (convert_to_void): Always evaluate concept checks so we don't accidentally ignore them. Substitution during satisfaction can make a program ill-formed (example in g++.dg/cpp2a/concepts6.C). * pt.c (tsubst_copy_and_build): [CALL_EXPR]: Don't evaluate concepts. [TEMPLATE_ID_EXPR]: Likewise. * semantics.c (finish_call_expr): Don't evaluate concepts. (finish_id_expression_1): Likewise. (finish_static_assert): Preserve the original condition so we can diagnose concept errors when a check returns false. gcc/testsuite/ * g++.dg/cpp2a/concepts-iconv1.C: Update diagnostics. * g++.dg/cpp2a/concepts-requires5.C: Likewise. * g++.dg/cpp2a/concepts6.C: New test. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/constraint.cc trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cvt.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp2a/concepts-iconv1.C trunk/gcc/testsuite/g++.dg/cpp2a/concepts-requires5.C
[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #8 from Jason Merrill --- Fixed for GCC 10.
