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
