On Fri, 15 Jun 2018 at 20:14, David Blaikie <dblai...@gmail.com> wrote: > > How do you handle name lookup for nested classes? They have the same problem > (they don't appear in all definitions) - don't appear in all descriptions of > the outer/parent class. (in theory we could ensure there's always at least a > declaration of the nested class - but we don't even do that if the nested > class is unused) > > Is it just the case that Clang doesn't mind you adding a new nested class but > it does mind you adding a new member function template? If so, maybe we could > change Clang to support adding new member function templates instead of > extending DWARF?
I was thinking about the same thing. It seems to me that this could be viewed as a deficiency of our implementation of dwarf parsing. (It's a pretty understandable deficiency, given that we are based on clang (compiler), and it thinks of the types in the same way as C++ does -- incomplete; or complete with template members and all). However, these template member functions should not impact anything "important" in the class (data member layout, vtables, ...) so one could conceivably have an implementation which allows member addition on the fly. And in this case the existing accelerator tables would work perfectly -- we would get a query "does this class have method X", we would look at the accel table, and it would point us straight to X. However, I have no idea how hard would it be to fit this scheme into the existing clang/lldb design. That said, having DWARF be able to represent the template member functions in an abstract way also sounds like nice thing to have from a debug info format. pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
