[PATCH] D76801: [AST] Print a<b<c>> without extra spaces in C++11 or later.

Tue Apr 21 11:20:47 PDT 2020

dblaikie added a comment.

In D76801#1994003 <https://reviews.llvm.org/D76801#1994003>, @labath wrote:

> In D76801#1993337 <https://reviews.llvm.org/D76801#1993337>, @dblaikie wrote:
>
> > In D76801#1991904 <https://reviews.llvm.org/D76801#1991904>, @labath wrote:
> >
> > > David's example does work with gdb without -Wl,--gdb-index (the member variable is shown), presumably due to the aforementioned fuzzy matching. However, it does not work if gdb-index is enabled,  nor with lldb (as lldb is always very index-oriented and assumes equality everywhere). That is definitely not ideal, though I'm not sure that means about this patch. This is definitely not the only difference in the formatting of DW_AT_names of templates. For example, `template<typename T> operator<<(T, T)` will come out as `operator<< <A>` with gcc, but as `operator<<<A>` with clang (with or without this patch).
> > >  OTOH, differences in type names are more likely to cause problems than is the case for functions/operators.
> >
> >
> > That is concerning. Any idea if that's only with lld's gdb-indexx implementation, or also gold's?
>
>
> I was using gold for my initial test. However, the same thing happens with lld too...

Good to know! Thanks for checking!

>> This isn't the only naming divergence between GCC and Clang, though, so if gdb-index doesn't support any divergence, that's a problem...
> 
> It becomes a gdb-index problem because with an index the debugger will do a (hashed?) string lookup and expect the string to be there. If the strings differ, the lookup won't find anything. In the no-index scenario, the debugger has to trawl the debug info itself, and so it has some opportunities to do fuzzy matching.

That surprises me a bit - given that one of the things debuggers provide is autocomplete (I'm unlikely to write out a type name exactly as the debug info contains it - if two compilers can't agree, it's much less likely that all users will agree with any compiler rendering), which I'd have thought would be facilitated by the index too - in which case lookup via exact match wouldn't be viable, you'd still want a way to list anything with a matching substring (or at least prefix), etc. Which could help facilitate lookup fuzzy matching like in this sort of case.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76801