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