[SR-6156] LLDB: warning: initialization of variable '$__lldb_error_result'

[keith]

Previous ID	SR-6156
Radar	rdar://problem/35002947
Original Reporter	@keith
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	41
Component/s	LLDB for Swift
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: 48509e726972078e013416019229b090

Issue Description:

This test case:

import Foundation

final class Foo {
    func bar() {
        DispatchQueue.main.async { [weak self] in
            if let `self` = self {
                print(self)
            }
        }
    }
}

let foo = Foo()
foo.bar()
dispatchMain()

Causes this error when attempting to `po self` inside of the dispatch closure:

error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

error: <EXPR>:18:5: error: value of type 'Foo' has no member '$__lldb_wrapped_expr_0'
    $__lldb_injected_self.$__lldb_wrapped_expr_0(
    ^~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~

To reproduce this you can compile and debug it with this:

$ swiftc -g foo.swift
$ lldb ./foo
(lldb) target create "./foo"
Current executable set to './foo' (x86_64).
(lldb) br set -f foo.swift -l 7
Breakpoint 1: where = foo`closure #​1 () -> () in foo.Foo.bar() -> () + 118 at foo.swift:7, address = 0x0000000100001ec6
(lldb) r
...
Target 0: (foo) stopped.
(lldb) po self
error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

error: <EXPR>:18:5: error: value of type 'Foo' has no member '$__lldb_wrapped_expr_0'
    $__lldb_injected_self.$__lldb_wrapped_expr_0(
    ^~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~

This is probably the same core issue as https://bugs.swift.org/browse/SR-3886 but I wanted to file it separately since it has a different test case.

[slavapestov]

@swift-ci create

[NachoSoto]

FWIW I think I've been seeing this since Swift 1.0.

[slavapestov]

So it's not a regression? Sorry, management won't let us fix it 😉

[keith]

I've made some progress on this. So the problem for this specific case is that when lldb attempts to find `self` here, it finds the optional one, and ends up adding the extension to Optional, yet the `self` that ends up getting accessed is the non optional one, so the extension doesn't apply. This is the cause of the second half of this error.

This isn't super surprising since in this case you can even see the problem by running `fr v`:

(@lvalue second.Foo?) self = 0x0000000101303740
(second.Foo) self = 0x0000000101303740 {}

Since you end up with multiple self vars here. I'm not exactly sure what the solution is yet, or if it's even on the lldb side, but I'm still looking into it.

[keith]

Upon more investigation, the problem isn't the multiple `self` variables, it's that where lldb is fetching the variables from, SymbolContext->GetFunctionBlock->GetBlockVariableList, only includes the optional self, and not the non-optional one. You can see this using the python API to access the same variables:

# From some lldb python function
frame = context.GetFrame()
block = frame.GetFunction().GetBlock()
# All the Trues means don't filter out any specific types of variables
variables = block.GetVariables(frame, True, True, True, lldb.eDynamicDontRunTarget)
for variable in variables:
    print variable

In this case you end up with just the optional `self`. If you instead access the variables directly from the frame, you get both.

[keith]

Since swiftlang/swift#15306 you can now do this without the backticks, but lldb still has this issue (unsurprisingly)

[omochi]

I recorded video about same issue.
https://twitter.com/omochimetaru/status/1047384921180758016

[swift-ci]

Comment by Erica Ehrhardt (JIRA)

We keep running into this one at Thumbtack. One way it manifests in Xcode is that tracepoints showing the value of locals in a closure that uses self like this don't print anything. Another is that the ℹ button results in the same initialization of variable '$__lldb_error_result' was never used message as in the issue description. The workaround in is to change the name of the unwrapped self to something else (if possible), but it looks a little goofy.

[swift-ci]

Comment by Daniel W Roth (JIRA)

Agreed. This effectively nullifies the value of being able to write (the very common)

guard let self = self else { return }

[swift-ci]

Comment by Christopher Fuller (JIRA)

I completely and wholeheartedly agree with dwroth@gmail.com (JIRA User) !! As Swift developers, we LOVE the fact that SE-0079 was accepted and released with Swift 4.2. We have adopted that syntax ever since, however we regularly encounter this debugging issue. This causes a lot of friction in our engineering process and results in Swift engineers resorting to using `strongSelf` or `this` or `_self` or whatever. These workarounds are not ideal at all - we can do better!!

[swift-ci]

Comment by Borys Gurtovyi (JIRA)

Please, give this bug some attention! Thank you 👍

[swift-ci]

Comment by Johnson Hsieh (JIRA)

This would be great

[swift-ci]

Comment by Nicholas (JIRA)

This one impacts us daily. Would be great to see a resolution.

[swift-ci]

Comment by Owen Thomas (JIRA)

I've been running into this for a while now too but didn't know there was a bug report for it till just now. Would love to see a fix for this one!

[swift-ci]

Comment by Michael Doshi (JIRA)

I've been running into this over the past couple years. Would be great to have a fix 👍

[swift-ci]

Comment by Connor Wybranowski (JIRA)

Would love to see a fix for this! 👍

[slavapestov]

I'm looking at this now, but at least some of you will be disappointed... 🙂 I suspect there are multiple root cause failures that all manifest as an error "value of type 'Foo' has no member '$__lldb_wrapped_expr_0'", one of them being this issue with a shadowed 'self' declaration. However, once I fix this issue, we can see what else remains.

[swift-ci]

Comment by Manjunath Chandrashekar (JIRA)

Have crossed path with this issue when working on Generics recently. https://github.com/manjuhere/GenericsBugDemo Would be glad if it can help in solving the issue.

[swift-ci]

Comment by rounak jain (JIRA)

Would be really great to have a fix for this, given a lot of times issues can't be reproduced, and having a broken debugger at that instant is very limiting.

[swift-ci]

Comment by Elliott Williams (JIRA)

I've been using this workaround in lldb to sidestep the issue.

1. Run fr v -D 1 to and get a pointer to self

2. Move up stack frames to get past the frame containing the problematic self reassignment. (in practice, it's easy to move up to `main`)

3. Run e -Ol swift – unsafeBitCast(<pointer>, to: <type of self>), and you'll have a reference to the object you can manipulate like you would with po

[swift-ci]

Comment by Leonid Kokhnovych (JIRA)

This one impacts us daily. It would be great to see a resolution.

[keith]

The original specific example here has been fixed for a while. If anyone else has a new repro case please file a new ticket!