[patch] fix pr15930

[Richard Smith]

On Tue, May 14, 2013 at 9:29 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 14 May 2013 16:10, Richard Smith <richard at metafoo.co.uk> wrote:
> > This isn't quite right. You need to scan up to the outermost such entity.
> > For instance:
> >
> > template<typename T> int *get() { static int k; return &k; }
> >
> > /*inline*/
> > int *f() {
> >   struct S {
> >     int *g() {
> >       struct T {};
> >       return get<T>();
> >     }
> >   } s;
> >   return s.g();
> > }
> >
> > Here, we should not treat get<f::S::g::T> as being externally-visible,
> but
> > if we uncomment the 'inline', then it should be externally-visible.
>
> I finally understand what you went by outermost in the bug report.
> Thanks, a new patch is attached.
>
> > (And technically, in either case, getFormalLinkage for get<...> should
> > return ExternalLinkage.)
>
> That is defect is the standard, no? In the non-inline case there is no
> way for another TU to refer to this and the current draft defines
> external linkage as
>
> * When a name has external linkage , the entity it denotes can be
> referred to by names from scopes of other translation units or from
> other scopes of the same translation unit.


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

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.

You should also be aware of core issue 1603, which brings the linkage rules
more into line with how we behave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130515/9249cedf/attachment.html>