On Wed, May 22, 2013 at 9:34 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On May 22, 2013, at 9:10 PM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
> John noticed that the fix for pr15930 (r181981) didn't handle indirect<br>
> uses of local types. For example, a pointer to local struct, or a<br>
> function that returns it.<br>
><br>
> One way to implement this would be to recursively look for local<br>
> types. This would look a lot like the linkage computation itself for<br>
> types.<br>
><br>
> To avoid code duplication and utilize the existing linkage cache, this<br>
> patch just makes the computation of "type with no linkage but<br>
> externally visible because it is from an inline function"  part of the<br>
> linkage computation itself.<br>
<br>
</div></div>Hmm, there's a subtle change in assumptions here, because the<br>
linkage enum is no longer a simple continuum.<br>
<br>
Previously, merging two linkages just meant taking their minimum.<br>
For example, consider the type T(*)(U):<br>
  - it has no linkage if either T or U has no linkage; or else<br>
  - it has internal linkage if either T or U has internal linkage; or else<br>
  - it has unique external linkage if either T or U has unique external<br>
    linkage; or else<br>
  - it has external linkage.<br>
<br>
But if T has VisibleNoLinkage and U has NoLinkage, InternalLinkage,<br>
or UniqueExternalLinkage, then T(*)(U) has NoLinkage.<br></blockquote><div><br></div><div>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:</div>
<div><br></div><div>(external, visible) -> ExternalLinkage</div><div>(external, not visible) -> UniqueExternalLinkage [*]</div><div>(internal, visible) -> not possible</div><div>(internal, not visible) -> InternalLinkage</div>
<div>(no linkage, visible) -> VisibleNoLinkage</div><div>(no linkage, not visible) -> NoLinkage</div><div><br></div><div>... and the combining step takes the minimum on each axis.</div><div><br></div><div>If we're going to three bits anyway, it would make more sense to me to separate out the two notions.</div>
<div><br></div><div>[*] 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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(This is slightly artificial; IIRC, the notion of types having linkage is<br>
not in the standard.  But it's the right computation for rules that *are*<br>
in the standard directly, like "template arguments can't involve a<br>
declaration lacking external linkage".)<br></blockquote><div><br></div><div>Per the standard, (some) types do have linkage... and template arguments *can* involve certain flavors of declaration lacking external linkage these days :-/</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, did you check that all of the bit-fields you increased still pack<br>
efficiently?<br>
<span class="HOEnZb"><font color="#888888"><br>
John.</font></span></blockquote></div><br>