jingham added a comment. @rsmith: lldb does as you suggest, if it can find a name in the local context, it returns that, if it can find it in the current CU, it returns that, etc... It only returns multiple matches if it can't find a single instance along that chain.
The problem with this case is that from lldb's standpoint the symbol wasn't ambiguous, the only match lldb knew about was the internal libc symbol. The collision was between that libc symbol and a local variable that was defined in the expression that lldb was submitting to clang. At present, we don't know anything about those in flight definitions, we just reply with names from outside the current compilation. So we didn't know there was a closer definition. Is it possible for lldb to peek at those in flight definitions ourselves and return that as the most proximate instance? I think that's the behavior we want. The other thing to do is have clang know to prioritize name matches from decls it made out of the expression over those provided to it by an externalAST source, if that's a thing it is possible to do. https://reviews.llvm.org/D39307 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
