Michael137 added a comment.
> 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)?
> 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
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D143501/new/
https://reviews.llvm.org/D143501
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
