On Fri, May 24, 2013 at 8:16 AM, Rafael Espíndola < [email protected]> wrote:
> >> > 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. I'm not a fan of the +1 / -1s which have appeared everywhere. Can you encapsulate these somehow?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
