debug: custom string of custom types

[mitar]

Is your feature request related to a problem? Please describe.

I have a custom type which internally uses an array of numbers, you can think UUID identifier. I would like it to be displayed in variables pane in VSCode in standard UUID format instead of current hex format I see in string().

Describe the solution you'd like

I would expect that string() representation really calls String() or at least GoString() on the value.

Describe alternatives you've considered

It seems there was some work on this done in #158, but I have not seen it really working now, so I am opening a new issue.

[firelizzard18]

I would expect that string() representation really calls String() or at least GoString() on the value.

When you say "string() representation" do you mean "the result of evaluating a string(...) expression"? If so, that would have to be implemented by delve because expressions are evaluated by delve. Also, that seems like the wrong behavior to me. When the debugger evaluates a Go expression, I expect it to have the same effect as that expression would if it were part of my program. And string(...) certainly does not call String().

Also vscode-go has no clue if the result of an expression is a value that implements String(). If you hover over a variable, it potentially could query gopls, "What type is this variable? Does that type define String()?". But that may be too expensive or impractical to do on every hover.

It seems there was some work on this done in #158

Putting aside how string(...) should behave, there are a few ways a custom string could be shown. If you to change the variables or watch view, I pretty sure vscode-go can't control what is shown there so you'd need to submit an issue to delve. If you want to change what's shown when a variable is hovered, it sounds like that's possible based on #158. However I don't see a practical way to implement this in either case; to add custom logic delve would have to call a method (or vscode-go would have to ask delve to call a method) and that's not always possible (due to limitations in delve that I don't fully understand). And besides that, I've experienced situations where asking delve to execute a call instruction screws up my debug session such that I have to restart it. So automatically calling a method seems like a bad idea.

Unless delve's ability to call methods becomes significantly more reliable, the only path forward I can see is to find some way around executing code in the debuggee, such as delve simulating executing String() or GoString() (which might require an external source to provide the source of the method). But that would be a major undertaking, and also that's a feature request for delve, not vscode-go.

[mitar]

By string() I mean what is shown in debugger in variables here:

To me it is surprising that string() representation does not call String() on the value.

So based on what you wrote, my understanding is that delve controls what is shown there under string()? How is that feature called in delve?

[firelizzard18]

By string() I mean what is shown in debugger in variables here: [screenshot]. To me it is surprising that string() representation does not call String() on the value.

Ah, I see, that makes more sense. Currently I'm pretty sure the string() = ... part is literally just the result of casting the expression to a string (e.g. string(ID)) and displaying that.

To be clear, I agree that showing the output of String() and/or GoString() would be extremely useful. I don't have an opinion on whether string() = ... should prefer those methods over what it's doing today, but having access to the result of Go/String one way or another would be extremely useful. However the problem remains: executing code in the debuggee (e.g. calling a method) is problematic and I believe that fundamentally comes down to the design of Go itself though I don't know the specifics.

So based on what you wrote, my understanding is that delve controls what is shown there under string()?

To the best of my knowledge, yes, what is shown there is directly controlled by delve's response to the Variables DAP request. I haven't read through the relevant code in detail so I could be wrong, but I have written my own DAP-based debugger extension and essentially the extension says, "Hey vscode, launch this DAP-compatible executable", and the extension has very little control over what happens after that.

How is that feature called in delve?

Maybe "DAP variables request response"? The code is here: Session.onVariablesRequest. Though the debug adapter protocol is complex and the full picture may involve additional requests/responses.

[adonovan]

As @firelizzard18 points out, this is not an issue of the VS Code Go extension, but of the underlying debugging tooling. I suggest you report the issue at https://github.com/go-delve/delve/issues.