aboutsummaryrefslogtreecommitdiff
path: root/gcc/fortran/simplify.c
diff options
context:
space:
mode:
authorNathan Sidwell <nathan@acm.org>2020-04-13 06:35:33 -0700
committerNathan Sidwell <nathan@acm.org>2020-04-13 06:35:33 -0700
commit8d213cbbe1856e6088282aa0076646cec694b030 (patch)
treee97f39aaaecacbba02763175ae240943ebb6b5cd /gcc/fortran/simplify.c
parentefc1f3577f38bb213b313661c025ac965baee953 (diff)
downloadgcc-8d213cbbe1856e6088282aa0076646cec694b030.zip
gcc-8d213cbbe1856e6088282aa0076646cec694b030.tar.gz
gcc-8d213cbbe1856e6088282aa0076646cec694b030.tar.bz2
c++: lambdas with internal linkage are different to no-linkage [PR94426]
My fix for 94147 was confusing no-linkage with internal linkage, at the language level. That's wrong. (the std is confusing here, because it describes linkage of names (which is wrong), and lambdas have no names) Lambdas with extra-scope, have linkage. However, at the implementation-level that linkage is at least as restricted as the linkage of the extra-scope decl. Further, when instantiating a variable initialized by a lambda, we must determine the visibility of the variable itself, before instantiating its initializer. If the template arguments are internal (or no-linkage), the variable will have internal linkage, regardless of the linkage of the template it is instantiated from. We need to know that before instantiating the lambda, so we can restrict its linkage correctly. * decl2.c (determine_visibility): A lambda's visibility is affected by its extra scope. * pt.c (instantiate_decl): Determine var's visibility before instantiating its initializer. * tree.c (no_linkage_check): Revert code looking at visibility of lambda's extra scope. ` gcc/cp/ * g++.dg/cpp0x/lambda/pr94426-[12].C: New. * g++.dg/abi/lambda-vis.C: Drop a warning. * g++.dg/cpp0x/lambda/lambda-mangle.C: Lambda visibility on variable changes. * g++.dg/opt/dump1.C: Drop warnings of no import.
Diffstat (limited to 'gcc/fortran/simplify.c')
0 files changed, 0 insertions, 0 deletions