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