[Lldb-commits] [PATCH] D53662: Give the SymbolFile plugin enough information to efficiently do exact match lookups

Zachary Turner via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Oct 25 14:07:15 PDT 2018


zturner added a comment.

In https://reviews.llvm.org/D53662#1276253, @jingham wrote:

> So the current approach relies on the ability to sniff the name to determine the context in which the user intends to find it.  It does (and always did) use the presence of an initial "::" to tell whether a symbol is exact.  That's obviously also inappropriate for a generic Type method.  But OTOH, there needs to be a funnel point where you take in a string you know nothing about (from the user either in type lookup or in an expression) and find it as best you can.  I don't think we want to force command line users to say "type lookup --exact " so we've got to figure it out internally.
>
> Internally, it might be helpful to do some initial analysis of the input type string, and then dispatch it to an exact or inexact search.  But given I don't think you can get away without a FindTypes that takes a string that you don't know whether it is exact or not, I don't feel strongly about that.
>
> We should abstract "is exact" and ask the various type systems to handle that request, and we also need to abstract "remove type class" and again ask the various type systems to handle that.  That seems to me the main ugliness that this patch reveals.


Just to clarify, is the consensus then that I can submit this as is?  Or that it needs some modification?  Greg's suggestion of making a separate method called `FindExactType` could work, but it doesn't seem that much different than passing a boolean call `exact_match`, which is what I've done here.  On the extreme end, we could just make `Module::FindTypes` do absolutely nothing except call the SymbolFile plugin.    I don't feel too strongly either way.  The current patch seems NFC for DWARF and strictly better for PDB, but I'm willing to make changes if anyone feels like there's an architecturally more sound approach.


https://reviews.llvm.org/D53662





More information about the lldb-commits mailing list