-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
Comments
Change https://go.dev/cl/565477 mentions this issue: |
Change https://go.dev/cl/565475 mentions this issue: |
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: |
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>
…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
Related: #61174 (comment) |
Change https://go.dev/cl/588141 mentions this issue: |
Package is both the "cooked" result data type of a Load call, and the "raw" JSON schema used by DriverResponse. This change documents the fields that are part of the protocol, and ensures that the others are omitted from the JSON encoding. (They are populated by the post- processing done by 'refine', if the appropriate Need bits are set.) Also - document that there are a number of open bugs in places where it may be likely to help, particularly Mode-related issues. - document that Load returns new Packages, using distinct symbol realms (types.Importers). - document Overlays in slightly more detail. Fixes golang/go#67614 Fixes golang/go#61418 Fixes golang/go#67601 Fixes golang/go#43850 Updates golang/go#65816 Updates golang/go#58726 Updates golang/go#56677 Updates golang/go#48226 Updates golang/go#63517 Updates golang/go#56633 Change-Id: I2f5f2567baf61512042fc344fca56494f0f5e638 Reviewed-on: https://go-review.googlesource.com/c/tools/+/588141 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
Fixes #371 See golang/go#65816 --------- Signed-off-by: Eliott Bouhana <eliott.bouhana@datadoghq.com> Co-authored-by: Romain Marcadier <romain@datadoghq.com>
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: