[PATCH] D143501: [clang][DebugInfo] lldb: Use preferred name's type when emitting DW_AT_names

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a subscriber: probinson.
dblaikie added a comment.

In D143501#4116200 <https://reviews.llvm.org/D143501#4116200>, @Michael137 wrote:

>> I'd recommend a possible long-term solution would be simplified template names (so we don't have to worry about encoding this in the `DW_AT_name` anyway) and a "DW_AT_LLVM_preferred_name" or similar attribute on a type that refers to the typedef that is the preferred name. This would generalize further than only appearing in template names - the type of a variable inside a template would also gain the beneficial naming (eg: `template<typename T> void f1(T t) { }` - as it stands, the type of the variable `t` must be `std::basic_string<char...` - but if the `DW_TAG_class_type` for `std::basic_string<char...` had this preferred-name attribute on it, then a debugger could helpfully render the type by its preferred alias instead)
>
> That could be a neat solution. I probably asked this before, but what's the timeline with switching it on by default (if such plan is in the works at all)?

I haven't especially planned that - though given it's been picked up by Fuschia and Chromium (at least in some build modes), and we got gdb and lldb mostly fixed, maybe it's worth considering. Defaulting on for lldb might be easier than for gdb (gdb has some outstanding index bugs with it). But generally I figure you Apple folks tend to be the ones who have more investment in what the lldb tuning should cover, or not?

If you folks want to try turning it on & we could see about turning it on by default for lldb tuning?

>> Alternatively, I suppose, the DWARF emission could just look at the preferred name and use that as the `DW_AT_type` in all cases anyway? Avoids needing a new attribute, etc, though would be a bit quirky in its own way.
>
> This is how I first thought of implementing it, but ran into some circular dependency quirks and started working on this patch instead. Could take a second stab at doing so if that's the preference. Would be nice to not have this behind a tuning

yeah, happy to help with pointers, etc.

I think /maybe/ we had some design principle that DWARF features wouldn't be solely controlled by debugger tuning, the tuning only indicates defaults but tehy can be controlled by flags? Not sure if I'm remembering that quite right, though - maybe @probinson remembers more of that?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143501/new/

https://reviews.llvm.org/D143501