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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Fri May 24 08:16:59 PDT 2013


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

New patch is attached.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 14713 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130524/dc91c96d/attachment.obj>


More information about the cfe-commits mailing list