[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