[clang] [clang][DebugInfo] Revert to printing canonical typenames for template aliases (PR #110767)

[Michael Buch via cfe-commits]

Michael137 wrote:

> If we're still producing the typedef-style DWARF for these alias template specializations - perhaps lldb could not cache pretty printers for typedefs? (I guess the pretty printers shouldn't be typedef-specific, right, since typedefs are transparent anyway - but I guess maybe pretty printers can be typedef-specific because typedefs can be intended to communicate what kind of a thing is and possibly how to render it?) - it'll cache teh pretty printer for the underlying type anyway, yeah?

Basically what was happening is that LLDB saw the new `std::removecv_ref_t<value_type>` member of `std::optional`, which resolved to `std::string`. Then formatted it as `std::string`. And then cached the `DW_AT_name`, i.e., `std::removecv_ref_t<value_type>`, to point to the `std::string` formatter. But that meant that the next time we saw a `std::removecv_ref_t<value_type>` (even if it didn't resolve to `std::string`) would use the cached formatter. The reason this patch works around that situation is that now the `DW_AT_name` will have the canonical type in `DW_AT_name`, not the unresolved `std::removecv_ref_t<value_type>`.

@jimingham will be able to speak more confidently about LLDB's intention here but I think caching typedefs is intentionally supported. Jim and I came to the conclusion yesterday that we probably don't want to cache template specializations.

I think we can (and should) fix the caching behaviour, but that would be a longer undertaking and I wanted to unblock the libc++ patch (https://github.com/llvm/llvm-project/pull/110355) as soon as possible.

It's on my list of follow-ups to reland this and fix the cache (and also investigate what it would take to support `DW_TAG_template_alias` in LLDB, so we can enable those by default).

https://github.com/llvm/llvm-project/pull/110767