Fixes golang/vscode-go#779 by:

• A test program that spins up a server at http://localhost:8080 to return helloworld.
• Adding 4 remote attach tests:

1. Attaching to a headless instance of Delve running the program. This tests that the initialization sequence up to configuration done request is good.
2. Attaching with a breakpoint already set. This tests that the breakpoint is hit when we hit the program's URL.
3. Attaching without any breakpoint and set the breakpoint afterwards. This tests that the breakpoint is hit when we hit the program's URL.
4. Test that the program still runs after we disconnect from it.

The issues being fixed in this PR:

1. There are instances where we are issuing a blocking call to Delve while it is running. That blocks subsequent requests to Delve and can cause the debugger to appear as hanged. Hence, we will need to check Delve's debug state before issuing blocking request in stacktraceRequest and threadsRequest (fixes golang/vscode-go#740).

2. When disconnecting, multiple requests disconnectRequest can be received. Subsequent disconnectRequest should not invoke Delve through the JSON RPC connection again as this may already be closed so we need to guard against that (fixes golang/vscode-go#766).

3. Also, even if Delve is blocked in disconnectRequest, disconnectResponse should always be sent back to VSCode after a period of time. Otherwise, in the case of Theia in particular, users will not be able to reset (fixes golang/vscode-go#761).

4. In close function of Delve class, we are not resolving a promise in the case of remote debugging and this causes the close function to hang and not send the disconnectResponse back (fixes golang/vscode-go#764).

5. Add more logging to help us easily debug similar scenarios in the future (fixes golang/vscode-go#763).

Repro

1. Clones a Go program (for example: https://github.com/GoogleCloudPlatform/cloud-code-samples/tree/master/golang/go-hello-world).
2. Runs the program in Delve through a terminal: dlv debug --continue --accept-multiclient --api-version=2 --headless --listen=:3456 --log
3. Connect to it by creating a configuration:

        {
            "name": "Connect to server",
            "type": "go",
            "request": "attach",
            "mode": "remote",
            "remotePath": "${workspaceFolder}",
            "port": 3456,
            "host": "127.0.0.1",
            "cwd": "${workspaceFolder}"
        }

4. Sets a breakpoint and sees that it's not working.
5. Disconnecting also does not work.

Copied from https://github.com/microsoft/vscode-go/issues/3179:

If you encounter this issue, please try the following steps to troubleshoot:

1. Check your other installed extensions and see if disabling them but the Go extension helps. Go Group Imports, Spell Right, and Go Test Explorer have both been identified as causing slow saves.
2. Your workspace may have errors which are causing gopls to be slow. Capture your gopls logs (instructions) and post them in a new issue (if you're able to share them). Detailed gopls logs are best, so please add -rpc.trace to go.languageServerFlags.

For reference, this bug is referring to an error that appears like this:

This issue consolidates https://github.com/microsoft/vscode-go/issues/3179, https://github.com/microsoft/vscode-go/issues/3063, https://github.com/microsoft/vscode-go/issues/3105, https://github.com/microsoft/vscode-go/issues/3141, https://github.com/microsoft/vscode-go/issues/3170, etc.

New launch modes: replay and core

The following modes are added:

• replay: Replays an rr trace, allowing backwards flows (reverse continue and stepback). Requires a traceDirPath property on launch.json pointing to a valid rr trace directory. Equivalent to dlv replay <tracedir> command.
• core: Replays a core dump file, showing its callstack and the file matching the callsite. Requires a coreFilePath property on launch.json pointing to a valid coredump file. Equivalent to dlv core <exe> <corefile> command.

With the new dap service, most of the heavy work will go to delve, so this PR mainly involves getting around passing the corresponding launchArgs to delve. It´s service counterpart lies on https://github.com/go-delve/delve/pull/2367

Fixes #168 Fixes #1243 Updates #110

What this does:

• Implements a test provider using the new API
• Populates the test explorer with a list of modules and/or workspaces
• Populates each module/workspace/package/file as it is expanded
• Creates test entries for the current file, and package/module parents
• Runs tests!

What this does not:

• Debug tests
• Handle stretchr suites

Issues:

• Handling of benchmarks isn't great. But I'm not sure it can get much better without changes to go test.
• If a test has subtests, I add those subtests. This can get annoying if you have a bunch of subtests. Should this be configurable? Disabling testing.followRunningTest can improve this UX.

Fixes golang/vscode-go#1579

Add ability to debug with Delve with sudo flag. Similar as it it done for Python: https://code.visualstudio.com/docs/python/debugging#_sudo

It is needed to debug modules that require root access, i.e. gopacket/pcap to capture traffic.

Delve supports debug adapter protocol natively (dlv dap). https://github.com/go-delve/delve/tree/master/service/dap

Implement the debug feature using it and deprecate the dlv wrapper (src/debug/goDebug.ts).

@polinasok @quoctruong @ramya-rao-a

This change modifies the extension to check for the go module name matching before setting a breakpoint. The bug this is trying to address (summed up by @hyangah):

In the go-guestbook sample, there are two go programs (frontend/main.go and backend/main.go). They will start in separate containers - each of which builds main.go by copying the code into a work directory and running go build there. The frontend and the backend happen to be in different modules in this sample.

VS Code supports debugging two binaries together - a user can set breakpoints in both frontend/main.go and backend/main.go. VS Code by design sends breakpoint requests for all the files to all the debug adapters.

Since we cannot make any assumption on where the source code is copied in the remote container (i.e. in the sample, frontend/main.go is copied to /app/frontend/main.go, but it's also possible that the user just copy the source code to /app and build the binary from /app), the debug adapter tries to find the best match by doing some sort of longest suffix matching.

So, this longest suffix matching will end up associating /app/frontend/main.go on the remote frontend container with both frontend/main.go and backend/main.go in this specific example. As a result, the breakpoints set in backend/main.go will apply to the frontend/main.go.

Updates golang/vscode-go#23

This DA serves as a DAP proxy between the editor and a DAP-capable Delve. Right now all it does is launch Delve (in DAP mode) when LaunchRequest is received from the editor, and then relays all messages between the editor and Delve back and forth.

package.json section is copied from the current DA as-is. Some of its options will be removed and cleaned up in the subsequent PRs to make the diffs more obvious (see golang/vscode-go#271).

What version of Go, VS Code & VS Code Go extension are you using?

• Run go version to get version of Go
  • go version go1.15.2 darwin/amd64
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders
  • 1.51.1 e5a624b788d92b8d34d1392e4c4d9789406efe8f x64
• Check your installed extensions to get the version of the VS Code Go extension
  • v0.18.1
• Run go env to get the go development environment details
  • GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/ss/Library/Caches/go-build" GOENV="/Users/ss/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/ss/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/ss/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/Cellar/go/1.15.2/libexec" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.15.2/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" ...

Share the Go related settings you have added/edited

None.

Describe the bug

Every time I restart vscode, it shows: Failed to find the "go" binary in either。GOROOT() or PATH(/usr/bin:/bin:/usr/sbin:/sbin). Check PATH, or Install Go and reload the window.

It seems the PATH(/usr/bin:/bin:/usr/sbin:/sbin) from the message is not my actual path:

$ cat /etc/paths
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
$ which go
/usr/local/bin/go

And if I manually did Developer: reload window once after terminal started, it would work without errors.

Steps to reproduce the behavior:

1. Clear all settings about go in vscode, make it all defaults
2. Make sure your executable go not in /usr/bin:/bin:/usr/sbin:/sbin
3. Add sleep 15 to ~/.bash_profile to make terminal very slow to up
4. Restart vocode

Screenshots or recordings

Refs may help:

• https://github.com/microsoft/vscode/issues/108804
• https://github.com/microsoft/vscode/issues/108003

From https://github.com/microsoft/vscode-go/issues/843

Please support "console" Property in launch.json, which have "none", "integratedTerminal", "externalTerminal" three Value like python's, and I can debug my go project at outside console and also support standard input.

This feature request has a lot of upvotes https://github.com/microsoft/vscode-go/issues/843, please follow the discussion there for more context and user scenarios where this feature would be relevant

gopls version: v0.11.0 (go1.19.2) gopls flags: update flags: proxy extension version: 0.37.0 go version: 1.19.2 environment: Visual Studio Code linux initialization error: undefined issue timestamp: Tue, 03 Jan 2023 13:50:57 GMT restart history: Tue, 03 Jan 2023 12:08:08 GMT: activation (enabled: true) Tue, 03 Jan 2023 12:19:48 GMT: installation (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0xb8307d]

goroutine 167 [running]:
golang.org/x/tools/gopls/internal/lsp/mod.hoverOnModuleStatement({0x10e0860%3F, 0xc0004cbef0%3F}, 0xc0004cbef0%3F, 0x10e0ac8%3F, {0x10ecbd8%3F, 0xc00040e840%3F}, {0x10e0ac8%3F, 0xc0003fd490%3F})
	  hover.go:128  0x5d
golang.org/x/tools/gopls/internal/lsp/mod.Hover({0x10e07b8, 0xc000388140}, {0x10ecbd8, 0xc00040e840}, {0x10e0ac8, 0xc0003fd490}, {0x4cbe30%3F, 0xc0%3F})
	  hover.go:50  0x35f
golang.org/x/tools/gopls/internal/lsp.(*Server).hover(0xcfcce0%3F, {0x10e07b8, 0xc000388140}, 0xc0004cbe30)
	  hover.go:25  0x152
golang.org/x/tools/gopls/internal/lsp.(*Server).Hover(0xc000266070%3F, {0x10e07b8%3F, 0xc000388140%3F}, 0xcfcce0%3F)
	  server_gen.go:140  0x25
golang.org/x/tools/gopls/internal/lsp/protocol.serverDispatch({0x10e07b8, 0xc000388140}, {0x10f05a0, 0xc000166500}, 0xc0004cbe00, {0x10e0ba8, 0xc0003880c0})
	  tsserver.go:397  0xca6
golang.org/x/tools/gopls/internal/lsp/protocol.ServerHandler.func1({0x10e07b8, 0xc000388140}, 0xc0004cbe00, {0x10e0ba8, 0xc0003880c0})
	  protocol.go:157  0x90
golang.org/x/tools/gopls/internal/lsp/lsprpc.handshaker.func1({0x10e07b8, 0xc000388140}, 0xc0004cbe00, {0x10e0ba8%3F, 0xc0003880c0%3F})
	  lsprpc.go:519  0xa39
golang.org/x/tools/internal/jsonrpc2.MustReplyHandler.func1({0x10e07b8, 0xc000388140}, 0xc0004cd4d0, {0x10e0ba8%3F, 0xc0003880c0%3F})
	  handler.go:35  0xf6
golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1.2()
	  handler.go:103  0xa3
created by golang.org/x/tools/internal/jsonrpc2.AsyncHandler.func1
	  handler.go:100  0x20a
[Error - 5:20:53 PM] 

gopls version: v0.10.1 (go1.19.3) gopls flags: update flags: local extension version: 0.37.0 go version: 1.19.3 environment: Visual Studio Code linux initialization error: undefined issue timestamp: Fri, 30 Dec 2022 11:31:39 GMT restart history: Fri, 30 Dec 2022 11:21:16 GMT: activation (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

gopls version: v0.10.1 (go1.19.3) gopls flags: update flags: local extension version: 0.37.0 go version: 1.19.3 environment: Visual Studio Code - Insiders linux initialization error: undefined issue timestamp: Thu, 29 Dec 2022 12:04:16 GMT restart history: Thu, 29 Dec 2022 11:40:49 GMT: activation (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

gopls version: v0.11.0 (go1.16.15) gopls flags: update flags: proxy extension version: 0.37.0 go version: 1.16.15 environment: Visual Studio Code linux initialization error: undefined issue timestamp: Thu, 29 Dec 2022 08:18:27 GMT restart history: Thu, 29 Dec 2022 07:39:24 GMT: activation (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

Type: Feature Request

增加依赖库显示

依赖库 有时会有问题，需要导到本地修改，这边导到本地得自己找所以需要依赖库显示，方便拿出来

Extension version: 0.37.0 VS Code version: Code 1.74.2 (e8a3071ea4344d9d48ef8a4df2c097372b0c5161, 2022-12-20T10:29:14.590Z) OS version: Windows_NT x64 10.0.19042 Modes: Sandboxed: Yes

As reported in https://github.com/dominikh/go-tools/issues/1342 https://github.com/dominikh/go-tools/issues/1343.

The version compatible with go1.20 is not yet released.