[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
Mon Oct 29 16:49:50 PDT 2018

zturner added a comment.

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

> Exact matches aren't a C++ specific thing.  An exact match is useful for mixed C/C++ since you might want to say Foo and not Bar::Foo.  IIRC a couple of the places where exact was dialed up explicitly in FindTypes were for C types.   But since C and ObjC allow multiple types with the same name, that's one way you might see multiple matches for "exact match".  Moreover C+ used to be fuzzy about whether non-exported classes from different linkage uses had to follow the ODR.  I haven't followed whether this got nailed down but it still seems Quixotic to expect you could enforce this, since you are asking two totally unrelated library vendors to avoid each other's names for private classes...  So having several classes with the same name is still a possibility IRL with C++.
> Why we care is that if somebody runs the command:
> (lldb) expression (::SomeClass *) 0x12345
> We're going to try our best to make that work.  If SomeClass is not visible in the module/comp_unit/function in which we are currently stopped, then we will go looking far and wide for SomeClass.  If we find one result somewhere out in the world, the expression will succeed, but if we find two results which are different, then we want to give an error about ambiguous type.

So when designing this new `FindTypesByFullyQualifiedName` API, is it safe to assume, for the purposes of the API signature, that at the //Module// level, it will either return 0 or 1 match (e.g. the return value shoudl be a `TypeSP`, but at the //ModuleList// level, it can return arbitrarily many (so the return value should be a `TypeList`?


More information about the lldb-commits mailing list