[patch] Fix linkage computation for derived types in inline functions

[Richard Smith]

On Thu, May 23, 2013 at 12:23 AM, John McCall <rjmccall at apple.com> wrote:

> On May 22, 2013, at 11:48 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Wed, May 22, 2013 at 9:34 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On May 22, 2013, at 9:10 PM, Rafael Espíndola <rafael.espindola at gmail.com>
>> wrote:
>> > John noticed that the fix for pr15930 (r181981) didn't handle indirect
>> > uses of local types. For example, a pointer to local struct, or a
>> > function that return it.
>> >
>> > One way to implement this would be to recursively look for local
>> > types. This would look a lot like the linkage computation itself for
>> > types.
>> >
>> > To avoid code duplication and utilize the existing linkage cache, this
>> > patch just makes the computation of "type with no linkage but
>> > externally visible because it is from an inline function"  part of the
>> > linkage computation itself.
>>
>> Hmm, there's a subtle change in assumptions here, because the
>> linkage enum is no longer a simple continuum.
>>
>> Previously, merging two linkages just meant taking their minimum.
>> For example, consider the type T(*)(U):
>>   - it has no linkage if either T or U has no linkage; or else
>>   - it has internal linkage if either T or U has internal linkage; or else
>>   - it has unique external linkage if either T or U has unique external
>>     linkage; or else
>>   - it has external linkage.
>>
>> But if T has VisibleNoLinkage and U has NoLinkage, InternalLinkage,
>> or UniqueExternalLinkage, then T(*)(U) has NoLinkage.
>>
>
> This seems to be a step towards what I think is the right end result. We
> have two separate notions: the formal language linkage, and whether an
> entity is externally visible. To that end:
>
> (external, visible) -> ExternalLinkage
> (external, not visible) -> UniqueExternalLinkage [*]
> (internal, visible) -> not possible
> (internal, not visible) -> InternalLinkage
> (no linkage, visible) -> VisibleNoLinkage
> (no linkage, not visible) -> NoLinkage
>
> ... and the combining step takes the minimum on each axis.
>
> If we're going to three bits anyway, it would make more sense to me to
> separate out the two notions.
>
>
> That makes sense to me.
>
> [*] Templates instantiated with non-visible arguments are also technically
> in this bucket, and we give them InternalLinkage or NoLinkage, but there's
> a DR pending which might change the linkage of those specializations to
> match our behavior.
>
>
> Okay.
>
>  (This is slightly artificial; IIRC, the notion of types having linkage is
>> not in the standard.  But it's the right computation for rules that *are*
>> in the standard directly, like "template arguments can't involve a
>> declaration lacking external linkage".)
>>
>
> Per the standard, (some) types do have linkage...
>
>
> I thought that was just the declared types.
>

Assuming I'm not misunderstanding what you're looking for here, this is
handled by N3690 [basic.link]p8: "A type is said to have linkage if and
only if ...", which covers all (canonical) types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130523/d853a14b/attachment.html>