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

Richard Smith richard at metafoo.co.uk
Wed May 22 23:48:35 PDT 2013


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 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.

[*] 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.

(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... and template arguments
*can* involve certain flavors of declaration lacking external linkage these
days :-/

Also, did you check that all of the bit-fields you increased still pack
> efficiently?
>
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130522/7eabbc67/attachment.html>


More information about the cfe-commits mailing list