Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] representing 'decltype(e)::name' in the AST without breaking API

> 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,


is valid, but


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.


Back to the top