x/tools/gopls: compiler errors disappearing and reappearing in unopened test files

[zikaeroh]

Please answer these questions before submitting your issue. Thanks!

What did you do?

I was working on one file in a project that fully compiles and runs. I can publish it if needed.

What did you expect to see?

No errors; the code compiles.

What did you see instead?

Randomly, I'd see that one of the files had a bunch of compiler errors. But, I'd go open the file and they'd disappear. Close the file, and they'd come back. I could modify another file in the package and they'd disappear and come back some time in the future. This happens reliably in this project.

LSP logs: https://gist.github.com/zikaeroh/89ddc6f1b444b756cc44195f607481ad

Screenshots of what VS Code is showing me in one file, versus moving to the file with the errors:

Build info

golang.org/x/tools/gopls master
    golang.org/x/tools/[email protected] h1:VVxELAabDbd0ccBLh29rD/dcK4BkwiQUTgNJrzUqezQ=
    github.com/BurntSushi/[email protected] h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
    github.com/sergi/[email protected] h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
    golang.org/x/[email protected] h1:KU7oHjnv3XNWfa5COkzUifxZmxp1TyI7ImMXqFxLwvQ=
    golang.org/x/[email protected] h1:vcxGaoTs7kV8m5Np9uUNQin4BrLOthgV7252N8V+FwY=
    golang.org/x/[email protected] h1:AFZdJUT7jJYXQEC29hYH/WZkoV7+KhwxQGmdZ19yYoY=
    golang.org/x/[email protected] h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
    honnef.co/go/[email protected] h1:sXmLre5bzIR6ypkjXCDI3jHPssRhc8KD/Ome589sc3U=
    mvdan.cc/xurls/[email protected] h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=

Go info

go version go1.14.1 linux/amd64

[stamblerre]

Thanks for the issue report and the log! Some quick observations:

• The test file in question is not open till the end of the log (only open for 1 version).
• It seems to alternate between diagnostics from analyses and diagnostics from the compiler.

From this information, my first guess is that this is an issue with diagnostics caching, since the file is not changing, but the diagnostics are seemingly changing and being resent. I'll see if I can come up with a regression test for this case.

A question for you: Were the diagnostics ever correct? Are the analysis diagnostics accurate or are they also outdated?

[zikaeroh]

I restarted gopls to get these logs; the original session's were 6MB and probably contain a lot of info. I can likely include that if you want.

Were the diagnostics ever correct?

I'm not sure which diagnostics you mean, sorry. Do you mean the "cannot use" ones? I don't think those were correct; the package builds and I can edit the file without trouble.

Are the analysis diagnostics accurate or are they also outdated?

Which diagnostics are the analysis ones? Most (if not all) of the warnings are from golangci-lint (as I don't run staticcheck live). I'll have to disable it to get a better view on things, since all of these tools display their diagnostics with the underlying tool's/analysis' names. I know that this project has a bunch of places without gofmt -s changes, which get auto-fixed on save, so I guess those are analysis diagnistics.

The repro is this repo on the selected branch, if you want to test this more easily: https://github.com/zikaeroh/sqlboiler/tree/with-gomod

[stamblerre]

Thanks for sharing the repro - I didn't realize it repro'd this easily. I should be able to make some progress off of the repro.

Edit: This does not reproduce with gopls/v0.3.4.

[zikaeroh]

Edit: This does not reproduce with gopls/v0.3.4.

I'm assuming that's a note to self, given I'm running at the current master build and not 0.3.4 (so probably something in between). 🙂

[stamblerre]

Yep 😄Sorry about that - just wanted to take notes as I investigate. I think I've isolated this to some weirdness with the new gofmt -s analyzers + diagnostics caching.

[gopherbot]

Change https://golang.org/cl/227299 mentions this issue: internal/lsp: handle unexpected compiler errors

[myitcv]

FWIW I'm also seeing instances of the "cannot use &(X literal) (value of type *X) as *X value in assignment" with -remote, against commit 9fc00b0.

@stamblerre - do you have enough information here or would you like further log files?

[stamblerre]

Can you try patching in https://golang.org/cl/227299 and seeing if that fixes the issue?

[gopherbot]

Change https://golang.org/cl/227354 mentions this issue: internal/lsp: make sure that gofmt -s analyses don't modify AST

[zikaeroh]

Fixed it for me, thank you!

[myitcv]

@stamblerre

Can you try patching in https://golang.org/cl/227299 and seeing if that fixes the issue?

I didn't have a repro in this case, so totally happy to go with you and @zikaeroh on this one. Will open a new issue if I spot this again.