On May 22, 2013, at 11:48 PM, Richard Smith <[email protected]> wrote:
> On Wed, May 22, 2013 at 9:34 PM, John McCall <[email protected]> wrote:
> On May 22, 2013, at 9:10 PM, Rafael Espíndola <[email protected]>
> 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 returns 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.
> and template arguments *can* involve certain flavors of declaration lacking
> external linkage these days :-/
I didn't say the rule was still always true. :)
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
