commit 93ee1d22ac928171e045acabe97e4e91a850a716
author Hana <hyangah@gmail.com> Sat Mar 20 20:07:06 2021 -0400
committer Hyang-Ah Hana Kim <hyangah@gmail.com> Thu Mar 25 19:28:32 2021 +0000
tree a9febf3651e18b9e10dff41d306340fa2bef33aa
parent ffc50bdfb26cd8c9d99819eb78b961e75d39a024

src/goDebugFactory: add ProxyDebugAdapter&DelveDAPOutputAdapter

This change brings in part of the thin adapter
for delve DAP to workaround the problem of forwarding
dlv dap's stdout/stderr to the right debug session's
console, until there is a better API for us to directly
access the console.

See https://github.com/microsoft/vscode/issues/104208
for the discussion.

ProxyDebugAdapter is a vscode.DebugAdapter that proxies
debug protocol message exchanges between VSCode and
another debug adapter connected with a duplex stream.
It does not attempt to interpret/parse the exchanged
message.

DelveDAPOutputAdapter is a ProxyDebugAdapter that
spawns a `dlv dap` process and proxies between VSCode
and the process. It turns the dlv dap process's stdout
and stderr into OutputEvents, so they can be shown
in the debug session's console correctly.

DelveDAPOutputAdapter is used as an inlined debug
adapter and is used only when the remote debug server
port isn't specified. If the debug server port is
specified, we let VSCode handle using its
DebugAdapterServer implementation.

This CL simplifies GoDebugAdapterDescriptorFactory
and fixes dlvDapServer termination logic.
DebugAdapterDescriptorFactory's dispose isn't called
until the extension is terminated. We want to terminate
the process at the end of each DebugSession. VSCode
starts a new debug adapter for a new DebugSession
and disposes it after the session ends.
So, use DelveDAPOutputAdapter's dispose for cleanup.

This potentially opens up possibilities of running
multiple debug sessions.

Testing this code path is yet difficult. I plan to
address it in separate changes. The vscode debug
testsupport works only with either a separate process
that communicates either through stdio or a network
port, not works with an inlined, direct adapter yet.
So, we need to change the thin adapter so that it
can run outside VSCode extension host. That means,

1) the adapter must not depend on 'vscode' api.
2) the binary that runs the adapter in server mode
has to be able to serialize/deserialize DAP protocol
messages exchanged over a stream. We can use vscode
debug adapter package's DebugSession or adopt protocol
handling logic from ProtocolServer.
https://github.com/microsoft/vscode-debugadapter-node/blob/eb025ad2248cb90821f5d2146790e4e9e9ae2502/adapter/src/protocol.ts

And, we may need to change `dlv dap` implementation
not to be sensitive to the directory with which the
`dlv dap` process is spawned, or tweak how the thin
adapter running as a server starts `dlv dap` further.
`dlv dap` by default creates the output of build in
the current directory (./__debug_bin), and if
`dlv dap` runs from a non-writable directory or
without cwd, this will fail. So, we are currently
interpret the program attribute and spawn `dlv dap`
in the directory. We need the same trick to invoke
this thin-adapter as a separate process.

Fixes golang/vscode-go#1346

Change-Id: Ifd6708219e4280314a93799012360d4a9737132e
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/303629
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>