Re: Anonymous Namespaces

[Alexandre Oliva <aoliva at redhat dot com>]

I'm sorry to resurrect this thread, but I'm missing one bit here, and
I could use some enlightenment.

On Jan 31, 2004, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Chris Lattner <sabre@nondot.org> writes:

> | Yes, we use the GCC "3.4" parser, so if it does, we do.  We also don't
> | support export yet.  Regardless, if export was implemented, and an entity
> | was not involved with an exported template, it should still be marked as
> | internal.

> You can't have that information availabale at parsing time.  You'd
> need to postpone the tramsutation to link time.  The reason is that,
> the instantiation of exported template can trigger  instantiation in
> chains and those usually implies name lookup  -- which will happen at
> sort of "link time"  when the different translation units are being
> combined together.

So, let's consider two alternatives about the name defined within an
anonymous namespace: either it's a template, or it's a non-template.

Here's my reasoning.  Please point out any flaws in it:

- If it's not a template, then the reference to the symbol is either
  template-independent (so it's bound at parse time, and we can
  determine immediately that the name can't be marked as local to the
  translation unit), or it's referenced for being a template argument
  passed to the exported template (in which case we know it can't be
  used as an argument to the exported template in another translation
  unit, because you can't reference the name in another unit, so you
  can't get to that particular exported template instantiation, so the
  name can remain local to the translation unit as well)

- If it is a template, either its arguments are template-dependent, or
  they aren't.  The latter case can be handled just like the
  non-template case.  The former, however, is the tricky one, and the
  only one I could think of that might require us to make names in
  anonymous namespaces visible outside the translation unit.

But then, I still can't think of a scenario in which this would
actually occur.  It seems to me that, in every case, we can tell
whether any template instantiations we actually emit within a
translation unit may need to be made globally visible or not, and from
those that are, proceed to the transitive closure of symbols in
anonymous namespaces referenced by other such symbols that need to get
global visibility.

There is one scenario that is odd, though: an exported template that
references a non-exported template in a template-dependent way, and
the non-exported template references a non-template.  Hmm...  This is
a bit like the first scenario, isn't it?  But in this case we do have
to make the non-template symbol globally visible, such that
instantiations of the non-exported template can get to it.


Still, it seems to me that we *can* determine whether a symbol in an
anonymous namespace might be referenced from other translation units,
without having to look at any other translation units, or having to
wait until link time.  What am I missing?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer