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

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

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

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

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.

Comment From: 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>"

Comment From: 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?

Comment From: 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.

Comment From: 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.

Comment From: 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?

Comment From: andig

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

Comment From: 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.

Comment From: 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?

Comment From: 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.

Comment From: danielpcox

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

Comment From: 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

Comment From: 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:

Comment From: 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 (golang/go#66041).

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

Comment From: andig

@findleyr

are you by any chance working in GOPATH/src?

No

Are you in a multiroot workspace?

If you mean single VScode workspace (not go gwork) with multiple repo/module folders- yes:

If you set "gopls": { "zeroConfig": false } in your settings, does it go away?

No :(

Comment From: andig

In my case all roots are Go projects and have a go.mod (I have removed the two that were not, problem remains). There is not problem when closing the workspace and opening a single project folder.

Comment From: findleyr

Thanks all for following up. What this sounds like is that one of the workspace folders is producing erroneous diagnostics for another, and gopls is merging the diagnostics. This logic definitely changed in the most recent gopls release: previously, gopls would only show diagnostics for one workspace folder at a time, whichever changed last.

However, being aware of the potential for this type of error, I thought that I had guarded against this type of error (in short, it is important that folder A never tries to load a file from folder B). Clearly, there is a bug, but my naive attempts to reproduce have failed: when I add multiple workspace folders, things work as expected.

To confirm my hypothesis, I think it would suffice to check that core operations work in the file with import errors, despite the errors: do things like jump to definition or hover work on a symbol that is imported from the import that is supposedly broken?

Other questions: 1. Are any of the workspace folders nested inside each other? 2. Are any of the workspace folders in a vendor directory? 3. Do any of the workspace folders use a go.work file? 4. Do any of the workspace folders have a local replace of a module in another folder? (i.e. replace foo.com/module => ../otherfolder in the go.mod file.

The answers to these questions will give me an idea of where to head next. If folks here are willing to go back and forth a bit, I can guarantee that we will fix this expediently. Absent a reproducer, the fastest way to diagnose this will be to run a patched version of gopls with additional debugging output. Unfortunately, today is a Google holiday, so I won't be able to put together such a patch until Monday. In the meantime, please downgrade to v0.14.2, or work in a single workspace folder. Sorry for the breakage.

Comment From: andig

do things like jump to definition or hover work on a symbol that is imported from the import that is supposedly broken?

yes

1/2/3: no 4: yes indeed- pointing to one of the other contained folder. It is an application I only ever build locally to push to some cloud provider directly and it is easier to maintain the dependency without updating the module all the time. And removing that folder from the workspace fixing it for me!

Comment From: findleyr

Thank for those responses. @ErwanDL do you also have a local replace directive?

Comment From: ErwanDL

Sorry for not answering earlier, I don't use Github at work so I need to come check in manually more often.

do things like jump to definition or hover work on a symbol that is imported from the import that is supposedly broken?

Yes, they do work.

1. Are any of the workspace folders nested inside each other?

Yes, in my case I have 5 roots to my multi-root workspace, and 4 Go projects nested in there. This is the project structure:

. --> one root of the multi-root workspace
├── .vscode
│   └── monorepo.code-workspace
├── experimental --> one root of the multi-root workspace
│   ├── go.mod
│   ├── scaler --> one root of the multi-root workspace
│   │   └── go.mod
│   └── tester --> one root of the multi-root workspace
│       └── go.mod
└── src --> one root of the multi-root workspace
    └── go.mod

1. Are any of the workspace folders in a vendor directory?

No.

1. Do any of the workspace folders use a go.work file?

No.

1. Do any of the workspace folders have a local replace of a module in another folder? (i.e. replace foo.com/module => ../otherfolder in the go.mod file.

Yes, we have several replace directives. experimental/go.mod contains:

replace experimental.mycompany.dev => ./
replace go.mycompany.dev => ./../src

and experimental/tester/go.mod contains:

replace go.mycompany.dev => ../../src

In the meantime I have downgraded gopls to v0.14.2 as a workaround and it works well.

Comment From: findleyr

Thanks all, I finally understand the bug, have a repro and should be able to fix.

Transferring to the Go issue tracker as this is a gopls bug.

Comment From: gopherbot

Change https://go.dev/cl/569836 mentions this issue: gopls/internal/cache: fix spurious diagnostics in multi-root workspaces

Comment From: gopherbot

Change https://go.dev/cl/569876 mentions this issue: [gopls-release-branch.0.15] gopls/internal/cache: fix spurious diagnostics in multi-root workspaces

Comment From: findleyr

~Hmm, I think the fix above was actually insufficient. Investigating further...~ EDIT: nevermind, my testing workspace was actually broken for legitimate reasons.

Comment From: findleyr

Hi, this should also be fixed in the next gopls prerelease:

go install golang.org/x/tools/gopls@v0.15.2-pre.1

@ErwanDL @andig please let me know if this does not fix the bug for you.

Comment From: andig

Just did and added the offending root. No more errors- LGTM! Much appreciated!

Comment From: ErwanDL

Indeed, looks like it works in v0.15.2-pre.1! Thanks a lot for the quick fix.

Comment From: findleyr

Great, thanks for confirming. gopls@v0.15.2 will be released soon.

Comment From: X-lem

I still seem to get this error :/

$ go version
go version go1.22.1 windows/amd64

$ gopls -v version
Build info
----------
golang.org/x/tools/gopls v0.15.3

$ code -v
1.89.1
dc96b837cf6bb4af9cd736aa3af08cf8279f7685
x64

My setup looks like this.

- Root folder
    - .vscode/
    - client/ (React application)
    - server/ (Go application)
  my-application.code-workspace
  .gitignore

If I open my application via the my-application.code-workspace file I get the error pictured below. I don't get any errors if I open /server folder directly. This issue has only started happening the last 2-3 months. I've tried several of the solutions posted in this thread including reverting back to older versions. Also done a go mod tidy and "Restart Language Server" in vscode.

Comment From: TeddyHarnat

I am also still getting this error