[patch] Cleanup handling of UniqueExternalLinkage.

John McCall rjmccall at apple.com
Fri May 10 17:11:10 PDT 2013


On May 10, 2013, at 7:11 AM, Rafael EspĂ­ndola <rafael.espindola at gmail.com> wrote:
>>> The attached patch is a nop. It just replaces most uses of getLinkage
>>> with getSemaLinkage and getCodeGenLinkage. Some of these calls should
>>> be audited to make sure they are calling the right function, but that
>>> is probably better done in an independent patch, so this one is
>>> mechanical:
>>> 
>>> hasExternalLinkage -> hasExternalCodeGenLinkage
>> 
>> I dislike the "CodeGen" / "Sema" split here.  The semantic property that
>> IR-generation cares about is whether the declaration is permitted to be
>> the same declaration under the ODR as a hypothetical declaration in
>> another translation unit.  That's what Sema usually cares about, too;
>> I would guess that only some narrow formalistic cases really want to
>> think of e.g. vector<MyInternalType> as having external linkage.
> 
> I guess the Sema part is probably ok, since it is the part responsible
> for making
> 
> namespace {
>  void f();
>  static void f();
> }
> 
> Invalid on c++98 and valid on c++11 for example. But yes, the CodeGen
> name here is a bit odd since many parts of Sema need to reason about
> it too. Fortunately, all that we really care is if it is external or
> not. What do you think about the attached patch. Is just uses the name
> isVisibleFromAnotheTU for what was "CodeGen linkage" in the previous
> patch.

How about getFormalLinkage() and isExternallyVisible()?  Baking
"Sema" into the name seems like poor form.

John.



More information about the cfe-commits mailing list