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/go/packages: Package.Module is unset for std and cmd modules #65816
Labels
Milestone
Comments
gopherbot
added
the
Tools
This label describes issues relating to any tools in the x/tools repository.
label
Feb 20, 2024
Change https://go.dev/cl/565477 mentions this issue: |
prattmic
added
the
NeedsFix
The path to resolution is known, but the work has not been done.
label
Feb 20, 2024
Change https://go.dev/cl/565475 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Feb 20, 2024
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>
Change https://go.dev/cl/565457 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Feb 20, 2024
Updates golang/go#65816 Change-Id: I76db031fc8c1b23caeabe0360db34e1126184e2f Reviewed-on: https://go-review.googlesource.com/c/tools/+/565477 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org>
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Feb 20, 2024
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The gopackages command (patched as shown at the end) displays the module of each package:
But for standard packages and tools, it shows nothing:
This seems like a bug. Even if "go list" doesn't report Module information for standard packages, go/packages should probably synthesize something. Either way, it should document what it actually does.
The text was updated successfully, but these errors were encountered: