Xcode's 'po' fails to identify the variable I wish to study. Wny?

Question

Environment: Xcode 6 Beta 4
I'm attempting to merely look into a text value using the debugger. However the debugger fails to identify the static variable (via 'Let'). This is also true for vars.

Why?

func textFieldShouldReturn(textField:UITextField) -> Bool {
    let myText = "Hello World"
    let theText = textField.text! as String
    return true
}

Here's the debugger result:

(lldb) po textField error: :1:1: error: use of unresolved identifier 'textField' textField ^ :11:5: error: use of unresolved identifier '$__lldb_injected_self' $__lldb_injected_self.$__lldb_wrapped_expr_29(
^ (lldb) po myText error: :1:1: error: use of unresolved identifier 'myText' myText ^ :11:5: error: use of unresolved identifier '$__lldb_injected_self' $__lldb_injected_self.$__lldb_wrapped_expr_30(
^ (lldb) po theText error: :1:1: error: use of unresolved identifier 'theText' theText ^ :11:5: error: use of unresolved identifier '$__lldb_injected_self' $__lldb_injected_self.$__lldb_wrapped_expr_31(
^ (lldb)

Note: debug output is set to 'All Output.

Here's the screenshot:

Answer 1

This is a problem I also encountered, and I think it is a bug in the debugger. If you do not use ANY variables declared with 'let', the po command will work. This is off course not what you want so I filed a bug with Apple for this issue.

I think you should just hope it is fixed in the next beta (file a bug too please, as number of filed bugs will influence Apple's priority in fixing them). In the meantime, go with Amitays workaround.

Answer 2

As confirmed by others above, this is pretty much strictly a bug in Swift / LLDB. It was mostly working as of 6.1.1, broken for or before 6.3 Beta 1, and fixed again in 6.3 Beta 2.

I am just using a command line app as a test and can't test with UIKit, but I have seen similar problems outside of UIKit - and by problems, I mean that I got results like the OP, but now it is working:

struct Foobar {
    var foo:String
    var bar:String
}

func textFieldShouldReturn() -> Bool {
    let fubar = Foobar(foo: "Onesy", bar: "Twosy")
    let myText = "Hello World"
    return true
}

textFieldShouldReturn()

p and po yield slightly different results, and depend on whether or not Printable is implemented:

(lldb) po fubar
(foo = "Onesy", bar = "Twosy")

(lldb) p fubar
(AssertClientMacDirect.Foobar) $R1 = (foo = "Onesy", bar = "Twosy")

Per the thread here: https://devforums.apple.com/message/1111705#1111705, you can also use the image lookup -t <SymbolName> command

image lookup -t Fubar

<path redacted>
id = {0x1000003e0}, name = "AssertMac.Fubar", byte-size = 8, clang_type = "class Fubar {
class func `new`(name: Swift.String) -> AssertMac.Fubar
init(name: Swift.String)
func test()
var someValue: Swift.String
var name: Swift.String
@objc deinit
}

It is worth emphasizing though, that you should double check that the Swift compiler is set to:

• Debug / Optimization -> None,
• Strip Symbols on Copy -> NO,
• Link Time Optimization -> No
• Strip Symbols on Install -> NO, (for debug builds, where appropriate)

If you implement Printable on a swift class, then you will get the results of the description property.

There were previous Xcode bugs where Xcode would crash when trying to step through optimized code.