Re: cp tree question

[Stefan Strasser <sstrasser at systemhaus-gruppe dot de>]

this is additional information on this subject I sent here two days ago 
which caused the dump-translation-unit discussion.
answers to bug 19073 please, not here.

---
ok, I took a closer look at this.
we all agree that type_decls(even c++ implicit ones) should be in 
cp_binding_level::names, don't we?

decls get added to this list by name-lookup.c add_decl_to_level(), which 
gets called by name-lookup.c:pushdecl()
pushdecl() checks if there is already a binding for the decl(via 
namespace_binding()).
if there is(which is the case for the implicit type decls in current 
version), it only calls add_decl_to_level() under certain circumstances, 
one of these is: not being a TYPE_DECL.

in gcc version 3.3.4(which doesn't have this problem) 
namespace_binding() returns 0, there is no binding, in current CVS there is.
so, why is this?

because of these lines in 
name-lookup.c:set_identifier_type_value_with_scope:
	  if (binding->value)
	    supplement_binding (binding, decl);
	  else
	    binding->value = decl;

I understand what they're doing but I don't understand why they are at 
this point and were introduced in decl.c version 1.1114.
the cvs log message doesn't contain anything that's useful to me either.
why are these lines there? before this there was no assignment to 
binding->value at all.

Thanks for your help

---


Stefan Strasser schrieb:
> Good morning,
> I'm wondering if it is a bug or desired behaviour that, in the current
> release version of gcc, TREE_CHAIN()ing the cp_namespace_decls() result
> doesn't bring up type_decl nodes of c++ enum's, but gcc version 3.3.4 does?
> have they been moved into another list?
>
> you can easily check this with -fdump-translation-unit on the code "enum
> blah{};". there is no blah in the .tu file with version 3.4.3.
>
> (don't put any enumerators in there because so the type_decl node gets
> queued by the DECL_TYPE() of the enumerator node. but it's not in
> cp_namespace_decls())
>
> thanks for your help,



--
Stefan Strasser