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`? https://reviews.llvm.org/D53662 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
