[SR-10472] Feature request: show generic type variables in Xcode's variables pane

[NSExceptional]

Previous ID	SR-10472
Radar	None
Original Reporter	@NSExceptional
Type	New Feature

Attachment: Download

Additional Detail from JIRA

| | | |------------------|-----------------| |Votes | 0 | |Component/s | LLDB for Swift | |Labels | New Feature | |Assignee | None | |Priority | Medium | md5: 3969b4dc93d426faa2ed68c5f5bb82eb

Issue Description:

Consider the following code:

func cast<T, U>(_ bar: T) -> U {
    return bar as! T
}

The variables pane will only show you a variable for bar (and self if this is a method). It would be so useful if T and U showed up as variables here too, relieving the developer from having to type po T.self (which often doesn't work) or from assigning a temporary variable to T.self. Generic type variables are implicit function parameters, after all.

I'm not sure how this could be incorporated into Playgrounds, but it would be nice to have something similar for Playgrounds as well.

[belkadan]

Interesting idea. jingham@apple.com (JIRA User), @dcci, @adrian-prantl, what do you think?

[swift-ci]

Comment by Jim Ingham (JIRA)

The thing you want to see is the full resolved type of T & U, right? We have the info to show this. I'm not so sure about how to present the results. I don't think you want to show T & U as held onto by some implicit function parameter, etc. That's too much inside baseball... It seems like we should just show T -> some type, and U -> some type. But that would mean the results don't fit naturally in frame variable, which presents values not types. But we could certainly add something to "frame info" and an SB API to return a map of Generic Names -> Types which Xcode could present however it wants to.

[adrian-prantl]

Because of how the debug information is encoded, the generic type parameters are actually part of the current frame. They are just hidden by default because they are not particularly pretty to look at.
By running `settings set target.display-runtime-support-values true` you can make them appear in the output of `frame variable` and/or the variables view.

[adrian-prantl]

To clarify: I don't recommend that users should turn on this setting. I think it would be reasonable to expect, for example, the type substitutions to appear in the back trace. I would also be okay with showing the type parameters in frame variable by default, if we can make sure they are actually printed as an abstract `T=Swift.Int32` hiding all the type metadata implementation details.

[swift-ci]

Comment by Jim Ingham (JIRA)

We got a request to print type substitutions in backtraces previously. I was worried that doing that would make the already noisy swift backtraces even noisier, particularly it you substitute them inline, e.g. just T->[Int, MyClass] everywhere...

[NSExceptional]

@adrian-prantl Oh, neat! It works, this caused $τ_0_0 to appear as a type variable. Printing it doesn't work, though, which is related to my other issue I'm sure. Also, it does tell you the type name, Tests.Human in this case, but it doesn't show that information in Xcode's variables window. LLDB:

(lldb) settings set target.display-runtime-support-values true
(lldb) frame variable
(Data) data = 47 bytes
(@thick BetterJSONDecoder.BetterJSONDecoder.Type) self = 0x0000000127a8e708
(Builtin.RawPointer) $τ_0_0 = 0x0000000127a8e450 type metadata for Tests.Human
(Any) json = {
  payload_data_0 = 0x0000000000000000
  payload_data_1 = 0x0000000000000000
  payload_data_2 = 0x0000000000000000
  instance_type = Any
}
(@thick T.Type) type = 0x0000000127a8e450
(BetterJSONDecoder.BetterJSONDecoder) decoder = <variable not available>

Output: 

Ideally type variables would show up as an [A] auto variable, like self, and read something like

[A] T = (Tests.Human) 0x0000000127a8e450

[adrian-prantl]

I don't even think that the pointer value is of any relevance to anyone but compiler developers, so it might as well be `T = Tests.Human` is that fair?

[NSExceptional]

I can see myself needing it when working with the runtime directly, at least until Swift gets full-fledged reflection on par with Objc. In fact I'll definitely need it for that.

Compromise: if I can see it's address by expanding/unfolding it, that works too!