On May 10, 2013, at 7:11 AM, Rafael Espíndola <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
