dwblaikie wrote: > To support access to such constants from LLDB we'll most likely have to have > to make LLDB find the constants by looking at the containing class first.
Tangentially related to: https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/31?u=dblaikie Clang/LLVM do know the difference between type-invariant members and type variant ones (type invariant members are in the `members` list of the `DICompositeType` and variant members have a `scope` that refers to the type but don't appear in the `members` list) - would it be reasonable to not include the invariant members in the accelerator table, but only include the variant ones? Invariant ones can be found by finding any instance of the type in the index, then looking at its members - and for variant members it'd be useful to have them in the index. (though, honestly, I'm not sure how lldb and gdb handle that situation - last time I tested it with gdb, it just saw two different copies of the type and didn't try to unify/aggregate all the variant members... but lldb only creates one copy of the type, so don't know what it does if you've got, say, two member function template instantiations for different template parameters in two different translation units/compile units) https://github.com/llvm/llvm-project/pull/74580 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
