tree 410a52dfd5fe6bf8688edda5896498416e4e5eba
parent 575abdeb3a25d668ff1a2a391bc8e3df6babae74
author Hana (Hyang-Ah) Kim <hyangah@gmail.com> 1597862806 -0400
committer Hyang-Ah Hana Kim <hyangah@gmail.com> 1599167399 +0000

src/debugAdapter: add delve 'call' command support

Delve supports function calls. Even though it is still
experimental and can be applied only to a limited set
of functions, this is a useful feature, many vscode-go
users long for.

Unlike other javascript/typescript debuggers, delve
treats function calls specially and requires different
call paths than usual expression evaluation. That is
because Go is a compiled, runtime-managed GC language,
calling a function safely from debugger is complex.
DAP and VS Code UI does not distinguish function calls
and other expression evaluation either, so we have to
implement this in the same `evaluateRequest` context.

We use a heuristic to guess which route (call or
expression evaluation) we need to take based on
evaluateRequest's request.

The set of expressions delve supports includes some of
the builtin function calls like `len`, `cap`. We also
expect some grammar changes due to the ongoing effort for
Go2 experiment. In order to cope with this uncertainty,
this change requires users to specify their intention
using the 'call' keyword. Any expression that starts with
'call' and contains function-call-like strings, will cause
the evaluateRequest to take the path for the `call` command.

And, DAP and VSCode assumes all expressions return only
one result, but in Go, function call can return multiple
values. In this CL, we work around this sementic difference
by wrapping all the return values in one wrapper result
that has all return values as children. Users can expand
each value.

While we are here, this CL also adds a logic to handle the
interface type value. Previously, it was captured by the
default case that does not show the underlying type and value.
Interface types behave differently depending on the underlying
data type and value (e.g. nil error https://golang.org/doc/faq#nil_error)
so showing the underlying type/value upfront helps debugging
much easier. In particular, the 'error' type is commonly used
as the last return value of a function call and the program
control flow changes depending on whether the error is nil.
So, here we surface the underlying type and, if the underlying
type is invalid and the addr is 0 (nil error), present the
result as 'nil <error>'. This allows users to recognize the 'nil'
error value without extra value expansion.

Any error with an underlying type will be presented as
`<error(someUnderlyingType)>` and require the value expansion.

I see we can further improve this display value handling and
try to follow delve's data presentation as much as possible but
that is a bigger change and is beyond the scope of this CL.

This is based on github.com/golang/vscode-go/pull/101

Fixes golang/vscode-go#100

Co-authored-by: Eugene Kulabuhov <eugene.kulabuhov@gmail.com>
Change-Id: I4e1e876ab1582b17fa2c7bf0b911f31ec348b484
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/249377
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Polina Sokolova <polina@google.com>