Navigation Menu

Skip to content
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

Jump to bottom

x/tools/gopls: inform user about excluded/orphaned files due to nested or multiple modules #42109

Closed
stamblerre opened this issue Oct 21, 2020 · 3 comments
Closed

x/tools/gopls: inform user about excluded/orphaned files due to nested or multiple modules #42109

stamblerre opened this issue Oct 21, 2020 · 3 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Soon This needs to be done soon. (regressions, serious bugs, outages) Tools This label describes issues relating to any tools in the x/tools repository.
Projects
vscode-go: gopls by default
Milestone
gopls/v0.6.0

Comments

@stamblerre
Copy link
Contributor

When a workspace contains multiple modules without experimentalWorkspaceModule, some of the modules may be excluded or ignored. We should show a diagnostic on every opened "excluded" file (analogous to the build tag diagnostics) that informs the user of the issue and redirects them to clear documentation on how to add workspace folders or enable experimentalWorkspaceModule.
@gopherbot 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 Oct 21, 2020
@gopherbot gopherbot added this to the Unreleased milestone Oct 21, 2020
@stamblerre stamblerre mentioned this issue Oct 21, 2020
Closed
@stamblerre stamblerre added the Soon This needs to be done soon. (regressions, serious bugs, outages) label Oct 30, 2020
@stamblerre stamblerre added this to Needs Triage in vscode-go: gopls by default Nov 10, 2020
@stamblerre stamblerre moved this from Needs Triage to Critical in vscode-go: gopls by default Nov 10, 2020
@stamblerre stamblerre changed the title x/tools/gopls: show diagnostics for excluded/orphaned files x/tools/gopls: inform user about excluded/orphaned files due to nested or multiple modules Nov 11, 2020
@stamblerre stamblerre mentioned this issue Nov 18, 2020
Closed
@stamblerre stamblerre self-assigned this Nov 23, 2020
@gopherbot
Copy link

Change https://golang.org/cl/272346 mentions this issue: internal/lsp: improve errors in multi-module workspaces (GO111MODULE=on)

gopherbot pushed a commit to golang/tools that referenced this issue Dec 1, 2020
@stamblerre
internal/lsp: improve errors in multi-module workspaces (GO111MODULE=on)
7beb506 
Currently, when a user opens a workspace with no top-level module but
multiple modules in subdirectories, gopls treats that as an invalid
build configuration and reports an error message that may be difficult
for the user to understand (a go list error message about creating a
main module in the top-level directory). Instead, show a more useful
error message about the gopls workspace layout in both the progress bar
and as a diagnostic on every open file.

This fix only works for GO111MODULE=on (for now) because it's a lot
easier to interpret user intent, and the go command will return no
packages. The next step will be to improve error messaging for
GO111MODULE=auto and for users with nested modules.

Updates golang/go#42109

Change-Id: I702ca6745f7e080ff6704ade7843972ab469ccf3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272346
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

Change https://golang.org/cl/275553 mentions this issue: internal/lsp: show multiple modules error message with GO111MODULE=auto

gopherbot pushed a commit to golang/tools that referenced this issue Dec 8, 2020
@stamblerre
internal/lsp: show multiple modules error message with GO111MODULE=auto
e652b2f 
When GO111MODULE=auto and the workspace is outside of $GOPATH/src, we
should still show diagnostics about how to correctly configure
multi-module workspaces. We should not show these warnings for
workspaces outside of a module within GOPATH.

This adds an extra piece to the WorkspacePackages error logic--we may
still need to show the errors even if WorkspacePackages returned
results. We should eventually consolidate all of this logic to be more
cohesive, but for now I think it's more important to cover all of the
different cases and add tests.

Updates golang/go#42109

Change-Id: I673a03c9840cdaaf7f058de1cda3bf36b96fa7d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275553
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

Change https://golang.org/cl/275554 mentions this issue: internal/lsp: add an orphaned file diagnostic for nested modules

vscode-go: gopls by default automation moved this from Critical to Done Dec 10, 2020
marwan-at-work pushed a commit to marwan-at-work/tools that referenced this issue Dec 23, 2020
@stamblerre @marwan-at-work
internal/lsp: improve errors in multi-module workspaces (GO111MODULE=on)
d8df960 
Currently, when a user opens a workspace with no top-level module but
multiple modules in subdirectories, gopls treats that as an invalid
build configuration and reports an error message that may be difficult
for the user to understand (a go list error message about creating a
main module in the top-level directory). Instead, show a more useful
error message about the gopls workspace layout in both the progress bar
and as a diagnostic on every open file.

This fix only works for GO111MODULE=on (for now) because it's a lot
easier to interpret user intent, and the go command will return no
packages. The next step will be to improve error messaging for
GO111MODULE=auto and for users with nested modules.

Updates golang/go#42109

Change-Id: I702ca6745f7e080ff6704ade7843972ab469ccf3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272346
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
marwan-at-work pushed a commit to marwan-at-work/tools that referenced this issue Dec 23, 2020
@stamblerre @marwan-at-work
internal/lsp: show multiple modules error message with GO111MODULE=auto
48e2f65 
When GO111MODULE=auto and the workspace is outside of $GOPATH/src, we
should still show diagnostics about how to correctly configure
multi-module workspaces. We should not show these warnings for
workspaces outside of a module within GOPATH.

This adds an extra piece to the WorkspacePackages error logic--we may
still need to show the errors even if WorkspacePackages returned
results. We should eventually consolidate all of this logic to be more
cohesive, but for now I think it's more important to cover all of the
different cases and add tests.

Updates golang/go#42109

Change-Id: I673a03c9840cdaaf7f058de1cda3bf36b96fa7d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275553
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
marwan-at-work pushed a commit to marwan-at-work/tools that referenced this issue Dec 23, 2020
@stamblerre @marwan-at-work
internal/lsp: add an orphaned file diagnostic for nested modules
ddcabaa 
This change adds a diagnostic and error message that appears when a user
edits a nested module in legacy mode. At first, I thought a diagnostic
would be enough, but it's actually quite difficult to spot it when you
have a bunch of "undeclared name" diagnostics caused by the nested
module, so I figured a progress bar error message would also be useful.

This error message just indicates to the user that they should open the
nested module as its own workspace folder.

Also, while debugging this, I noticed that command-line-arguments
packages can have test variants, which we were never handling.
So I addressed that in this change.

Fixes golang/go#42109

Change-Id: Ifa6f6af401a3725835c09b76e35f889ec5cb8901
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275554
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@golang golang locked and limited conversation to collaborators Dec 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Soon This needs to be done soon. (regressions, serious bugs, outages) Tools This label describes issues relating to any tools in the x/tools repository.
Projects
No open projects
vscode-go: gopls by default
  
Done
Milestone
gopls/v0.6.0
Development

No branches or pull requests
2 participants
@stamblerre @gopherbot