kuilpd wrote: > 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? > 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.
Well, my logic was that it's better to return something than nothing, similar to what current `frame var` does, it just outputs the first thing that matches the base name, regardless of namespace. Should I make `DILFindVariable` return a specific error message like "ambiguous name" or something? > 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. I tried doing `symbol_context.module_sp->GetSymbolFile()->FindGlobalVariables`, which in turn calls `SymbolFileDWARF::FindGlobalVariables`, but it searches through the entire module, not just current CU. `CompileUnit` class has only `GetVariableList`, no search. It looks like getting variable list there does something different, but I really can't tell if it's any faster. 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
