x/tools/gopls: internal error: go list gives conflicting information for package

[andig]

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

$ go version
go version go1.15.6 darwin/amd64

Does this issue reproduce with the latest release?

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/andig/Library/Caches/go-build"
GOENV="/Users/andig/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/andig/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/andig/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.6/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.6/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/andig/htdocs/evcc/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/73/89ycv7qn51j4kbm04jsz9b840000gn/T/go-build196148698=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Running vscode with gopls, refactoring and developing:

❯ gopls version
golang.org/x/tools/gopls v0.6.4
    golang.org/x/tools/gopls@v0.6.4 h1:PO8rURGmi+QEKZ3pk+ZXJh51EFTVTSXqxzoRzrGSTJM=

What did you expect to see?

gopls identifies errors during coding (missing return types etc). Once error is fixed in code, gopls error messages are removed.

What did you see instead?

Once gopls sees certain kinds of errors , they become "sticky" until VSCode is restarted, even when they are already fixed in the code. Here's an example:

Error loading workspace: internal error: go list gives conflicting information for package github.com/andig/evcc/charger [github.com/andig/evcc/charger.test]: packages.Load error

The general issue has existed for a longer time, it's not related to the latest gopls version.

gopls.txt.zip

[stamblerre]

Did you confirm that this error does not exist on the command-line (for example, by running go build or go list ./...)?

[stamblerre]

Also, if you have a case with which we could reproduce this issue, that would be ideal.

[andig]

Program builds and runs. The issue does not manifest itself only in this error. Instead, during coding, different error states pop up and don‘t resolve even if code is fixed. It feels as if gopls (or vscode) works on outdated cached state..

We could keep this issue open and I can supply more examples when I notice this. It does not manifest itself in the code base per se.

[stamblerre]

We could keep this issue open and I can supply more examples when I notice this. It does not manifest itself in the code base per se.

Sure. In this case, this error message is particularly strange and may be best fixed by a restart, but if you had a way of reproducing it we could look into it. If you run into other cases, please share the logs for them.

[kentquirk]

I can reproduce this:

I have a package called "books" that has no errors. I create a new file in that folder, and type "package boo", then pause. I wait a few seconds, then finish "package books". All of the other files in that folder are now showing 1 error; when you hover over the word package, it says "package books: expected boo".

I haven't been able to fix it except by restarting vscode.

I am attempting to refactor code by moving code into different packages, and moving code around between files, and this is a persistent problem that has recurred several times today.

$ go version
go version go1.15.6 darwin/amd64
$ gopls version
golang.org/x/tools/gopls v0.6.4
    golang.org/x/tools/gopls@v0.6.4 h1:PO8rURGmi+QEKZ3pk+ZXJh51EFTVTSXqxzoRzrGSTJM=

[andig]

Perfect. That‘s exactly what I notice and not specific to this error message. Fixed errors seemingly hang around in vscode/gopls.

[stamblerre]

Thanks for sharing this, @kentquirk. This actually sounds like an issue that will be resolved in Go 1.16. If you're willing to try out Go 1.16, please do so by following these instructions and then please share if you are still able to reproduce the issue.

[stamblerre]

Closing this as there has been no activity on this issue for over a month. Please open a new issue if you continue to encounter this problem with Go 1.16.