On Thu, May 23, 2013 at 9:40 AM, Rafael Espíndola < [email protected]> wrote:
> > This seems to be a step towards what I think is the right end result. We > > have two separate notions: the formal language linkage, and whether an > > entity is externally visible. To that end: > > > > (external, visible) -> ExternalLinkage > > (external, not visible) -> UniqueExternalLinkage [*] > > (internal, visible) -> not possible > > (internal, not visible) -> InternalLinkage > > (no linkage, visible) -> VisibleNoLinkage > > (no linkage, not visible) -> NoLinkage > > > > ... and the combining step takes the minimum on each axis. > > The two cases were this would produce different result from the last patch > are: > > InternalLinkage VisibleNoLinkage -> NoLinkage > UniqueExternalLinkage VisibleNoLinkage -> NoLinkage > > My patch produces InternalLinkage and UniqueExternalLinkage. Can you > think of a testcase where this would be a problem? Yes. InternalLinkage + VisibleNoLinkage is externally visible under those merging rules, and shouldn't be. Also, this doesn't match what I thought we were going to do to resolve that DR (that you take the weakest linkage of a template and its arguments for a template specialization). Why do you think these revised rules are better? What's your model?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
