c++: constexpr evaluation and bare EMPTY_CLASS_EXPR [PR96575]
In the testcase below, folding of the initializer for 'ret' inside the
instantiated f<lambda>::lambda ends up yielding an initializer for which
potential_constant_expression returns false. This causes finish_function
to mark the lambda as non-constexpr, which ultimately causes us to reject
'f(g)' as a call to a non-constexpr function.
The initializer for 'ret' inside f<lambda>::lambda, prior to folding, is
the CALL_EXPR
<lambda(S)>::operator() (&cb, ({}, <<< Unknown tree: empty_class_expr >>>;))
where the second argument is a COMPOUND_EXPR whose second operand is an
EMPTY_CLASS_EXPR that was formed by build_class_a. cp_fully_fold_init
is able to only partially fold this initializer: it gets rid of the
side-effectless COMPOUND_EXPR to obtain
<lambda(S)>::operator() (&cb, <<< Unknown tree: empty_class_expr >>>)
as the final initializer for 'ret'. This initializer no longer satifies
potential_constant_expression due to the bare EMPTY_CLASS_EXPR which is
not wrapped in a COMPOUND_EXPR.
(cp_fully_fold_init first tries maybe_constant_value on the original
CALL_EXPR, but constexpr evaluation punts upon seeing
__builtin_is_constant_evaluated, since manifestly_const_eval is false.)
To fix this, it seems we could either make cp_fold preserve the
COMPOUND_EXPR trees produced by build_call_a, or we could improve
the constexpr machinery to treat EMPTY_CLASS_EXPR trees as first-class
citizens. Assuming it's safe to continue folding away these
COMPOUND_EXPRs, the second approach seems cleaner, so this patch
implements the second approach.
gcc/cp/ChangeLog:
PR c++/96575
* constexpr.c (cxx_eval_constant_expression)
<case EMPTY_CLASS_EXPR>: Lower it to a CONSTRUCTOR.
(potential_constant_expression_1) <case COMPOUND_EXPR>: Remove
now-redundant handling of COMPOUND_EXPR with EMPTY_CLASS_EXPR
second operand.
<case EMPTY_CLASS_EXPR>: Return true instead of false.
gcc/testsuite/ChangeLog:
PR c++/96575
* g++.dg/cpp1z/constexpr-96575.C: New test.