Re: [PATCH] c++, v4: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions

[Jakub Jelinek <jakub@redhat.com>]

On Thu, Nov 17, 2022 at 07:15:05PM -0500, Marek Polacek wrote:
> > --- gcc/cp/decl.cc.jj	2022-11-16 14:44:43.692339668 +0100
> > +++ gcc/cp/decl.cc	2022-11-17 20:53:44.102011594 +0100
> > @@ -5600,6 +5600,57 @@ groktypename (cp_decl_specifier_seq *typ
> >    return type;
> >  }
> >  
> > +/* For C++17 and older diagnose static or thread_local decls in constexpr
> > +   or consteval functions.  For C++20 similarly, except if they are
> 
> In C++17 we don't support consteval so I guess drop the "or consteval "?

I just forgot to update the function comment.

Anyway, I think:

> BTW, I notice that the patch breaks
> g++.dg/cpp1y/lambda-generic-func1.C
> g++.dg/cpp1z/constexpr-lambda16.C
> Maybe they just need dg- tweaks.

this is actually a real bug and I'm not sure how to resolve that.

We have there:

int main()
{
  [](auto i) { if (i) { int j; static int k; return i + j; } return i; }(0);
}

and for C++17/20 I presume something (haven't figured out yet what) marks
the lambda operator() when still a template as constexpr and then
cp_finish_decl -> diagnose_static_in_constexpr pedwarns on it.
For the above perhaps we could figure out there is a static int k; in the
operator() and don't turn it into constexpr, but what if there is
something that would e.g. satisfy decl_maybe_constant_var_p but not
decl_constant_var_p when actually instantiated?
Without my patch, the diagnostics is in start_decl which isn't called again
during instantiation, so I presume we mark it as constexpr and then we'd
diagnose it during constant evaluation.

	Jakub