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: add a diagnostic (and quick-fix) when a package is outside of go.work #53880

Closed
findleyr opened this issue Jul 14, 2022 · 7 comments
Closed

x/tools/gopls: add a diagnostic (and quick-fix) when a package is outside of go.work #53880

findleyr opened this issue Jul 14, 2022 · 7 comments
Assignees
@findleyr
Labels
FeatureRequest gopls/workspace Issues related to support for modules or multi-module workspaces. gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.12.0

Comments

@findleyr
Copy link
Contributor

It can be very confusing when gopls does not function properly because a package is excluded by go.work.

We should provide a friendly error message, preferably as a diagnostic on the package name and/or module name, with a quick fix to add the module to go.work.
@findleyr findleyr added this to the gopls/later milestone Jul 14, 2022
@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 Jul 14, 2022
@ansaba ansaba added the gopls/workspace Issues related to support for modules or multi-module workspaces. label Jul 14, 2022
@thediveo
Copy link

Just for clarification: by "is excluded by go.work" do you mean that a Go module isn't listed in a use statement in a go.mod?

@findleyr
Copy link
Contributor Author

@thedive I mean "a go.work is in use, and the current module is not used". You said "a use statement in a go.mod", but I think you mean "... in a go.work".

So if I have a go.work using mod1 but not mod2, and I open mod2, I should get a diagnostic suggesting that many gopls features will not work in mod2, and that this can be fixed by adding it to go.work.

@thediveo
Copy link

@findleyr yes, exactly, the "in a go.work" is important, too!

@findleyr findleyr mentioned this issue Aug 4, 2022
Closed
@findleyr findleyr modified the milestones: gopls/later, gopls/v0.10.0 Aug 4, 2022
@findleyr findleyr modified the milestones: gopls/v0.10.0, gopls/later Sep 1, 2022
@findleyr findleyr assigned pjweinb and unassigned findleyr Oct 12, 2022
@findleyr
Copy link
Contributor Author

From in-person discussion, this can be achieved approximately as follows:

In Server.checkForOrphanedFiles, where we generate the "No packages found" diagnostic, we need to determine if a go work use command could potentially fix the problem. For this, we can use the following heuristic:

  • GOWORK is set (check snapshot.WorkFile)
  • The orphaned file is in a module (check parent directories for a go.mod file)
  • That directory is not included in the go.work file (call snapshot.ParseWork for the workfile uri)

If these conditions hold, then we can suggest a quickfix to run go work use . from the directory containing the file. The Go command should do the right thing.

We could go further and try to check whether the file would be excluded by build tags even if we use its module, but that is probably overkill.

@gopherbot
Copy link

Change https://go.dev/cl/448695 mentions this issue: internal/lsp/cache: clean up workspace information tracking

@findleyr findleyr modified the milestones: gopls/later, gopls/v0.12.0 Dec 29, 2022
@findleyr findleyr mentioned this issue Apr 4, 2023
Closed
@findleyr findleyr assigned findleyr and unassigned pjweinb May 11, 2023
@gopherbot
Copy link

Change https://go.dev/cl/494675 mentions this issue: gopls: improve diagnostics for orphaned files

gopherbot pushed a commit to golang/tools that referenced this issue May 12, 2023
@findleyr
gopls: improve diagnostics for orphaned files
1c9fe3f 
Fix some of the very misleading errors gopls produces when it can't find
packages for a file. Try to diagnose _why_ a file is orphaned by the
workspace, rather than just guess that it may be due to build
constraints. Only put diagnostics on files that we can prove are
excluded in some way.

To achieve this, we need to be able to differentiate
command-line-arguments packages that are standalone packages, so add a
corresponding field on source.Metadata.

Refactor/simplify some functions that operate on open files. In the
future, we really should track overlays separately in the snapshot, but
that is out-of-scope for now.

Also make a minor fix for TestImplementationsOfError: I use $HOME/src as
my development directory, so GOROOT/src is $HOME/src/go/src.

For golang/go#53880

Change-Id: I8e9fa7d4f2c03ce3daaab7c6d119b4276ec6da79
Reviewed-on: https://go-review.googlesource.com/c/tools/+/494675
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@gopherbot
Copy link

Change https://go.dev/cl/494738 mentions this issue: gopls/internal/lsp: add quick-fixes to manage the go.work file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@findleyr findleyr

Labels
FeatureRequest gopls/workspace Issues related to support for modules or multi-module workspaces. gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.12.0
Development

No branches or pull requests
5 participants
@ansaba @pjweinb @thediveo @gopherbot @findleyr