[patch] fix pr15930

Richard Smith richard at metafoo.co.uk
Wed May 15 22:13:08 PDT 2013


On Wed, May 15, 2013 at 9:47 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> > Well, improper use of italics aside, my view is that that rule does *not*
> > define when an entity has external linkage. Instead, that text is
> describing
> > a consequence of the declaration having external linkage (and by "can be
> > referred to" it really means "you don't need to block identical entities
> in
> > different translation units from linking together").
> >
> > I do agree that the standard may not say what we want here, and isn't
> > completely clear; I filed core issue 1602 for that a few months ago for
> > exactly that. However, it's not been decided by CWG yet, and since
> (AFAICT)
> > it would only affect which diagnostics are mandatory and it would make
> > 'linkage' much more expensive to compute, there's a good chance that
> they'll
> > say it's NAD.
>
> I am not sure I follow the "more expensive" argument. Any compiler (as
> opposed to a theoretical tool that just checks if a string is valid
> c++) will have to compute something like the linkage we compute, no?


I think would be sufficient to use a globally-unique mangling for names
inside anonymous namespaces and non-inline functions (like gcc used to), or
to generate an 'externally visible' flag as a side-effect of computing the
mangled name. But you don't need to do any of that if you're not generating
code, and there are many C++-parsing tools out there which do not generate
code.


> > You should also be aware of core issue 1603, which brings the linkage
> rules
> > more into line with how we behave.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130515/4b6acaa5/attachment.html>


More information about the cfe-commits mailing list