No TypeLoc node for outer nested-name-specifier in pointer-to-member type

[HighCommander4]

In the following code:

struct Outer {
  struct Inner {};
};

using Alias = void (Outer::Inner:: *)();

the token Outer on the last line does not get a TypeLoc node in the AST.

Here's what TypeLoc::dump() prints for the MemberPointerTypeLoc representing void (Outer::Inner:: *)():

MemberPointerTypeLoc 'void (struct Outer::Inner::*)(void)'
|-RecordTypeLoc 'struct Outer::Inner'
| `-CXXRecord 0x5583b9d05430 'Inner'
`-ParenTypeLoc 'void (void)'
  `-FunctionProtoTypeLoc 'void (void)' cdecl
    `-BuiltinTypeLoc 'void'

The TypeLoc for the "class" part of the member pointer is a RecordTypeLoc for Outer::Inner, with no distinct TypeLoc for Outer.

In other contexts where a nested class type like Outer::Inner appears, it's represented as an ElaboratedTypeLoc wrapping the RecordTypeLoc. The ElaboratedTypeLoc exposes a NestedNameSpecifierLoc which allows getting at TypeLocs for other elements of the nested-name-specifier.

A consequence of this missing TypeLoc is that many clangd features, including go-to-definition and semantic highlighting, do not work on the affected Outer token (clangd/clangd#2235).

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Nathan Ridge (HighCommander4)

In the following code:

struct Outer {
  struct Inner {};
};

using Alias = void (Outer::Inner:: *)();

the token Outer on the last line does not get a TypeLoc node in the AST.

Here's what TypeLoc::dump() prints for the MemberPointerTypeLoc representing void (Outer::Inner:: *)():

MemberPointerTypeLoc 'void (struct Outer::Inner::*)(void)'
|-RecordTypeLoc 'struct Outer::Inner'
| `-CXXRecord 0x5583b9d05430 'Inner'
`-ParenTypeLoc 'void (void)'
  `-FunctionProtoTypeLoc 'void (void)' cdecl
    `-BuiltinTypeLoc 'void'

The TypeLoc for the "class" part of the member pointer is a RecordTypeLoc for Outer::Inner, with no distinct TypeLoc for Outer.

In other contexts where a nested class type like Outer::Inner appears, it's represented as an ElaboratedTypeLoc wrapping the RecordTypeLoc. The ElaboratedTypeLoc exposes a NestedNameSpecifierLoc which allows getting at TypeLocs for other elements of the nested-name-specifier.

[llvmbot]

@llvm/issue-subscribers-c-1

Author: Nathan Ridge (HighCommander4)

In the following code:

struct Outer {
  struct Inner {};
};

using Alias = void (Outer::Inner:: *)();

the token Outer on the last line does not get a TypeLoc node in the AST.

Here's what TypeLoc::dump() prints for the MemberPointerTypeLoc representing void (Outer::Inner:: *)():

MemberPointerTypeLoc 'void (struct Outer::Inner::*)(void)'
|-RecordTypeLoc 'struct Outer::Inner'
| `-CXXRecord 0x5583b9d05430 'Inner'
`-ParenTypeLoc 'void (void)'
  `-FunctionProtoTypeLoc 'void (void)' cdecl
    `-BuiltinTypeLoc 'void'

The TypeLoc for the "class" part of the member pointer is a RecordTypeLoc for Outer::Inner, with no distinct TypeLoc for Outer.

In other contexts where a nested class type like Outer::Inner appears, it's represented as an ElaboratedTypeLoc wrapping the RecordTypeLoc. The ElaboratedTypeLoc exposes a NestedNameSpecifierLoc which allows getting at TypeLocs for other elements of the nested-name-specifier.

[HighCommander4]

I believe the decision whether to wrap the class type into ElaboratedType here is made here:

llvm-project/clang/lib/Sema/SemaType.cpp

Lines 5351 to 5358 in 574f64c

	// Note: if the NNS has a prefix and ClsType is a nondependent
	// TemplateSpecializationType, then the NNS prefix is NOT included
	// in ClsType; hence we wrap ClsType into an ElaboratedType.
	// NOTE: in particular, no wrap occurs if ClsType already is an
	// Elaborated, DependentName, or DependentTemplateSpecialization.
	if (isa<TemplateSpecializationType>(NNS->getAsType()))
	ClsType = Context.getElaboratedType(ElaboratedTypeKeyword::None,
	NNSPrefix, ClsType);

The comment there states that no wrapping is done if the type being wrapped is already an ElaboratedType, or a DependentNameType or DepenentTemplateSpecializationType -- this makes sense, since these are precisely the type classes which store a NestedNameSpecifier already.

However, the actual code conditions the wrapping on the type being a TemplateSpecializationType, for reasons that are unclear to me.

That leaves cases like RecordType in my example, where the type does not itself store the NestedNameSpecifier, and it does not get wrapped into a ElaboratedType which would store it.

Naively, it would seem to me that adjusting the condition to wrap in all cases except the three type classes discussed above would be an appropriate fix, but it's possible I'm missing something.

[HighCommander4]

Naively, it would seem to me that adjusting the condition to wrap in all cases except the three type classes discussed above would be an appropriate fix, but it's possible I'm missing something.

I wrote this fix up at #118236. Feedback is welcome.