diff options
author | Jason Merrill <jason@redhat.com> | 2025-07-24 14:07:11 -0400 |
---|---|---|
committer | Jason Merrill <jason@redhat.com> | 2025-07-24 14:07:11 -0400 |
commit | eb59e58dcc4cdf36b8b2d4e1654fe4fa062b5bef (patch) | |
tree | ac3d039b70b65cd8e7a6e7179bfa4729a54d7d46 /libstdc++-v3/testsuite/std | |
parent | 44e32178031e89399710c3ee7444891631a9c8ec (diff) | |
download | gcc-eb59e58dcc4cdf36b8b2d4e1654fe4fa062b5bef.zip gcc-eb59e58dcc4cdf36b8b2d4e1654fe4fa062b5bef.tar.gz gcc-eb59e58dcc4cdf36b8b2d4e1654fe4fa062b5bef.tar.bz2 |
c++: lambda convop in C++23 [PR114632]
The lambda conversion was ICEing for two C++23 features, static op() and
explicit object parameters. The issue with the former seems like a more
general issue: tsubst_function_decl recursing to substitute the parameters
was affected by cp_unevaluated_operand from the decltype that refers to the
declaration. Various places already make a point of clearing
cp_unevaluated_operand ahead of PARM_DECL tsubsting; doing it here makes the
PR101233 fix redundant.
For explicit object lambdas, we want to implement CWG2561 and
just not declare the conversion.
PR c++/114632
PR c++/101233
gcc/cp/ChangeLog:
* lambda.cc (maybe_add_lambda_conv_op): Not for xobj lambda.
* pt.cc (tsubst_function_decl): Add cp_evaluated.
(alias_ctad_tweaks): Revert PR101233 fix.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-lambda18.C: New test.
* g++.dg/cpp23/static-operator-call7.C: New test.
Diffstat (limited to 'libstdc++-v3/testsuite/std')
0 files changed, 0 insertions, 0 deletions