Usually when searching for variables we stop after we find the first one (see for example
ClangExpressionDeclMap::LookupLocalVariable or
ClangExpressionDeclMap::FindGlobalVariable), as there are legitimate reasons for multiple
variables with the same name being defined in the ASTs that LLDB searches. For example,
a header with at static global variable that is included by multiple shared libraries will
produce such duplicate variables.
However, when resolving lookups in namespaces, LLDB currently iterates over all lldb_private::Modules
that are known to contain the given namespace and then searches in all of these modules for
the given lookup. This causes that when a static global variable from a header is included in
different shared libraries, LLDB will add all these variables to the lookup results. The results
will then cause Clang to emit a diagnostic about an ambiguous lookup and the expression
will fail to compile.
This patch solves this by only adding the first variable that is found to the lookup and ignoring
the others. It also changes the search order to first look in the current module of the
execution context and then iterate over all other modules, so that LLDB will always find the
'closest' definition of the given variable.
Also adds a test for the case where all these variables are in one module, but solving that issue
is yet another patch.
Just to state the obvious: Picking the first variable won't work for variable templates, but we anyway
don't really support those yet (beside pretending they are just normal variables). Once we properly
model those this logic just needs minor tweaking to make them work as expected.
Fixes rdar://63222982
I believe current_namespace == n should be enough. Or maybe use ClangASTImporter::NamespaceMapItem *current_namespace instead of the optional (compare with `current_namespace == &n) and avoid the copies and value comparisons...