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

[stamblerre]

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]

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]

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.

[gopherbot]

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