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: ignore vendor directories when running diagnostics #38080

Closed
stamblerre opened this issue Mar 26, 2020 · 3 comments
Closed

x/tools/gopls: ignore vendor directories when running diagnostics #38080

stamblerre opened this issue Mar 26, 2020 · 3 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. NeedsFix The path to resolution is known, but the work has not been done. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@stamblerre
Copy link
Contributor

stamblerre commented Mar 26, 2020

See the end of microsoft/vscode-go#3110 for some discussion. Vendor directories populated after running go mod vendor overwhelm gopls when they create a large number of packages that we consider "part of the workspace".

We need to watch the vendor directory for file changes, but we shouldn't consider packages in vendor directories to be workspace packages, and therefore, we shouldn't offer any diagnostics for them. To me, this seems as simple as ignoring any packages whose directories are prefixed with vendor, but I imagine it's not that simple. @heschik: What do you think / does this approach sound reasonable?

@stamblerre stamblerre added this to the gopls/v0.4.0 milestone Mar 26, 2020
@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 Mar 26, 2020
@heschi
Copy link
Contributor

heschi commented Mar 26, 2020

In module mode, it's guaranteed to be module root + /vendor. In GOPATH mode they could be anywhere, and also the user might want to edit them, so it's not obvious to me that they shouldn't be workspace packages. But certainly we can start with module mode.

I think we've also discussed debouncing file change events, which would probably be relevant to the go mod vendor case?

@stamblerre
Copy link
Contributor Author

In module mode, it's guaranteed to be module root + /vendor. In GOPATH mode they could be anywhere, and also the user might want to edit them, so it's not obvious to me that they shouldn't be workspace packages. But certainly we can start with module mode.

Sounds reasonable. I'll work on this fix soon.

I think we've also discussed debouncing file change events, which would probably be relevant to the go mod vendor case?

In this case, I noticed that VS Code sends one batched didChangeWatchedFiles with all of the changes, so it's actually not a big deal for gopls to handle. The slow part really seemed to be all of the go list calls we start making to diagnose the workspace packages.

@stamblerre stamblerre self-assigned this Mar 26, 2020
@stamblerre stamblerre added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 26, 2020
@stamblerre stamblerre modified the milestones: gopls/v0.4.0, gopls/v0.5.0 Apr 2, 2020
@gopherbot
Copy link

Change https://golang.org/cl/237598 mentions this issue: internal/lsp/cache: vendored packages are not workspace packages

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. NeedsFix The path to resolution is known, but the work has not been done. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants