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: don't show analysis for std and 3rd-party packages #45607

Open
ShoshinNikita opened this issue Apr 17, 2021 · 9 comments
Open
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Tools This label describes issues relating to any tools in the x/tools repository.

Comments

@ShoshinNikita
Copy link

ShoshinNikita commented Apr 17, 2021

Warning in /src/os/exec_unix.go:

Warning in github.com/gorilla/mux@v1.8.0/mux.go:

I think these warnings are not useful, but just distracting. It makes sense to run analyzers only for workspace packages

@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 Apr 17, 2021
@gopherbot gopherbot added this to the Unreleased milestone Apr 17, 2021
@findleyr findleyr added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Apr 19, 2021
@findleyr
Copy link
Contributor

findleyr commented Apr 19, 2021

I'm not sure there's a clear answer here, though I agree that in the example above I wouldn't want to see analysis for gorilla/mux.
Perhaps we should disable analysis for anything in the mod cache.

I think this becomes more clear-cut once multi-module workspaces are the norm. At that point we'll know which modules the user is intending to work on.

CC @stamblerre @heschi

@findleyr findleyr modified the milestones: Unreleased, gopls/unplanned Apr 19, 2021
@nezorflame
Copy link

nezorflame commented Apr 19, 2021

Maybe make it optional through the gopls setting?

@findleyr
Copy link
Contributor

findleyr commented Apr 19, 2021

Maybe make it optional through the gopls setting?

We can consider that, but we'd need evidence that two users, when working on the same exact workspace, might reasonably want different behavior. I.e., that such configuration is not just papering over gopls' inability to determine the user's intent with respect to a given package.

In the past we've used configuration when we can't just Do The Right Thing, resulting in configuration bloat and suboptimal behavior in the common zero-config case (I've been guilty of this).

In this case, my sense is that users only want to see lint errors when they're actionable. A lint error in a read-only module is not actionable.

@nezorflame
Copy link

nezorflame commented Apr 19, 2021

True, but we also have:

  • /vendor
  • local replace

Both of these are usually RW, thus actionable (maybe not every time and not in the case of /vendor, but it's possible).

@findleyr
Copy link
Contributor

findleyr commented Apr 20, 2021

Indeed, though I would argue we also shouldn't run analyzers for vendored packages.

To be more precise, though, we should differentiate between running an analyzer and showing the diagnostics. In some cases we may want to run analyzers on all dependencies in order to compute facts.

Perhaps the rule should be "only show analysis diagnostics for workspace packages and locally replaced packages".

@ShoshinNikita
Copy link
Author

ShoshinNikita commented Apr 20, 2021

Should I change the title to x/tools/gopls: don't show the diagnostics for std and 3rd-party packages?

@findleyr
Copy link
Contributor

findleyr commented Apr 20, 2021

If that would satisfy your original request, then yes :)

I've updated the title with a slight variation of that.

@findleyr findleyr changed the title x/tools/gopls: don't run analyzers for std and 3rd-party packages x/tools/gopls: don't show analysis for std and 3rd-party packages Apr 20, 2021
@findleyr
Copy link
Contributor

findleyr commented Apr 20, 2021

We chatted about this request in a meeting today, and some team members like seeing all diagnostics, even if they aren't actionable. I guess, per my criteria above, this means it probably should be a configuration gated feature (something like diagnoseDependencies).

Given that the current state is preferable for some users and mildly annoying for others, this is unlikely to be prioritized soon.

@findleyr
Copy link
Contributor

findleyr commented Apr 21, 2021

See also golang/vscode-go#1275. Perhaps the setting should be more fine grained: something like
showDiagnostics: openPackages | workspace | all

Where openPackages only shows diagnostics for packages that have open files, workspace shows diagnostics for all workspace packages (+local replaces), and all shows all diagnostics (or rather all workspace + open files in dependencies, like we do now).

Frankly there's a lot of overlap with a more general request we've had to limit the scope of certain features to open packages only, for large monorepos. @heschi has been thinking about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. 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