jingham added a comment. The problem here is that the name that started the whole query is a local variable in the code we're currently compiling. So clang doesn't need to ask us about it, and in fact since we're still in mid-compilation lldb doesn't know anything about the name we're actually trying to look up.
Actually clang shouldn't be asking us about it at all. It already knows what it is, and it is a local variable so it should know that it takes priority over anything else we might find. But it does, by bad luck we find ONE unambiguous symbol with the same name. We return that to clang and then it says that symbol and the local variable it should never have looked elsewhere for collide. This fix would only fix one particular version of the problem. For instance if the symbol that was causing problems happened to be external and not internal, this fix wouldn't work. It's just that libm happens to have an internal symbol with a quite unfortunate name: 'a'... https://reviews.llvm.org/D39307 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
