Michael137 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)
I'll merge the PR for now to unblock and address this later https://github.com/llvm/llvm-project/pull/74580 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
