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

Open
stamblerre opened this issue Mar 26, 2020 · 2 comments
Open

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

stamblerre opened this issue Mar 26, 2020 · 2 comments
Assignees
Milestone

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?

@heschik

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

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 added the NeedsFix label Mar 26, 2020
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
You can’t perform that action at this time.