Can't obtain full type of the non-template type parameter in clang frontend

[DoDoENT]

Consider this example:

template< typename T, auto ... dims >
struct NDArray;

struct Dimension
{
    using value_type = unsigned short;

    value_type size{ value_type( 0 ) };
};

template < typename ConcreteDim >
struct DimensionImpl : Dimension {}; 

struct Width : DimensionImpl< Width  > {};
struct Height: DimensionImpl< Height > {};

inline constexpr Width  W;
inline constexpr Height H;

NDArray< float, W > bla;

Clang reports the error as

error: implicit instantiation of undefined template 'NDArray<float, {{{0}}}>

while GCC provides full type information:

error: aggregate 'NDArray<float, Width{DimensionImpl<Width>{Dimension{0}}}> bla' has incomplete type and cannot be defined

In my code, I'm using libTooling to obtain full type names of some C++ code, and I've noticed that in cases such as the above, Clang simply writes {{{0}}} instead of Width{DimensionImpl<Width>{Dimension{0}}}. This is problematic for me as my tool should behave differently if this {{{0}}} is actually Width than if it's actually Height.

I'm obtaining type information in libTooling using this snippet:

bool VisitVarDecl( clang::VarDecl * varDecl )
{
     auto canonicalType{ varDecl->getType().getCanonicalType().getAsString() };
     // make some decisions based on canonicalType
     return true;
}

However, clang appears to correctly resolve overloads taking NDArray< float, W > vs NDArray< float, H >, so this means that clang actually does have a distinction between those two types.

However, how to obtain the full name of the type?

Also, would you consider putting the full name of the type in the clang's error as well (the way GCC does)?

[DoDoENT]

The issue also persists in clang 15.0.0.

[DoDoENT]

I've noticed that stack traces displayed by LLDB and sanitizers show the full correct name of the type, however, it appears that they parse that from debug info stored in the binary, which means that someone somewhere had to write that inside, meaning that clang has that information somewhere.

Can someone point me to how to get the same strings LLDB and sanitizer get for type names from AST nodes?

[dwblaikie]

LLDB and sanitizers probably get it from mangled names - though you could check in the DWARF to see if the human-readable names are better than the ones you're getting in diagnostics.
If you compile a small program with -g and then use llvm-dwarfdump on that object/executable, you should get the debug info that's used by LLDB, etc. The functions should have a DW_AT_name that's the human-readable version, and a DW_AT_linkage_name that's the mangled one. The mangled one would certainly demangle (using llvm-cxxfilt I think) to include the extra info, I would imagine. But I don't know if the human-readable one would be unambiguous or not - if it is, then you could go look in clang's CGDebugInfo.cpp to see how that name is generated.

[DoDoENT]

@dwblaikie, thank you for the pointers. I've investigated how the name is getting printed in AST and created this patch which actually gets me the behavior I want (the same as GCC).

I've made a patch for LLVM.