On Tue, May 14, 2013 at 9:29 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.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="im">On 14 May 2013 16:10, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> This isn't quite right. You need to scan up to the outermost such entity.<br>
> For instance:<br>
><br>
> template<typename T> int *get() { static int k; return &k; }<br>
><br>
> /*inline*/<br>
> int *f() {<br>
>   struct S {<br>
>     int *g() {<br>
>       struct T {};<br>
>       return get<T>();<br>
>     }<br>
>   } s;<br>
>   return s.g();<br>
> }<br>
><br>
> Here, we should not treat get<f::S::g::T> as being externally-visible, but<br>
> if we uncomment the 'inline', then it should be externally-visible.<br>
<br>
</div>I finally understand what you went by outermost in the bug report.<br>
Thanks, a new patch is attached.<br>
<div class="im"><br>
> (And technically, in either case, getFormalLinkage for get<...> should<br>
> return ExternalLinkage.)<br>
<br>
</div>That is defect is the standard, no? In the non-inline case there is no<br>
way for another TU to refer to this and the current draft defines<br>
external linkage as<br>
<br>
* When a name has external linkage , the entity it denotes can be<br>
referred to by names from scopes of other translation units or from<br>
other scopes of the same translation unit.</blockquote><div><br></div><div>Well, improper use of italics aside, my view is that that rule does *not* define when an entity has external linkage. Instead, that text is describing a consequence of the declaration having external linkage (and by "can be referred to" it really means "you don't need to block identical entities in different translation units from linking together").</div>
<div><br></div><div>I do agree that the standard may not say what we want here, and isn't completely clear; I filed core issue 1602 for that a few months ago for exactly that. However, it's not been decided by CWG yet, and since (AFAICT) it would only affect which diagnostics are mandatory and it would make 'linkage' much more expensive to compute, there's a good chance that they'll say it's NAD.</div>
<div><br></div><div>You should also be aware of core issue 1603, which brings the linkage rules more into line with how we behave.</div></div>