Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory

[Mark Mitchell <mark at codesourcery dot com>]

Richard Guenther wrote:

[Nathan, Jason, please see below for question for you as C++ maintainers.]

>> | 2006-12-09  Richard Guenther  <rguenther@suse.de>
>> | 
>> | 	* include/bits/stl_tree.h (struct _Rb_tree): Qualify types.
>> | 
>> | 	* g++.dg/warn/implicit-typename1.C: Qualify types.
>> | 	* g++.dg/parse/crash12.C: Likewise.
>> | 	* g++.dg/tree-ssa/pr22444.C: Likewise.
>>
>> [...]
>>
>> Thanks for doing this.  Please check it in.
> 
> I have applied the g++.dg parts only, libstdc++ needs some more fixing.

I think this we may be moving too quickly on this.

First, I don't think it's 100% clear that this code is invalid, though I
agree that that's a reasonable interpretation.  G++ and EDG agree that
this code is valid:

  struct S {
    struct T {};
    T T();
  };

so, like it or not, name lookup does honor the stat hack, and there's an
argument that for:

  struct T {};
  struct S {
    T T();
  };

name lookup for the T appearing as a type-specifier would still find the
outer T, and that therefore the binding to the member function T does
not affect validity.

More importantly, we know that this code is in our testsuite, in
libstdc++, and accepted by EDG -- all of which suggests that this
construct is likely in relatively widespread use.  I'm not sure that
it's a good tradeoff to break that code for the sake of a diagnostic
which is explicitly not required by the standard.  There's no inherent
problem with accepting the code, in the sense that the semantics G++ is
implementing could be well-defined, if we chose to do so, and in that we
are not changing the meaning of an well-formed program.

I think that we should first check with the core reflector to see if
there is consensus that this code is indeed invalid.  If that consensus
does not exist, then we certainly should not change G++.  If everyone
agrees that this code is invalid, then we will have to weigh the
benefits of breaking the code against the costs.  It would not be hard
to preserve the existing behavior, and still solve Richard's problem.

Nathan, Jason, what do you think?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713