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

[Richard Smith]

On Thu, May 23, 2013 at 3:02 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > By revised rules you mean the one you proposed, making
> >
> > 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.

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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130523/019e676c/attachment.html>