[cfe-dev] ElaboratedType, QualifiedNameType and TypenameType.

[Douglas Gregor]

On Mar 22, 2010, at 3:15 PM, Abramo Bagnara wrote:

> Il 22/03/2010 21:10, Douglas Gregor ha scritto:
>> 
>> 
>> There is an option (C). Here's what I think each of the types should
>> do:
>> 
>> ElaboratedType: Should handle all elaborated-type-specifiers in the
>> C++0x sense, which means a type referenced via the
>> enum/class/struct/union keyword. This class should be extended with
>> an optional NestedNameSpecifier to handle qualified
>> elaborated-type-specifiers, ideally in a implementation-detail base
>> class so that we don't pay a size penalty for "struct X". Getting
>> this right should make fixing PR5681 trivial.
> 
> Why don't have ElaboratedType of QualifiedNameType instead of optional NNS?
> 
> It seems to me it would be more congruent:
> 
> 1) ElaboratedType of EnumType (for non qualified enum X)
> 2) ElaboratedType of QualifiedNameType of EnumType (for qualified not
> dependent enum A::X)
> 3) ElaboratedType of TypenameType (for qualified dependent enum A::X)


The problem is that elaborated-type-specifiers in the C++ language have very different name-lookup semantics than QualifiedNameType/TypenameType (C++ [basic.lookup.elab]), so it's cleaner to have the *Type nodes match up with language constructs. That's actually what

	http://llvm.org/bugs/show_bug.cgi?id=5681

is about: we're using ElaboratedType as an outer level of sugar (more like what you're proposing than what I'm proposing), and because of that we get name-lookup wrong when we instantiate the node that the ElaboratedType points to. Instead, we should have enough information in the ElaboratedType itself to perform instantiation and elaborated-type-specifier name lookup without having to dig deeper into the type that the ElaboratedType points to.

	- Doug