-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: publishDiagnostics is unstable #65801
Comments
@hyangah thanks for reporting... This does reproduce with v0.15.0-pre.3 for me. Therefore, this is a critical bug that must block the v0.15.0 release. |
Change https://go.dev/cl/565475 mentions this issue: |
Change https://go.dev/cl/565457 mentions this issue: |
…d to workspace packages Fix two bugs related to workspace packages that contributed to golang/go#65801. The first is that we didn't consider packages with open files to be workspace packages. This was pre-existing behavior, but in the past we simply relied on diagnoseChangedFiles to provide diagnostics for open packages, even though we didn't consider them to be part of the workspace. That led to races and inconsistent behavior: a change in one file would wipe out diagnostics in another, and so on. It's much simpler to say that if the package is open, it is part of the workspace. This leads to consistent behavior, no matter where diagnostics originate. The second bug is related to loading std and cmd. The new workspace package heuristics relied on go/packages.Package.Module to determine if a package is included in the workspace. For std and cmd, this field is nil (golang/go#65816), apparently due to limitations of `go list`. As a result, we were finding no workspace packages for std or cmd. Fix this by falling back to searching for the relevant go.mod file in the filesystem. Unfortunately this required reinstating the lockedSnapshot file source. These bugs revealed a rather large gap in our test coverage for std. Add a test that verifies that we compute std workspace packages. Fixes golang/go#65801 Change-Id: Ic454d4a43e34af10e1224755a09d6c94c728c97d Reviewed-on: https://go-review.googlesource.com/c/tools/+/565475 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 607b664) Reviewed-on: https://go-review.googlesource.com/c/tools/+/565457
Change https://go.dev/cl/569836 mentions this issue: |
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>
Change https://go.dev/cl/569876 mentions this issue: |
…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>
gopls version
go env
What did you do?
src
dir of the Go project.src/cmd/go/internal/load/pkg.go
in the Go project.PackagePublic
(but, not update the references). For example,What did you see happen?
Expected gopls to detect build breakage ("has no field or method Name" error), across many packages.
What did you expect to see?
Gopls published diagnostics for some files and then soon empty diagnostics for all those files. This empty diagnostic message makes vscode (client) clears all diagnostics immediately.
Editor and settings
Logs
And, the session info:
The text was updated successfully, but these errors were encountered: