aboutsummaryrefslogtreecommitdiff
path: root/gcc/fortran
diff options
context:
space:
mode:
authorJason Merrill <jason@redhat.com>2025-03-29 14:00:55 -0400
committerJason Merrill <jason@redhat.com>2025-03-31 07:29:23 -0400
commit1949beb7dbe66687542f4a19d316914dd73fe84d (patch)
tree5f209878fb0968adac5ad5084907079bd38dca12 /gcc/fortran
parent95c25cb09f58810bc520c3db469945c6a751aa32 (diff)
downloadgcc-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