[patch] Fix linkage computation for derived types in inline functions

Richard Smith richard at metafoo.co.uk
Thu May 23 11:56:57 PDT 2013


On Thu, May 23, 2013 at 9:40 AM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130523/06901d14/attachment.html>


More information about the cfe-commits mailing list