Fix IRGen debug info for swift_task_alloc'ed variables.

[adrian-prantl]

The old code attempted to load the variable despite not knowing its size. Fixed by describing the variable's address on the task heap.

[adrian-prantl]

@swift-ci test

[adrian-prantl]

Matching LLDB test can be found in apple/llvm-project#5768

[adrian-prantl]

Discovered via #62499

[aschwaighofer]

LGTM. Thank you!

[JetForMe]

This does seem to improve inspecting variable values in async code, but doesn't seem to improve stepping into async code (in Xcode, at least, but I've got some compiler/lldb mismatch warnings).

[adrian-prantl]

Good to hear the confirmation. It is expected that this change would not have any effect on stepping.

[JetForMe]

I wasn't sure but also didn't think so. Just trying to be thorough. I may know the words and grammar, but reading that code is like Darmok & Jalad at Tanagra.

[JetForMe]

Hmm, I'm still experiencing the symptom of the Xcode debugger not seeing some local variables that are clearly in scope and accessible, in this case running in a Task { } block (via function call) on macOS. Happy to provide this project.

[adrian-prantl]

Happy to provide this project.

That would be great. Either bugs.swift.org or feedback.apple.com work.

[JetForMe]

Set a breakpoint in DaemonCollector.swift:153 and run it. It should stop there almost immediately. Try to inspect the variables lower in the list in the Xcode variables pane (interestingly, it seems there's a line on the list above which variables are inspectable, below which they are not, and I feel like this has always been the case).

See the screenshot for examples (I context-clicked on label and executablePath and chose “Print description of”):

Exorcist.zip

[adrian-prantl]

Thanks! Here's an even shorter reproducer:

func f(_ l: [Int]) async {
    for item in l {
        var label : String?
        label = "test"
        print("break here")
    }
}

await f([1, 2])