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: suddenly stops working #38878

Open
atombender opened this issue May 5, 2020 · 6 comments
Open

x/tools/gopls: suddenly stops working #38878

atombender opened this issue May 5, 2020 · 6 comments
Labels
Milestone

Comments

@atombender
Copy link

@atombender atombender commented May 5, 2020

Description

Edited code in a single file. Gopls suddenly stopped reporting any errors. I could not get gopls to function again, and had to reload. Unfortunately, I could not reproduce the problem even when I went through the same editing steps that I remembered.

gopls.log. Note: Scrubbed of textDocument/didOpen notifications, as this is a private repo.

Build info

golang.org/x/tools/gopls master
    golang.org/x/tools/gopls@v0.0.0-20200501005904-d351ea090f9b h1:CAqIXUMd9mH3t2O1DRj2IWu0Zh75A4fWPA+YjJOmXdE=
    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-20200430221153-f26c0dd9827d h1:8emZwJTManptbFnp36i5fbhO/1vUs3rfnh5e3Th8HEQ=
    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 darwin/amd64

@gopherbot gopherbot added this to the Unreleased milestone May 5, 2020
@gopherbot
Copy link

@gopherbot gopherbot commented May 5, 2020

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.5.0 May 5, 2020
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 5, 2020

From what I can tell in your log, it looks like you switched branches, which caused gopls to reload a lot of packages by their package path. My guess is that the files in the github.com/sanity-io/gradient/pkg/security test package did not exist on the original branch, and they were treated like file creations, resulting in #38423. See the error message:

 [Error - 11:36:31 AM] 2020/05/05 11:36:31
	message="failed to load workspace packages, skipping diagnostics"
	error=github.com/sanity-io/gradient/pkg/security [github.com/sanity-io/gradient/pkg/security.test] has no metadata
	snapshot=241
	directory=file:///Users/alex/Projects/Sanity/gradient

gopls then appeared to be stuck because no new diagnostics were not being propagated.

@atombender
Copy link
Author

@atombender atombender commented May 5, 2020

Ah, that's possible. I wasn't switching branches, though; I was rebasing, which I guess can trigger the same problem.

@gopherbot
Copy link

@gopherbot gopherbot commented May 13, 2020

Change https://golang.org/cl/233657 mentions this issue: internal/lsp: add regtest for golang/go#38878

@gopherbot
Copy link

@gopherbot gopherbot commented May 28, 2020

Change https://golang.org/cl/235377 mentions this issue: internal/lsp: regtests for removing files outside the editor

@gopherbot
Copy link

@gopherbot gopherbot commented May 28, 2020

Change https://golang.org/cl/235581 mentions this issue: internal/lsp/regtest: add a test that reproduces golang/go#38878

gopherbot pushed a commit to golang/tools that referenced this issue May 29, 2020
When a file with errors is removed outside the editor, sometimes its
errors are cleared by the editor and sometimes they are not. If the file
is still open in the editor gopls does not clear the errors, taking the
editor's version as the truth. Otherwise the errors are cleared.
(This behavior depends on the editor sending gopls a notification that
the workspace changed.)

There seems to be no good way yet to test that gopls takes no action after
receiving the didChangeWatchedFiles notification.

Updates golang/go#38878

Change-Id: Ie418dd786d4c5f827cf0665a31f0f9913f7cfdc0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/235377
Run-TryBot: Peter Weinberger <pjw@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopherbot pushed a commit to golang/tools that referenced this issue Jun 1, 2020
This test partially reproduces some strange behavior with creating
new tests files. In particular, it creates a new x test in a package
that already has a test variant and adds content with a missing import.

In the test, the import is never added. However, in my own experience
debugging this in VS Code, I see the import get added but the diagnostic
never get removed. One thing at a time though...

Updates golang/go#39315

Change-Id: I724a145688b915d04abd1f21efc6f9a7506be043
Reviewed-on: https://go-review.googlesource.com/c/tools/+/235581
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
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.