x/tools/gopls: go list error opening Go source tree

[myitcv]

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

$ go version
go version devel +20bf6a495e Tue Nov 26 12:03:08 2019 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20191113223546-95cb2a1a7eae => github.com/myitcvforks/tools v0.0.0-20191119111301-0222b4b716c6
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20191115202509-3a792d9c32b2 => github.com/myitcvforks/tools/gopls v0.0.0-20191119111301-0222b4b716c6

Note that github.com/myitcvforks/tools v0.0.0-20191119111301-0222b4b716c6 and github.com/myitcvforks/tools/gopls v0.0.0-20191119111301-0222b4b716c6 correspond to the x/tools 95cb2a1 with 80313e1 cherry picked on top. Reason being, we can't move beyond 95cb2a1 because otherwise we start tripping over the mistmatched versions problem described in #35114

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=""
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-build345551721=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Opened Vim + govim in the root of a clone of the Go source tree:

cd $(mktemp -d)
git clone https://github.com/golang/go
cd go
git checkout 20bf6a495eabad79b7b275d46fc3e11c620b8212
vi src/go/format/format.go

Got the following error message from gopls:

go list gives conflicting information for package internal/bytealg

What did you expect to see?

No error

What did you see instead?

As above.

gopls log as follows: fail.log

---

cc @stamblerre

[stamblerre]

I'm not able to reproduce this on master. Is this still an issue for you?

[heschi]

I tried again and hit #36587...

[heschi]

OK that was a me problem. Works for me. @myitcv, wanna take another look?

[myitcv]

I'm still seeing an error being logged as of 473961e:

LogMessage callback: &protocol.LogMessageParams{Type:1, Message:"2020/01/16 12:22:15 diagnose: no workspace packages: internal error: go list gives conflicting information for package runtime/internal/sys\n\tdirectory = 0xa8b110"}

[stamblerre]

Could that error be related to your Go installation? Does running go list -e -json -compiled -deps -test ./... in your ~/go/src folder produce a similar error?

[heschi]

This might be https://golang.org/issue/36188. Are you absolutely sure that gopls is using the go binary that matches the GOROOT you're opening?

[myitcv]

@stamblerre

Could that error be related to your Go installation? Does running go list -e -json -compiled -deps -test ./... in your ~/go/src folder produce a similar error?

Note I'm loading this file from the root of GOROOT, not src. For completeness, I don't see an such error when running that command:

go list -e -json -compiled -deps -test ./... 2>&1 | grep conflicting

gives not output.

@heschik

This might be https://golang.org/issue/36188.

Possibly.

Are you absolutely sure that gopls is using the go binary that matches the GOROOT you're opening?

100% sure. It's even logged as such.

[myitcv]

Note

• this message is only logged (hence I'm not aware of there being any user impact, given my limited test)
• the workaround here is to have $GOROOT/src as the workspace root, then I don't see this error at all

As a result I don't think this is a v0.3.0 blocker.

[stamblerre]

Note I'm loading this file from the root of GOROOT, not src.

I think that would be the problem. The go.mod file for is in go/src, so your workspace root will need to be go/src.

[myitcv]

The go.mod file for is in go/src, so your workspace root will need to be go/src.

Oh wow. Quite honestly I hadn't even spotted there was a go.mod there in src/

Perhaps a point worth highlighting to folks who work on the Go source tree and use gopls?

Either way, there is no bug per say here so I'll close this. Thanks for your responses and sorry for the noise.