On Fri, Nov 18, 2022 at 08:48:32AM +0100, Jakub Jelinek wrote:
> 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
Right, that's the C++17 implicit constexpr for lambdas, finish_function:
/* Lambda closure members are implicitly constexpr if possible. */
if (cxx_dialect >= cxx17
&& LAMBDA_TYPE_P (CP_DECL_CONTEXT (fndecl)))
DECL_DECLARED_CONSTEXPR_P (fndecl)
= ((processing_template_decl
|| is_valid_constexpr_fn (fndecl, /*complain*/false))
&& potential_constant_expression (DECL_SAVED_TREE (fndecl)));
> 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.
Um, can we give up on trying to handle C++17/C++20 then?
Marek
