Feature request: show time strings in debug inline values

[holmbuar]

Referring to closed Delve issue. Perhaps this request is more valid for the vscode-go extension?

In my debug sessions I have a time variable t, for this variable I can see

t: <time.Time>(0xc00000a040)

in the Run side bar, and

t = <time.Time>(0xc00000a040)

in the debugging inline values, highlighted in the editor.

When I e.g do recursion and use pointer variables, the memory address of the variables is nice to have immediate eyesight upon. However, I spend a significant amount of time cycling through

...
call t1.String()
call t2.String()
call t3.String()
call d1.String()
call t1.String()
...

in the debug console.

My question is: do we need to have variable type and memory address shown both in debug side bar and inline values?

I naively suggest to print (t time.Time).String() and (d time.Duration).String() in either the debug inline values or debug side bar, for all time and duration variables. This feature would speedup my debug sessions significantly, thanks.

[holmbuar]

I also notice that if I add the time variable t and duration variable d to Watch, I get

>t: <time.Time>

and

d: 1381000000000

in the Watch window. Displaying the string values directly could also help a lot in this case.

[mattwelke]

That's a neat idea. I know in languages like JavaScript, I see a string representation of the date object and I can use watches to get more info about a variable, including date objects:

For Go, this doesn't work right now. Not even watches:

The error under watches is Unable to eval expression: "could not find symbol value for time".

It tells me it's a time struct but nothing more than that. It'd be nice if it displayed one of the formatted time strings next to it in the debugger. Personally, I'd like it both in the bar on the left and for inline when you mouse over a variable while debugging.

[hyangah]

cc @polinasok @suzmue what do you think about adding this in the new delve dap?

[holmbuar]

Adding to debugging time with call t.String() is getting Unable to complete call: "call not at safe point" error regularly. The solution is normally to step a few steps more, then retry string call.

Having the time string feature would be really nice, even with some delay in presenting the strings (due to the safe point issue?)