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? On Fri, Jun 15, 2018 at 11:59 AM <paul.robin...@sony.com> wrote: > gc> Solution #1 would cause us to dig through all definitions of all C++ > gc> classes all the time when parsing DWARF to check if definitions of > gc> the classes had template methods. And we would need to find the class > gc> that has the most template methods. This would cause us to parse much > gc> more of the debug info all of the time and cause increased memory > gc> consumption and performance regressions. > > pr> It would be cheap to put a flag on the class DIE that tells you there > pr> are template methods to go look for. Then you incur the cost only > pr> when necessary. And the accelerator table makes it fast to find the > pr> other class descriptions. > > gc> That is a fine solution. But we still run into the problem where we > don't > gc> know if the DWARF knows about that flag. If we do a flag, it would be > nice > gc> if it were mandatory on all classes to indicate support for the flag. > But > gc> this would be a fine solution and not hard to implement. > > pr> So what you really want is not a flag, but a count, so you can tell > when > pr> you've found all the different templates. If the count is zero, > there's > pr> nothing to look for. If the count is two, you look around at all the > pr> various definitions of the class until you find two different > templates, > pr> then you stop. If there's no count attribute, your producer doesn't > pr> know you want this information and you do it the hard way. Or, we've > pr> invented a way to describe the templates directly in the class. > pr> > pr> How's that? > > gc> that would work fine. > > I filed PR37816 to track this idea. > > The other ideas: > > - accelerator to point to the actual instantiations > - emitting template definitions not just instantiations > > would be trickier to define and harder to implement correctly. > I won't say they can't be done, but somebody else would have to do > the heavy lifting here, unless it turns out that our debugger folks > like the idea. > > --paulr > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
