diff options
author | Jason Merrill <jason@redhat.com> | 2025-03-29 14:00:55 -0400 |
---|---|---|
committer | Jason Merrill <jason@redhat.com> | 2025-03-31 07:29:23 -0400 |
commit | 1949beb7dbe66687542f4a19d316914dd73fe84d (patch) | |
tree | 5f209878fb0968adac5ad5084907079bd38dca12 /gcc/fortran | |
parent | 95c25cb09f58810bc520c3db469945c6a751aa32 (diff) | |
download | gcc-1949beb7dbe66687542f4a19d316914dd73fe84d.zip gcc-1949beb7dbe66687542f4a19d316914dd73fe84d.tar.gz gcc-1949beb7dbe66687542f4a19d316914dd73fe84d.tar.bz2 |
c++: lambda in function template signature [PR119401]
Here we instantiate the lambda three times in producing A<0>::f:
1) in tsubst_function_type, substituting the type of A<>::f
2) in tsubst_function_decl, substituting the parameters of A<>::f
3) in regenerate_decl_from_template when instantiating A<>::f
The first one gets thrown away by maybe_rebuild_function_decl_type. Before
r15-7202, we happily built all of them and mangled the result wrongly as
lambda #3. After r15-7202, we try to mangle #3 as #1, which breaks because
#1 is already mangled as #1.
This patch avoids building #3 by suppressing regenerate_decl_from_template
if the template signature includes a lambda, fixing the ICE.
We now mangle the lambda as #2, which is still wrong. Addressing that
should involve not calling tsubst_function_type from tsubst_function_decl,
and building the type from the parms types in the first place rather than
fixing it up in maybe_rebuild_function_decl_type.
PR c++/119401
gcc/cp/ChangeLog:
* pt.cc (regenerate_decl_from_template): Don't regenerate if the
signature involves a lambda.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ11.C: New test.
Diffstat (limited to 'gcc/fortran')
0 files changed, 0 insertions, 0 deletions