[GCC-XML] last commit

[Brad King]

Brad King wrote:
> This is very strange indeed.  I reduced the example to just
> 
>   namespace N {
>     struct A {};
>   #if 1
>     struct B0 { const A a; };
>   #endif
>     struct B  { const A a; };
>   }
> 
> If you switch the "1" to a "0" then all the decls in "A" show up.  I
> added some debugging output to the dump code.  GCC doesn't even have an
> internal representation for the missing decls.  Note the only difference
> is whether a struct whose _name_ has at least two characters contains a
> _const_ member of type A.  Even stranger, if it is put outside a namespace:
> 
>   struct A {};
>   struct B  { const A a; };
> 
> then the length of the name does not matter.  Just having struct B is
> enough to block the decls.  By commenting it out they all show up.
> 
> This must be some strange quirk in the GCC parser implementation.
> Unfortunately we cannot report this as a bug to GCC folks unless we can
> produce a C++ example that won't compile.

I just had some time to track this down.  It's not a GCC problem but in
fact a subtle bug introduced by the previous commit.  It started doing
the lazy declarations during the dump, so the order mattered.  Doing the
implicit declarations of B or B0 recursively does them for A too if they
are not already done.  Doing the recursive implicit declarations during
the xml dump seems to be a bad time.  The reason the name of B v. B0
affected things was simply the order resulting from the class name hash.

For now I've removed the change and re-opened the original bug:

  http://www.gccxml.org/Bug/view.php?id=7148

I'll have to find a better place to get the implicit declarations done
before the dump.

-Brad