[cfe-dev] Dependent types representation in the NestedNameSpecifier

[David Rector via cfe-dev]

Good point.  At best implementing the second NNS as a dependent prefix + Identifier is redundant, since DependentNameType could already store this info, but you’re right that it would be more consistent with the first NNS you cite (the DependentTemplateSpecializationType) to implement the second NNS as a DependentNameType.

It seems like the Prefix field of NestedNameSpecifier is the root cause of this redundancy, and perhaps more general confusion.  I don’t think it is needed.  Perhaps an NNS should only store a simple PointerUnion of the various name kinds.  If we really want to keep the getPrefix() method we can define it as accessing the the properly cast pointer’s getQualifier() method.

DependentNameTypes/DependentTemplateSpecializationTypes each store their prefix on their own, so do ElaboratedTypes, so written prefixes for types would be covered, if I’m not mistaken.

The only non-trivial change I think needed would be for handling namespaces, for which we need to pair a written prefix with the NamespaceDecl or NamespaceAliasDecl.  In those cases, I think, we just define a "NamespaceName" class to handle the pairing of the decl and written qualifier, then allocate the NamespaceName as a trailing object of its NestedNameSpecifier in the applicable Create functions.

By getting rid of the Prefix field in this way we would be forced to define the second example you cite via a DependentNameType, making it more consistent with other the first example you cite, and would also save a little space in most cases.

I am probably missing something though.  In any case you raise a good point,

- Dave

> On Jul 20, 2020, at 5:21 AM, Eduardo Caldas via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> template <class T>
> void f() {
>   // Case 1:
>   typename T::template U<int>::type x;
>   // 'T::template U<int>' in the NNS is a DependentTemplateSpecializationType.
> 
>   // Case 2:
>   typename T::U::type y;
>   // 'T::U' in the NNS is an Identifier. Why not a DependentNameType?
> }
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200720/15f82a64/attachment.html>