[cfe-dev] ElaboratedType, QualifiedNameType and TypenameType.

[Douglas Gregor]

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

> Il 22/03/2010 23:27, Douglas Gregor ha scritto:
>> 
>> 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.
> 
> I guess I've misunderstood something...
> 
> Tell me where I'm wrong:
> 
> - non qualified enum X would be represented as ElaboratedType of
> EnumType (exactly as now)

It's an ElaboratedType whose canonical type is an EnumType.

> - qualified not dependent enum A::X would be represented as
> ElaboratedType of EnumType using the (to be inserted) optional NNS

Yes, same thing (the canonical type is an EnumType).

> - qualified dependent enum A::X ???
> 
> Here I'm lost, from your previous message I believed you want to leave
> it as now (ElaboratedType of TypenameType), but now I thought I've
> misunderstood (as PR5681 is related to this case).


I wanted this to be an ElaboratedType... but it's a completely different kind of elaborated type than the first two cases. Actually, I'm coming around to the idea of TypenameType morphing into some kind of DependentQualifiedNameType node, which covers typename/class/struct/enum. The lookup is different for those cases, but otherwise it gets the point across.

	- Doug