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: no diagnostics received for initially empty files (sometimes) #39646

Open
myitcv opened this issue Jun 17, 2020 · 5 comments
Open

x/tools/gopls: no diagnostics received for initially empty files (sometimes) #39646

myitcv opened this issue Jun 17, 2020 · 5 comments

Comments

@myitcv
Copy link
Member

@myitcv myitcv commented Jun 17, 2020

What version of Go are you using (go version)?

$ go version
go version devel +d286e61b67 Mon Jun 15 23:29:23 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200617042924-7f3f4b10a808
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20200617042924-7f3f4b10a808

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build538522998=/tmp/go-build -gno-record-gcc-switches"

What did you do?

govim has a test that verifies we receive expected diagnostics in the case where files are initially empty on disk, but subsequently get populated with content in the editor.

https://github.com/govim/govim/blob/e2a1802131f331832d667736aa27f023636f0c3a/cmd/govim/testdata/scenario_default/quickfix_empty_files.txt

Recently (apologies, I can't be any more specific than saying "in the last 2-3 weeks) we have started to see, and continue to see, a small number of flakes in this test.

In a normal run of this test we expect a set of diagnostics; when we see these flakes, we don't see any diagnostics.

Here is a gopls log file from a passing test run. Notice the DidChange notifications, as well as the PublishDiagnostics notifications: gopls.log

And here is the gopls log from a failing test run. Notice the DidChange notifications, but no PublishDiagnostics notifications: gopls.log

What did you expect to see?

A consistently passing test.

What did you see instead?

Flakes as described above.


cc @stamblerre @findleyr

FYI @leitzler

@myitcv
Copy link
Member Author

@myitcv myitcv commented Jun 25, 2020

FYI we're still seeing ~1 failure per day (in a build matrix of 12 entries) in the govim gopls@master build runs.

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jun 25, 2020

Thanks for the report! I am going to convert this into a gopls regression test and see if I can reproduce the issue.

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 26, 2020

Change https://golang.org/cl/240063 mentions this issue: internal/lsp: add a new regtest to reproduce golang/go#39646

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jun 26, 2020

I tried to reproduce the test as carefully as possible in my CL, but I haven't been able to trigger the failure. The issue is that the new files are getting treated like command-line-arguments packages, which should only happen when they are empty. I wonder if we will see similar flakes on the builders.

In the logs, I see command-line-arguments in the packages.Load at snapshot 3, which is the point at which p/p.go should be in a good state. I don't see any packages.Load results for snapshot 1, which is when you might expect a command-line-arguments result. One more thing to try would be adding an analogous go/packages test.

gopherbot pushed a commit to golang/tools that referenced this issue Jun 26, 2020
Change-Id: I51d8c66a83ecae1c8fc1f39c0e90a03a732c263b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/240063
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link

@gopherbot gopherbot commented Jun 26, 2020

Change https://golang.org/cl/240098 mentions this issue: internal/lsp: reproduce and fix golang/go#39646

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.