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

[Jason Merrill <jason@redhat.com>]

On 11/18/22 10:03, Marek Polacek wrote:
> 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)));

Yeah, I guess potential_constant_expression needs to be stricter in a 
lambda. Or perhaps any function that isn't already 
DECL_DECLARED_CONSTEXPR_P?

>> 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?

I'd expect the above change to potential_c_e to handle that case.

Jason