[Bug c++/96251] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
So, as noted, the problem is being caused because the coroutine is being
regarded as potentially constexpr while still type-dependent, and then failing
during template expansion.

All the coroutine expressions are correctly marked as not suitable for
constexpr.

One can also use the DECL_COROUTINE_P on the function decl (which is added as
soon as any coroutine keyword is encountered - that would perhaps short-circuit
some work), but it doesn't fix the bug. ... like so.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 377fe322ee8..c4226599072 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -7827,6 +7827,9 @@ potential_constant_expression_1 (tree t, bool want_rval,
bool strict, bool now,
   switch (TREE_CODE (t))
     {
     case FUNCTION_DECL:
+      if (DECL_COROUTINE_P (t))
+       return false;
+       /* FALLTHROUGH.  */
     case BASELINK:
     case TEMPLATE_DECL:
     case OVERLOAD:

===

The for loop body is never visited during the initial parse, but rather the
dependent type in the loop init expression causes a conservative early exit
(with a 'true' result).

It seems that this conservative approach to potentially-constexpr, means that
some way of punting in template expansion is needed (or the initial check needs
to be less conservative).