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

Open
findleyr opened this issue Jul 14, 2022 · 3 comments
Labels
FeatureRequest gopls/workspace gopls Tools
Milestone

Comments

@findleyr
Copy link
Contributor

findleyr commented Jul 14, 2022

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 gopls labels Jul 14, 2022
@ansaba ansaba added the gopls/workspace label Jul 14, 2022
@thediveo
Copy link

thediveo commented Jul 17, 2022

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

findleyr commented Jul 18, 2022

@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

thediveo commented Jul 18, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls/workspace gopls Tools
Projects
None yet
Development

No branches or pull requests

4 participants