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

andig · 2024-02-29T17:22:33Z

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.

The text was updated successfully, but these errors were encountered:

ErwanDL · 2024-02-29T18:22:47Z

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 · 2024-02-29T18:23:59Z

Hi @andig, a few questions:

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

findleyr · 2024-02-29T18:53:38Z

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.

andig · 2024-02-29T20:13:11Z

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

findleyr · 2024-02-29T21:53:48Z

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.

andig · 2024-03-01T07:27:33Z

@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 :(

andig · 2024-03-01T11:05:34Z

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.

findleyr · 2024-03-01T16:22:53Z

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:

Are any of the workspace folders nested inside each other?
Are any of the workspace folders in a vendor directory?
Do any of the workspace folders use a go.work file?
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.

andig · 2024-03-01T16:57:08Z

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!

findleyr · 2024-03-04T21:48:00Z

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

ErwanDL · 2024-03-06T13:15:45Z

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.

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

Are any of the workspace folders in a vendor directory?

No.

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

No.

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.

findleyr · 2024-03-06T21:42:44Z

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.

gopherbot · 2024-03-07T19:14:38Z

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

gopherbot · 2024-03-08T15:34:27Z

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

…stics in multi-root workspaces In golang/go#66145, users reported spurious import errors in multi-root workspaces. The problem was related to scenarios where module A had a local replace of module B, and the user opened a file F in module B that wasn't in the forward dependencies of module A. In this case, if the View of module A tried to load F, it would get real packages (not command-line-arguments), but due to module graph pruning the View of module A would not have access to the full set of dependencies for module B, resulting in the potential for import errors. Even this would not be a problem, as long as the package that module A loaded for F was not considered a 'workspace' package. Unfortunately a couple of incorrect heuristics in gopls added along with the zero-config work of gopls@v0.15.0 allowed us to diagnose these broken packages: 1. In resolveImportGraph, we called MetadataForFile for each overlay. As a result, the import graph optimization caused gopls to attempt loading packages for each open file, for each View. It was wrong for an optimization to have this side effect. 2. In golang/go#65801, we observed that it was inconsistent to diagnose changed packages independent of whether they're workspace packages. To fix that, I made all open packages workspace packages. It was probably wrong for the set of workspace packages to depend on open files. To summarize a rather long philosophical digression: open files should determine Views, not packages. Fixing either one of these incorrect heuristics would have prevented golang/go#66145. In this CL, we fix (2) by building the import graph based on existing metadata, without triggering an additional load. For (1), we check IsWorkspacePackage in diagnoseChangedFiles to enforce consistency in the set of diagnosed packages. It would be nice to also remove the heuristic that "all open packages are workspace packages", but we can't do that yet as it would mean no diagnostics for files outside the workspace, after e.g. jumping to definition. A TODO is left to address this another day, when we can be less conservative. Fixes golang/go#66145 Change-Id: Ic4cf2bbbb515b6ea0df24b8e6e46c725b82b4779 Reviewed-on: https://go-review.googlesource.com/c/tools/+/569836 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com> (cherry picked from commit 93c0ca5) Reviewed-on: https://go-review.googlesource.com/c/tools/+/569876 Auto-Submit: Robert Findley <rfindley@google.com>

findleyr · 2024-03-08T16:10:02Z

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

findleyr · 2024-03-08T20:08:19Z

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.

andig · 2024-03-08T20:15:20Z

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

ErwanDL · 2024-03-11T15:18:42Z

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

findleyr · 2024-03-11T16:07:56Z

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

X-lem · 2024-05-17T22:17:40Z

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.

TeddyHarnat · 2024-07-16T14:02:46Z

I am also still getting this error

findleyr changed the title ~~import errors/ semantictokens are disabled~~ gopls: import errors with gopls@v0.15.0+ Feb 29, 2024

This comment was marked as resolved.

Sign in to view

findleyr changed the title ~~gopls: import errors with gopls@v0.15.0+~~ gopls: import errors with multi-root workspace and gopls@v0.15.0+ Feb 29, 2024

This comment was marked as resolved.

Sign in to view

This comment was marked as outdated.

Sign in to view

findleyr mentioned this issue Mar 6, 2024

BrokenImport golang/vscode-go#2933

Open

findleyr transferred this issue from golang/vscode-go Mar 6, 2024

findleyr changed the title ~~gopls: import errors with multi-root workspace and gopls@v0.15.0+~~ x/tools/gopls: import errors with multi-root workspace and gopls@v0.15.0+ Mar 6, 2024

gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Mar 6, 2024

gopherbot added this to the Unreleased milestone Mar 6, 2024

findleyr modified the milestones: Unreleased, gopls/v0.15.2 Mar 6, 2024

findleyr added the gopls/metadata Issues related to metadata loading in gopls label Mar 6, 2024

findleyr self-assigned this Mar 7, 2024

gopherbot closed this as completed in golang/tools@93c0ca5 Mar 8, 2024

findleyr reopened this Mar 8, 2024

findleyr closed this as completed Mar 8, 2024

findleyr mentioned this issue Mar 18, 2024

x/tools/gopls: import errors when using go.work replace directives #66425

Closed

gabyhelp mentioned this issue Aug 6, 2024

x/tools/gopls: How to disable error message DuplicateDecl on vscode? #68752

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

andig commented Feb 29, 2024

ErwanDL commented Feb 29, 2024 •

edited

Loading

findleyr commented Feb 29, 2024

findleyr commented Feb 29, 2024

This comment was marked as resolved.

This comment was marked as resolved.

andig commented Feb 29, 2024

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as outdated.

findleyr commented Feb 29, 2024 •

edited

Loading

andig commented Mar 1, 2024

andig commented Mar 1, 2024

findleyr commented Mar 1, 2024

andig commented Mar 1, 2024 •

edited

Loading

findleyr commented Mar 4, 2024

ErwanDL commented Mar 6, 2024 •

edited

Loading

findleyr commented Mar 6, 2024

gopherbot commented Mar 7, 2024

gopherbot commented Mar 8, 2024

findleyr commented Mar 8, 2024 •

edited

Loading

findleyr commented Mar 8, 2024

andig commented Mar 8, 2024

ErwanDL commented Mar 11, 2024

findleyr commented Mar 11, 2024

X-lem commented May 17, 2024 •

edited

Loading

TeddyHarnat commented Jul 16, 2024

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

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

Comments

andig commented Feb 29, 2024

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

Share the Go related settings you have added/edited

Describe the bug

Screenshots or recordings

ErwanDL commented Feb 29, 2024 • edited Loading

findleyr commented Feb 29, 2024

findleyr commented Feb 29, 2024

This comment was marked as resolved.

This comment was marked as resolved.

andig commented Feb 29, 2024

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as outdated.

findleyr commented Feb 29, 2024 • edited Loading

andig commented Mar 1, 2024

andig commented Mar 1, 2024

findleyr commented Mar 1, 2024

andig commented Mar 1, 2024 • edited Loading

findleyr commented Mar 4, 2024

ErwanDL commented Mar 6, 2024 • edited Loading

findleyr commented Mar 6, 2024

gopherbot commented Mar 7, 2024

gopherbot commented Mar 8, 2024

findleyr commented Mar 8, 2024 • edited Loading

findleyr commented Mar 8, 2024

andig commented Mar 8, 2024

ErwanDL commented Mar 11, 2024

findleyr commented Mar 11, 2024

X-lem commented May 17, 2024 • edited Loading

TeddyHarnat commented Jul 16, 2024

ErwanDL commented Feb 29, 2024 •

edited

Loading

findleyr commented Feb 29, 2024 •

edited

Loading

andig commented Mar 1, 2024 •

edited

Loading

ErwanDL commented Mar 6, 2024 •

edited

Loading

findleyr commented Mar 8, 2024 •

edited

Loading

X-lem commented May 17, 2024 •

edited

Loading