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

[Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx>]

I don't think we need any API-breaking changes. We can do something like:

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

-sergey

On Tue, Jul 23, 2013 at 11:44 PM, Nathan Ridge <zeratul976@xxxxxxxxxxx> wrote:

Bug 380751 [1] concerns constructs of the form 'decltype(e)::name'.

Currently we cannot represent these in the AST, because our representation
for things of the form 'A::B' (and 'A::B::C' etc.) is an IASTQualifiedName,
which stores a sequence of IASTNames. This was well-suited for representing
qualified names in C++98, but it cannot represent 'decltype(e)::name'
because 'decltype(e)' is not an IASTName.

If maintaining API compatibility were not an issue, the approach I would
suggest for supporting 'decltype(e)::name' would be to refactor the
representation of qualified names to resemble more closely the grammar in
the C++ standard. Specifically:
  - Instead of storing a sequence of IASTNames, an IASTQualifiedName could
    store just the last IASTName, and an IASTNestedNameSpecifier (see below)
    representing everything before the last.
  - Introduce a new AST node IASTNestedNameSpecifier to represent the
    'nested-name-specifier' production rule (see [gram.expr]). This could
    be either another IASTQualifiedName representing the names before the
    last one, or a decltype-specifier representing a 'decltype(e)'.

However, I don't know how to do the above without breaking the
IASTQualifiedName API.

I can think of a couple of alternative approaches that don't involve
breaking API, but they're not very satisfying:

 1) We could make 'decltype(e)' be an IASTName, with its resolveBinding()
    being the type in question, or null if said type is not a binding.
    However, this would be misleading (as 'decltype(e)' is *not* a "name"
    for any reasonable definition of "name" that I can think of), and it
    would not correspond to the grammar in the C++ standard. Also, it
    won't work nicely for dependent types, for which we don't know whether
    they are a binding or not (currently TypeOfDependentExpression is
    *not* a binding, and I'm not sure if it's a good idea to try to make
    it one).

 2) We could introduce a new interface, IASTCXX11QualifiedName (extending
    IASTName), and use it to represent things of the form
    'decltype(e)::name' (and 'decltype(e)::name1::name2', etc.), but
    continue using IASTQualifiedName for all other qualified names.
    However, this would be messy, and more work for the parser to build
    the correct variant and for semantics code to work with the two
    variants.

Any suggestions?

(A slightly related question is whether there will ever be a CDT 9.0. If
yes, and not too far in the future, perhaps we can just wait for it and
make the API-breaking change then.)

Thanks,
Nate

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=380751
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev