[patch] fix pr15930

[Richard Smith]

Patch looks good, but don't you need to also change all the other calls to
QualType::getLinkageAndVisibility? In C++14 at least, a no-linkage type can
completely leak out of a function and be used as a type of a non-type
template parameter. For instance:

inline auto f() {
  struct S {};
  return S();
}
template<decltype(f())*> struct X { X() {} };
X<nullptr> x;

Right now, this incorrectly generates @x as an internal-linkage symbol. You
can probably observe the same bug in C++11 by passing S to a template like
this:

template<typename T> struct Outer { template<T *p> struct Inner { ... }; };

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.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130515/ab942a90/attachment.html>