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).
