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.

Sign up for GitHub

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: show error messages about "orphaned" files to the user #31668

Closed
ianthehat opened this issue Apr 25, 2019 · 6 comments
Closed

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

ianthehat opened this issue Apr 25, 2019 · 6 comments
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
gopls/v0.5.1

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 Issues asking for a new feature that does not need a proposal. 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 mentioned this issue Apr 25, 2019
Closed
This was referenced May 1, 2019
Closed
Closed
@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
@stamblerre stamblerre mentioned this issue Aug 6, 2019
Closed
@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
Contributor

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
@stamblerre
internal/lsp: show errors when the user is in the wrong directory
11affa0 
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 <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Cottrell <[email protected]>
clintjedwards pushed a commit to clintjedwards/tools that referenced this issue Sep 19, 2019
@stamblerre @clintjedwards
internal/lsp: show errors when the user is in the wrong directory
6aeba54 
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 <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Cottrell <[email protected]>
@stamblerre stamblerre modified the milestones: Unreleased, gopls v1.0 Dec 4, 2019
@stamblerre stamblerre mentioned this issue Dec 4, 2019
Closed
@stamblerre stamblerre removed the FeatureRequest Issues asking for a new feature that does not need a proposal. label Jan 29, 2020
@stamblerre stamblerre mentioned this issue Feb 12, 2020
Closed
@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
@stamblerre stamblerre mentioned this issue Sep 9, 2020
Closed
@gopherbot
Copy link
Contributor

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
@stamblerre
internal/lsp: show a warning message when opening an "orphaned" file
53e29e9 
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 <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Robert Findley <[email protected]>
@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
Contributor

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.
Assignees
No one assigned
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
Milestone
gopls/v0.5.1
Development

No branches or pull requests
4 participants
@ianthehat @marco-m @stamblerre @gopherbot