https://github.com/labath commented:
Looks mostly good, I'm just not sure about this part: > or return any partial match found I'm not sure that's the right thing to do -- if there are multiple matches, how can we know we picked the one that the user wanted to see? It also doesn't seem like it matters for performance, as it's just a check on the size of the candidate list. What might matter for performance is, if returning false/nullptr here causes the implementation to perform the lookup at a larger (more expensive scope). If that's the case, then I'd say that the right thing is to *not* do the second lookup in case the first one is ambiguous (as that doesn't help in resolving the ambiguity). So, the function could return one of three results: found zero, found one, found more than one; and in the last case we would immediately bail out. > However, this slows down lookup if we search for a global in the current > file, but also speeds up the lookup if we search for a global in a different > file, and I'm not sure which tradeoff is better. I think this is the right order at least (variables in the current CU should resolve first), and I definitely wouldn't want to search throught all (potentially thousands) of CUs and then try to pick out the variables from the current one. That said, I think the search for the current CU has different performance characteristics (I believe it materializes all globals, and then searches for the right name), so while I'm not sure if it's necessary (this should be a one-shot thing), I can imagine implementing the search differently somehow, so that we can only return the "local globals" with the right name. https://github.com/llvm/llvm-project/pull/146094 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
