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

x/tools/gopls: show error messages about "orphaned" files to the user #31668

Closed
ianthehat opened this issue Apr 25, 2019 · 6 comments
Closed
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@ianthehat
Copy link

There are a few ways we have problems working on a file, and we need to report them to the user in a way that lets them understand and fix the problem
Some causes are:

  • The opened folder is not inside a valid workspace (module, GOPATH, other)
  • The file is excluded by build tags
  • The file is in an excluded folder (or other build system specific rules)
  • The file is a pure overlay for a package we do not recognize

Each of these may require a different mechanism for detection, a different heuristic to suggest the root cause or fix, and maybe a different way to report the error.

@ianthehat ianthehat added FeatureRequest gopls Issues related to the Go language server, gopls. labels Apr 25, 2019
@odeke-em odeke-em changed the title gopls: it is confusing when a go file is not being handled x/tools/cmd/gopls: it is confusing when a go file is not being handled Apr 25, 2019
@gopherbot gopherbot added this to the Unreleased milestone Apr 25, 2019
@stamblerre stamblerre changed the title x/tools/cmd/gopls: it is confusing when a go file is not being handled x/tools/cmd/gopls: clarify error messages, make error messages more visible to the user Jun 5, 2019
@marco-m
Copy link

marco-m commented Jun 12, 2019

Thanks for this ticket Go team! 🙏

@stamblerre stamblerre changed the title x/tools/cmd/gopls: clarify error messages, make error messages more visible to the user x/tools/gopls: clarify error messages, make error messages more visible to the user Jul 2, 2019
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Sep 12, 2019
@gopherbot
Copy link

Change https://golang.org/cl/194018 mentions this issue: internal/lsp: show errors when the user is in the wrong directory

gopherbot pushed a commit to golang/tools that referenced this issue Sep 17, 2019
If we encounter `go list` errors when loading a user's package, we
should try to see if they've encountered any of our common error cases.
They are: 1) a user has GO111MODULE=off, but is outside of their GOPATH,
and 2) a user is in module mode but doesn't have a go.mod file.

Fortunately, go/packages does a great job handling edge cases so gopls
will work well for most of them. The main issue will be unresolved
imports. These show up in DepErrors in `go list`, so go/packages doesn't
propagate them through to the list of errors. This will require changes
to go/packages.

Updates golang/go#31668

Change-Id: Ibd5253b33b38caffeaad54a403c74c0b861fcc14
Reviewed-on: https://go-review.googlesource.com/c/tools/+/194018
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
clintjedwards pushed a commit to clintjedwards/tools that referenced this issue Sep 19, 2019
If we encounter `go list` errors when loading a user's package, we
should try to see if they've encountered any of our common error cases.
They are: 1) a user has GO111MODULE=off, but is outside of their GOPATH,
and 2) a user is in module mode but doesn't have a go.mod file.

Fortunately, go/packages does a great job handling edge cases so gopls
will work well for most of them. The main issue will be unresolved
imports. These show up in DepErrors in `go list`, so go/packages doesn't
propagate them through to the list of errors. This will require changes
to go/packages.

Updates golang/go#31668

Change-Id: Ibd5253b33b38caffeaad54a403c74c0b861fcc14
Reviewed-on: https://go-review.googlesource.com/c/tools/+/194018
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
@stamblerre stamblerre modified the milestones: Unreleased, gopls v1.0 Dec 4, 2019
@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.5.0 Jun 24, 2020
@stamblerre
Copy link
Contributor

I believe that the main remaining case to address here is files excluded by build tags. We should probably show a pop-up saying that we can't map them to any package. (Maybe we should do that for all files we can't place in a package?)

@stamblerre stamblerre changed the title x/tools/gopls: clarify error messages, make error messages more visible to the user x/tools/gopls: show error messages about "orphaned" files to the user Jun 24, 2020
@stamblerre stamblerre modified the milestones: gopls/v0.5.0, gopls/v1.0.0 Jul 22, 2020
@gopherbot
Copy link

Change https://golang.org/cl/253798 mentions this issue: internal/lsp: show a warning message when opening an "orphaned" file

gopherbot pushed a commit to golang/tools that referenced this issue Sep 10, 2020
Build tags are a common stumbling block for users of gopls, as build
tagged files may be excluded from the initial workspace load without a
clear warning. This change adds a check for every opened file to confirm
if it maps to a package. If not, we show a message with suggestions.

A follow-up improvement might be to check if the opened file actually
has build tags to make the error message more precise (and give a better
example config).

Updates golang/go#31668

Change-Id: I829d8546edea65aa08274021bfde8ea2fb6eeaa1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/253798
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@stamblerre
Copy link
Contributor

A few more ideas for how to improve this:

  • Show a diagnostic on the package name, not a pop-up warning
  • Parse the build tags to confirm that the file actually has them

@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.5.1 Sep 17, 2020
@gopherbot
Copy link

Change https://golang.org/cl/256977 mentions this issue: internal/lsp: show orphaned file warnings as diagnostics

@golang golang locked and limited conversation to collaborators Sep 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge 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
Development

No branches or pull requests

4 participants