Static linkage and anonymous namespace

[Martin von Loewis]

>   But why can't we just make the definitions have internal linkage if
> they're in an anonymous namespace?  Why do we need to introduce the
> TREE_PRIVATE bit?  In other words, at some point the compiler decides
> whether to make things have internal or external linkage.  Why doesn't
> it just use the DECL_CONTEXT (recursively looking at parent contexts)
> to see what linkage the thing should get?

Good questions. As far as I can tell, there are two reasons:

1. Not all members of an anonymous namespace can have internal
   linkage. Specifically, foo in

   namespace{
     extern "C" foo(){}
   }

   can be called from other translation units. This is because of the
   way anonymous namespaces and C linkage are defined. Maybe this is
   really a defect, maybe this is intentional.

2. Some members of named namespaces also get this internal linkage.
   Given

   namespace {
     struct Foo{};
   }

   we get this on

   void print(Foo&){}
   std::vector<Foo> vfoo;

   Other translations can't use these objects/functions, since they
   can't provide the parameters. Not making them internal means to
   risk linkage problems again, if some other translation unit has the
   same sequence of tokens.

   I started computing whether an object is related to anonymous
   namespaces, i.e. analyze template parameters and argument types.  I
   then realized that I reimplemented the mangling algorithm.

So, I think the current patch does exactly what it is supposed to do:
all assembler names that contain the supposedly unique anonymous
namespace name should have internal linkage.

Maybe the implementation of that is messy; I'll take advise on how to
improve it.

Martin