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

[Richard Smith]

On Fri, May 24, 2013 at 8:16 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> >> > InternalLinkage        VisibleNoLinkage       -> NoLinkage
> >> > UniqueExternalLinkage  VisibleNoLinkage       -> NoLinkage
> >> >
> >> > I am OK with it, but I was unable to write any testcase :-(
> >>
> >> The attached patch implements your proposed semantics (but keeps the
> >> single bitfield representation, at least for now). Any ideas of a
> >> testcase we could add?
> >
> >
> > The former case goes from externally visible to not-externally-visible.
> You
> > should be able to catch that by looking at the CodeGen output.
>
> No, with the old patch we produce InternalLinkage and
> UniqueExternalLinkage which are both not externally visible.  Any
> observable difference should come from getFormalLinkage now returning
> NoLinkage instead of InternalLinkage or ExternalLinkage.
>
> > The latter case goes from external linkage to no linkage. That should
> cause
> > us to error if we use the address of a function with that linkage as a
> > template argument. (I'm not 100% sure that's the right behavior, but it
> > seems like it should be observable at least.)
>
> This worked, thanks!
>
> Right now only the UniqueExternalLinkage is tested, but the
> InternalLinkage case will be automatically tested too once we
> implement the c++11 rule that entities in anonymous namespaces have
> internal linkage.


I'm not a fan of the +1 / -1s which have appeared everywhere. Can you
encapsulate these somehow?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130524/eb71fdc0/attachment.html>