"errror: reference to '...' is ambiguous" message in LLDB

[michaeleiselsc]

When I try to print a local variable in LLDB, e.g. with po foo, and there's a function with the same name, I get this message:

error: reference to 'foo' is ambiguous
candidate found by name lookup is 'foo'
candidate found by name lookup is 'some_module::some_struct::{{impl}}::foo'

[mikeyhew]

Just found this bug. Is there a workaround / something you can pass to lldb to make it print the local variable?

[samg31]

I have encountered this bug as well.

[ahti]

frame variable varname did the job as a workaround for me.

[fanzeyi]

Having a pair of single quotation mark around the variable name can solve this issue, but I found this trick by randomly trying and I reached this issue when I'm digging more into this issue...

[epai]

I was able to get the info by first just directly printing out the memory address for the object:

example (request is the local variable name here)

>>> (lldb)  frame variable request
(NSMutableURLRequest *) request = 0x00006000002df950
>>> (lldb)  po 0x00006000002df950
<NSMutableURLRequest: 0x6000002df950> { URL: http://example.com }

[alexreg]

Any update on this?

[ranweiler]

I ran into this running the rustc test suite and lldb 8.0.0.

It looks like I can always repro with a program like this:

fn main() {
    let ascii = 123;

    println!("hi");
}

After breaking at println!, we can elicit:

(lldb) p ascii
error: reference to 'ascii' is ambiguous
candidate found by name lookup is 'ascii'
candidate found by name lookup is 'core::ascii'

It looks like I can repro this by having my local var shadow any direct submodule of core (array, unique, &c).

This may be related to this lldb (todo) "project": Fix local variable lookup in the lldb expression parser

In lldb, print is an alias for expr, whereas frame variable doesn't use the expression parser:

The “frame variable” command is not a full expression parser but it does support a few simple operations [...]

— https://lldb.llvm.org/use/tutorial.html#examining-stack-frame-state

It also looks like this project, if completed, would at least provide a workaround: Expression parser needs syntax for “{symbol,type} A in CU B.cpp”

[ranweiler]

See also:

We have a not-yet-implemented scheme to allow some syntax like:
(lldb) expr $$foo.c$bar(5)
that would mean: look up the version of bar defined in foo.c and call that. [...]

— http://lists.llvm.org/pipermail/lldb-dev/2016-June/010623.html