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: diagnostics are produced for packages beginning with underscore #39563

Closed
fhs opened this issue Jun 12, 2020 · 3 comments
Closed
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@fhs
Copy link
Contributor

fhs commented Jun 12, 2020

Please answer these questions before submitting your issue. Thanks!

What did you do?

  • Checkout yaegi:
$ cd /tmp
$ git clone git@github.com:containous/yaegi.git
...
$ cd yaegi/
$ git checkout v0.8.7
  • Add /tmp/yaegi to vscode workspace.
  • Open _test/a1.go, which produces 2709 diagnostics in the View > Problems window.
  • Close _test/a1.go and we still have 2709 diagnostics.

What did you expect to see?

The _test package should be ignored by gopls, as it's also ignored by go build ./....

What did you see instead?

Too many diagnostics for a package I don't care to see diagnostics on. The only way to remove the diagnostics seems to be to restart vscode.

While unwanted diagnostics might not seem like a big issue on vscode, where the user usually don't look at the Problems window, it's a larger issue for editors that don't support highlighting problems within the file buffer (e.g. acme-lsp). In those editors, the Problems window is the only way to see the diagnostics.

Build info

golang.org/x/tools/gopls 0.4.1
    golang.org/x/tools/gopls@v0.4.1 h1:0e3BPxGV4B3cd0zdMuccwW72SgmHp92lAjOyxX/ScAw=
    github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/mod@v0.2.0 h1:KU7oHjnv3XNWfa5COkzUifxZmxp1TyI7ImMXqFxLwvQ=
    golang.org/x/sync@v0.0.0-20190911185100-cd5d95a43a6e h1:vcxGaoTs7kV8m5Np9uUNQin4BrLOthgV7252N8V+FwY=
    golang.org/x/tools@v0.0.0-20200513154647-78b527d18275 h1:e7nYe9s94RHunFJ7b+mmPxiQMOKMVSqYASToWb1EcHs=
    golang.org/x/xerrors@v0.0.0-20191204190536-9bdfabe68543 h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
    honnef.co/go/tools@v0.0.1-2020.1.3 h1:sXmLre5bzIR6ypkjXCDI3jHPssRhc8KD/Ome589sc3U=
    mvdan.cc/xurls/v2@v2.1.0 h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=

Go info

go version go1.14.4 linux/amd64

@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 Jun 12, 2020
@gopherbot gopherbot added this to the Unreleased milestone Jun 12, 2020
@stamblerre
Copy link
Contributor

/cc @heschik because https://go-review.googlesource.com/c/tools/+/237597 is relevant here

@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.5.0 Jun 12, 2020
@heschi
Copy link
Contributor

heschi commented Jun 12, 2020

That CL is unrelated, since it was ignoring individual files that start with _, not whole directories. I reproduced and gopls is doing a many-file packages.Load, which is presumably the orphaned file handling kicking in because the workspace load correctly ignored _test.

Guess we need to duplicate go list's exclusion logic in orphanedFileScopes.

@gopherbot
Copy link

Change https://golang.org/cl/237638 mentions this issue: internal/lsp/cache: hide diagnostics for ignored dirs

@stamblerre stamblerre modified the milestones: gopls/v0.5.0, gopls/v0.4.2 Jun 18, 2020
@golang golang locked and limited conversation to collaborators Jun 18, 2021
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. 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