Jason,
This is from pr94426, which is fallout from my pr94147 fix.
You added the following to no_linkage_check as part of
2018-11-12 Jason Merrill <ja...@redhat.com>
Implement P0315R4, Lambdas in unevaluated contexts.
/* Lambda types that don't have mangling scope have no linkage. We
check CLASSTYPE_LAMBDA_EXPR for error_mark_node because
when we get here from pushtag none of the lambda information is
set up yet, so we want to assume that the lambda has linkage and
fix it up later if not. We need to check this even in templates so
that we properly handle a lambda-expression in the signature. */
if (LAMBDA_TYPE_P (t)
&& CLASSTYPE_LAMBDA_EXPR (t) != error_mark_node
&& LAMBDA_TYPE_EXTRA_SCOPE (t) == NULL_TREE)
return t;
The comment suggests that those with a mangling scope do (sometimes?)
have linkage. Under what circumstances does the std give lambdas
linkage? They are 'unique, unnamed non-union class type[s]' 7.5.5.1/1
The wording in 6.3/14 suggests that even in:
inline auto var = []{};
the multiple definitions of 'var' in different TUs could have different
types.
'In particular, lambda-expressions (7.5.5) appearing in the type of D
may result in the different declarations having distinct types,'
so they can be ODR-same, but not TYPE-same. Comparing 'typeid (var)'
acrosss TU boundaries gives an unspecified result.
I can see why implementationwise we might want the above to have a
pseudo-external linkage -- IIRC we don't correctly give templates
instantiated from non-external types internal linkage, so we have to
either guarantee unique mangling or guarantee same typeness.
What am I missing?
nathan
--
Nathan Sidwell
