x/tools/gopls: import errors with multi-root workspace and gopls@v0.15.0+

[andig]

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

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.
  go version go1.22.0 darwin/arm64
• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.

Build info
----------
golang.org/x/tools/gopls v0.15.1
    golang.org/x/tools/gopls@v0.15.1 h1:WBLlqa3auWKt/jbezarYT204f7IDtCdOn260vY0q4Vk=
    github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
    github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
    golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y=
    golang.org/x/mod@v0.15.0 h1:SernR4v+D55NyBH2QiEQrlBAnj1ECL6AGrA5+dPaMY8=
    golang.org/x/sync@v0.6.0 h1:5BMeUDZ7vkXGfEr1x9B4bRcTH4lpkTkpdh0T/J+qjbQ=
    golang.org/x/telemetry@v0.0.0-20240209200032-7b892fcb8a78 h1:vcVnuftN4J4UKLRcgetjzfU9FjjgXUUYUc3JhFplgV4=
    golang.org/x/text@v0.14.0 h1:ScX5w1eTa3QqT8oi6+ziP7dTV1S2+ALU0bI+0zXKWiQ=
    golang.org/x/tools@v0.18.1-0.20240227180630-1c466157abc9 h1:DAFzI/OUTyNjVKs2nsM593aR8oHWjVh3ftZ7XQFEKXw=
    golang.org/x/vuln@v1.0.1 h1:KUas02EjQK5LTuIx1OylBQdKKZ9jeugs+HiqO5HormU=
    honnef.co/go/tools@v0.4.6 h1:oFEHCKeID7to/3autwsWfnuv69j3NsfcXbvJKuIcep8=
    mvdan.cc/gofumpt@v0.6.0 h1:G3QvahNDmpD+Aek/bNOLrFR2XC6ZAdo62dZu65gmwGo=
    mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: go1.22.0

• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.

Version: 1.87.0 (Universal)
Commit: 019f4d1419fbc8219a181fab7892ebccf7ee29a2
Date: 2024-02-27T23:42:56.944Z (1 day ago)
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Darwin arm64 23.2.0

• Check your installed extensions to get the version of the VS Code Go extension
• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.

Share the Go related settings you have added/edited

Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.

    "go.gopath": "~/go",
    "go.useLanguageServer": true,
    "gopls": {
        "formatting.gofumpt": true,
    },
    "go.languageServerFlags": [
        "serve",
        "-rpc.trace",
        "--debug=localhost:6060"
    ],

Describe the bug

For some days, gopls has started complaining about missing imports. go.mod and go.sum are clean and project compiles.

Extension host shows errors:

2024-02-29 18:21:56.462 [error] [golang.go] provider FAILED
2024-02-29 18:21:56.462 [error] Error: semantictokens are disabled
    at handleResponse (/Users/andig/.vscode/extensions/golang.go-0.41.1/dist/goMain.js:8606:40)
    at handleMessage (/Users/andig/.vscode/extensions/golang.go-0.41.1/dist/goMain.js:8416:11)
    at processMessageQueue (/Users/andig/.vscode/extensions/golang.go-0.41.1/dist/goMain.js:8431:13)
    at Immediate.<anonymous> (/Users/andig/.vscode/extensions/golang.go-0.41.1/dist/goMain.js:8407:11)
    at processImmediate (node:internal/timers:476:21)

Screenshots or recordings

If applicable, add screenshots or recordings to help explain your problem.

[ErwanDL]

Noticed the same bug in my multiroot workspace setup. Manually reverting gopls to v0.14.2 solved the issue for me, it seems it was brought by gopls v0.15.0.

EDIT: a bit more info:

• The problem seems to disappear when I open each Go module individually, as opposed to in the multiroot workspace setup.
• Both stdlib imports, local imports (to my own modules) and third-party imports fail. The error messages are varied: sometimes it shows up as module lookup disabled by GOPROXY=off, other times as no required module provides package "<package_name>", or even missing metadata for import of "<package_name>"

[findleyr]

Hi @andig, a few questions:

1. are you by any chance working in GOPATH/src?
2. Are you in a multiroot workspace?
3. If you set "gopls": { "zeroConfig": false } in your settings, does it go away?

[findleyr]

Also: needless to say, but if any of this is in an open source repo (or set of repos), a reproducer would be the fastest way to investigate.

[danielpcox]

I and a coworker also had this problem with v0.15.0, and this fixed it for both of us: go install -v golang.org/x/tools/gopls@v0.14.2 && pkill gopls. Our go.mod is in a subdirectory of the repo root, but we have the problem whether or not we open the subdirectory as the workspace root in VS Code.

[findleyr]

@danielpcox thanks, but installing gopls@v0.14.2 isn't really a fix. This is a regression in gopls@v0.15.0, and we need more information to help diagnose it -- it doesn't reproduce for us, and given that it took a few days for this to be reported I suspect it's not affecting a very large number of users. Therefore, we need to understand what is happening in the cases where this bug appears.

Are you also in a multi-root repository? If you set "gopls": { "zeroConfig": false } in your settings, does it go away in v0.15.0?

[andig]

Multi root for me, will add more diag when back at machine

[danielpcox]

I'm not multi-root. One root in the VS Code workspace.
"gopls": { "zeroConfig": false } does not fix the problem for me in v0.15.0.
If this helps, my dependencies are vendored.

[findleyr]

Hmm, I was about to say that this seems highly correlated with multi-root setups, until @danielpcox's counter example.
Is anyone here working in GOPATH/src? That seemed related in one other instance.
@andig do the problems go away when you open one module individually?
In these multi-root setups, do all roots have a go.mod file? Are some of them non-go?

[danielpcox]

I think I made a mistake. "Multi-root" could mean VS Code multi-root workspace, or it could mean a repository with multiple go.mod files in subdirectories. I thought you meant the former. We do have multiple go.mod files in different subdirectories of the git repository, and none in the root of the repo. We see the problem whether or not we open the particular subdirectory as the single root of the VS Code workspace.

[danielpcox]

We are not working in $GOPATH/src.
Not all subdirectories of our repository have a go.mod.
Some of them are non-go.

[danielpcox]

Also, I have nothing specific to Go in my settings.json, other than the test of "gopls": { "zeroConfig": false }.
VS Code 1.86.2
vscode-go v0.41.1
Failing versions of gopls: 0.15.0 and 0.15.1

[itsaerie]

Greetings, tagging in with some reproduction steps of the issue for a single-root project:

[VS Code v1.87.0, vscode-go v0.41.1, gopls v0.15.1, go v1.20]

• Create folder for new VSCode workspace.
• Create subfolder within VSCode workspace.
• Create *.go file within subfolder, using an import that isn't in default Golang packages.
• Create a go.mod file within the subfolder.
• Run go mod tidy && go mod vendor within the subfolder.
• Have the issue when in VSCode.

CLI:

cd ~
mkdir temp
mkdir idk
touch temp.go
touch go.mod
# do editing to temp.go and go.mod
go mod tidy
go mod vendor

temp.go:

package main

import (
	"fmt"

	"github.com/spf13/viper"
)

func main() {
	viper.SetDefault("something", "else")
	fmt.Println("hello world")
}

go.mod: (before go commands)

module something

go 1.20

Screenshot with issue below:

Screenshot with final dir structure, and temp.go contents below:

[findleyr]

It turns out that @danielpcox and @itsaerie both work at Google, and we have a Google-internal go/packages driver. The presence of this driver caused the "zero config" logic of gopls@v0.15.0 and later to throw up its hands: if the user has a go/packages driver we can't make any assumptions about how packages are laid out... Of course, this regression for Googlers was unintended. For now, the workaround is to explicitly set GOPACKAGESDRIVER=off in the environment of the gopls process, by setting

{
  "go.toolsEnvVars": {
    "GOPACKAGESDRIVER": "off"
  }
}

I will fix this in a subsequent release (#66041).

Marking comments related to GOPACKAGESDRIVER as resolved, as I think they represent a separate issue. All other comments relate to multi-root workspaces.