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

Comments

@stamblerre
Copy link
Contributor

@stamblerre 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?

@heschi
Copy link
Contributor

@heschi 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

@stamblerre stamblerre 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.

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 modified the milestones: gopls/v0.4.0, gopls/v0.5.0 Apr 2, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented Jun 11, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants