Re: [cdt-dev] representing 'decltype(e)::name' in the AST without breaki

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

> 1. Introduce ICPPASTNestedNameSpecifier interface. 
> 2. Introduce ICPPASTNestedNameSpecifier  
> ICPPASTQualifiedName.getQualifier() method 
> 3. Deprecate ICPPASTQualifiedName.getNames() method. This method should  
> continue to work for names that are composed of IASTName's.  
> For 'decltype(e)::name' it may return an array of two elements where  
> the first element is a placeholder that formally implements IASTName  
> interface but throws UnsupportedOperationException in most methods  
> except toCharArray() and toString(). 

Let's call this proposal (A).

I like this.

> Here is a slightly modified proposal that avoids the recursive nature  
> of ICPPASTNestedNameSpecifier. 
>  
> 1. Introduce ICPPASTNameSpecifier interface. Both AST names and  
> decltype specifiers should implement this interface. 
> 2. Introduce ICPPASTNameSpecifier[] ICPPASTQualifiedName.getQualifier()  
> method. 

Let's call this proposal (B).

I don't think this represents the grammar of the language as faithfully
as (A). A decltype-specifier is only allowed as the first element of
a qualified name. So, for example,

decltype(A)::B::C

is valid, but

A::decltype(B)::C

is not. Proposal (A) encodes this rule in the AST, while proposal (B)
would allow a valid AST to be built for A::decltype(B)::C and leave 
it to semantics code to sort out that it's not valid. I think the
former is preferrable.

Is there anything wrong with the recurive nature of the proposed
ICPPASTNestedNameSpecifier? In the grammar in the C++ standard,
the 'nested-name-specifier' production is recursive, and our AST has
largely been corresponding to that grammar.

Regards,
Nate