Anonymous Namespaces

[Chris Lattner]

On 1 Feb 2004, Gabriel Dos Reis wrote:
> | > And replacing "being declared in an unnamed
> | > space" with "being declared as static" (with static meaning what is
> | > means in C and C++), changes the meaning of well-defined programs.
> |
> | Which I understand and am _not suggesting_.
>
> So, exactly what are you suggesting with respect to the "unnamed
> namespace" as far as GCC is concerned?

Ok, I will put this in GCC terms.  The "right" solution in my mind is to
seperate the front-end notion of internal linkage from the back-end notion
of internal linkage.  I am guessing this will not happen, so here is a
proposal that I think would be acceptable to the GCC community.  Note that
my knowledge of GCC is pretty limited (and I know nothing specifically
about the C++ parser), so there are _likely_ to be technical problems with
this decription.

Currently GCC uses TREE_PUBLIC(x) == false to indicate that something has
internal linkage.  From what I gather of your description, I assume that
the C++ parser uses this to determine whether something should be ignored
for the purposes of name lookup.  I am _not_ proposing that we change the
meaning of this or any other existing flag at all.

Instead, add a new flag, TREE_REALLY_PUBLIC (following the C++ front-end's
example of DECL_REALLY_EXTERN), which is set to false for entities in an
anonymous namespace.  The inliner, code expander, etc can use this flag to
determine whether something REALLY is public and should be exported.  If
not, it should be treated as though TREE_PUBLIC were false.  This
localizes information about unnamed namespaces in the C++ front-end, so
that you don't need to "teach the programmed inliner about unnamed
namespace", as you propose.  If other front-ends rely on the TREE_PUBLIC
flag for their parsing or semantic analysis, they won't be effected
either, because the flag would never be set to false for them.
Additionally, the horrible "random" names added to the symbols in
anonymous namespaces can be eliminated, as they are in LLVM.

The "right" solution I mention above, would involve the C++ parser setting
TREE_PUBLIC to false for entities in anonymous namespaces, and using some
other (C++ specific) flag to control name lookup functions.  I am guessing
that this is unlikely to fly though, because it would require changing
more of the C++ front-end.  As such, I am specifically not suggesting
this.

If this doesn't make sense, or if I made technical errors in my
description, please let me know.  I think it should be clear that either
implementation _cannot_ effect name lookup at all, because it does not
change the value of any existing flag.

> | Please please please read my
> | emails more carefully, or perhaps with more of an open mind.
>
> If I was as open minded as you seem to imply, I would have said "Just
> any bozo" and ignored your message.  Or is it essential for you to
> believe that you're discussion something with less open minded people?

I am going to ignore this and the other inflamatory comments and insults
you use, as they are meaningless in the technical discussion at hand.

> | We are _correct_, as is
> | GCC.  The only difference is that GCC generates worse code, which I think
> | is silly.  You never responded to my question about what kind of code GCC
> | 3.4 generates for your example.
>
> For the purpose of comparing apples and oranges?  How do you rewrite
> the example I gave so that we can compare apples with apples and
> oranges with oranges?  Because if
>
>    Unlike the GCC tree representation, LLVM is not intended to follow any
>    particular source-level language semantics (it is language-independent).
>
> then the comparison is pointless.

No it isn't.  In fact, the whole point is that the LLVM _optimizer_ is
capable of doing things the GCC _optimizer_ is not.  It does not matter
how this information is represented, the point is functionality.  For the
n'th time, the C++ name-lookup functionality is not effected at all
(and for the third time, you never responded with the code GCC 3.4
produces on your example!).

> | And I tried to explain exactly why the transformation is safe, and have
> | _demonstrated_ that it is for you.  What exactly do you need to be
> | convinced?
>
> I do not want you convince me of anything -- conviction is when religion
> matters.  If you can't prove your transformation is correct as far as
> C++ semantics is concerned, let's move on something different.

I believe that my description above should convince you that the semantics
of C++ are preserved, at least in the absence of export (I freely admit
that I don't know enough about export to judge how this would interact
with it).  If you still don't believe me, please provide a counterexample,
or explain _why_.

> I was wanting to make sure:
>   (1) we're talking of the same thing -- we don't, as you said your
>       notion of internal linkage is not that of a program source level
>       and at the same time you claim it is exactly like "static" in C++
>       (which it can't be since that would lead to something different).

We are not talking about the same thing, apparently.  I am not talking
about "marking entities in anonymous namespaces as 'static'", to
paraphrase you.

>   (2) we're comparing oranges to oranges -- we don't, as you said your
>       compiler follows no language semantic, whereas g++ ought to
>       follow language semantics.
>
> So, the question is what are you transforming according to what
> semantics and what are you demonstrating?

The point is that what LLVM does is irrelevant to this discussion, as GCC
is not LLVM.  While I certainly can explain how LLVM works, that is better
done on an LLVM list than on a GCC list.  Alternatively you can read some
of the extensive documentation we have here:
http://llvm.cs.uiuc.edu/Documentation.html

What really matters for the sake of this discussion is what the
_optimizer_ does.

> |  Note _again_ that I have said _nothing_ about turning things
> | in anonymous namespaces into 'static' objects!!
>
> giving internal linkage to members of unnamed namespace was precisely
> the question of the original poster, that generated this traffic.

_which is not the same as marking it as static in the front-end_!

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/