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

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

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