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

[Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>]

On Sun, Jul 28, 2013 at 12:10 AM, Nathan Ridge <zeratul976@xxxxxxxxxxx> wrote:

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

I don't consider it a major drawback. It's not possible to capture all grammar constraints in AST anyway. 

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.

All lists are defined recursively in the grammar, but we flatten them in AST so that we can check the number of items ahead of time and iterate over them easier.

Regards,
Nate

-sergey 

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev