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

Wed Apr 22 11:26:22 PDT 2020

dblaikie added a comment.

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

> In D76801#1995058 <https://reviews.llvm.org/D76801#1995058>, @dblaikie wrote:
>
> > > 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.
>
>
> That is kind of true, and I don't really have a definitive reply to that. I suppose there is a difference between the lookups done for type completion and those done e.g. in expression evaluation. The latter are probably more frequent and are assumed to be correct. Maybe they shouldn't be, but in that cases, then there would probably be no use for the hash tables in indexes (I am not very familiar with the gdb index, but I know it has hash tables similar to debug_names/apple_names). I don't know what gdb does for tab completion, but it probably bypasses the hash table (though the index could still be useful even then as it has a concise list of all strings in the debug info), or it gets the list of strings-to-complete from a completely different source (demangled function names?).
>
> Tab completion is always a bit dodgy. E.g., in your example `ptype tmpl<TAB>` completes to `ptype tmpl<tmpl<int>>`, but then running that produces an error: `No symbol "tmpl" in current context.`
>
> In lldb, tab completion in expressions works by hooking into the regular clang tab-completion machinery used by editors.  The up- and down-side of that is that it uses the same code path used for actual expression evaluation -- i.e. all the types will be looked up the same (exact) way.
>
> Speaking of templates and indexes, the thing we would really like in lldb would be to have just the bare names of templated class in the indexes -- that way we could reliably look up all instantiations of a template and do the filtering ourselves. However, this runs afoul of the dwarf specification, which says that the index names should match the DW_AT_names of relevant DIEs (and these contain the template arguments for other reasons...). This means that currently we have outstanding issues when looking up templated types, but we haven't really figured out what to do about that...

Yeah, points all taken - as for this actual issue... I'm kind of inclined to say "hey, our template names already diverge somewhat - and this divergence is in the realm of acceptable by gdb (without an index) so... *thumbs up*/let's stick with it" & as I think you mentioned earlier, this is more a problem for the index support, than for the debug info producer. I don't think it's a reasonable goal that Clang & GCC produce /exactly/ the same names for templates like this... I mean, we /could/ try, but I don't think it's worthwhile (especially given that gdb's got support intended to do fuzzy matching/allow some divergence)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76801