On Fri, May 24, 2013 at 8:16 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> > InternalLinkage        VisibleNoLinkage       -> NoLinkage<br>
>> > UniqueExternalLinkage  VisibleNoLinkage       -> NoLinkage<br>
>> ><br>
>> > I am OK with it, but I was unable to write any testcase :-(<br>
>><br>
>> The attached patch implements your proposed semantics (but keeps the<br>
>> single bitfield representation, at least for now). Any ideas of a<br>
>> testcase we could add?<br>
><br>
><br>
> The former case goes from externally visible to not-externally-visible. You<br>
> should be able to catch that by looking at the CodeGen output.<br>
<br>
</div>No, with the old patch we produce InternalLinkage and<br>
UniqueExternalLinkage which are both not externally visible.  Any<br>
observable difference should come from getFormalLinkage now returning<br>
NoLinkage instead of InternalLinkage or ExternalLinkage.<br>
<div class="im"><br>
> The latter case goes from external linkage to no linkage. That should cause<br>
> us to error if we use the address of a function with that linkage as a<br>
> template argument. (I'm not 100% sure that's the right behavior, but it<br>
> seems like it should be observable at least.)<br>
<br>
</div>This worked, thanks!<br>
<br>
Right now only the UniqueExternalLinkage is tested, but the<br>
InternalLinkage case will be automatically tested too once we<br>
implement the c++11 rule that entities in anonymous namespaces have<br>
internal linkage.</blockquote><div><br></div><div>I'm not a fan of the +1 / -1s which have appeared everywhere. Can you encapsulate these somehow?</div></div>