https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126483
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Patrick Palka <[email protected]>: https://gcc.gnu.org/g:b3bca9f73eb6b29bddf5fec92e929f32675b8d20 commit r17-3304-gb3bca9f73eb6b29bddf5fec92e929f32675b8d20 Author: Patrick Palka <[email protected]> Date: Fri Aug 14 15:53:12 2026 -0400 c++: is_const_eval init folding inside lambda scope [PR126483] Here when processing a's copy-initialization we overeagerly fold its initializer as if the lambda scope is not constexpr, and thus assume is_constant_evaluated is false. Subsequent constant evaluation of the lambda gives the wrong answer due to this premature folding. The culprit cp_fully_fold_init call is guarded by DECL_DECLARED_CONSTEXPR_P but that can't be relied on for maybe-constexpr lambdas until the lambda is fully parsed and its body is checked as a whole for constexpr suitability. This patch makes us check maybe_constexpr_fn instead, which considers such lambdas. This however means we no longer fold a's copy-init even for the runtime version of the lambda body, hence the is_constant_evaluated3b.C xfail. Making maybe_constexpr_fn distinguish between fully parsed constexpr and non-constexpr lambdas doesn't help because we don't hit this code path again. And cp_fold_function doesn't fold the copy-init because it's represented as an INIT_EXPR of an AGGR_INIT_EXPR which it doesn't yet handle. The subsequent patch will enable folding of INIT_EXPR initializers to address this xfail. PR c++/126483 gcc/cp/ChangeLog: * typeck2.cc (store_init_value): Check maybe_constexpr_fn instead of DECL_DECLARED_CONSTEXPR_P of the function scope. gcc/testsuite/ChangeLog: * g++.dg/opt/is_constant_evaluated3b.C: xfail a1 initializer folding. * g++.dg/cpp2a/is-constant-evaluated16.C: New test. Reviewed-by: Jason Merrill <[email protected]>
