x/tools/gopls: add logging to detect instances of "cannot use A (value of type B) as B value"

[myitcv]

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

$ go version
go version devel +801cd7c84d Thu Apr 2 09:00:44 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200408132156-9ee5ef7a2c0d => github.com/myitcvforks/tools v0.0.0-20200408225201-7e808beafd9f
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20200408132156-9ee5ef7a2c0d => github.com/myitcvforks/tools/gopls v0.0.0-20200408225201-7e808beafd9f

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=""
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/.vim/plugged/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-build285741329=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This is a follow up to #38267 (comment).

I'm occasionally seeing instances of "cannot use A (value of type B) as B value" with -remote.

The most recent instance was after I change branches, (with all editor instances closed) at which point I saw:

...cannot use X (value of type context.Context) as context.Context...

What did you expect to see?

No such errors

What did you see instead?

The above errors.

I don't have any repro steps as yet, nor any details that are worth uploading to this issue. So instead opening this as a placeholder in case others start seeing issues and can provide more context.

---

cc @stamblerre @findleyr

FYI @leitzler

[stamblerre]

Thanks for the report. I could see this happening with -remote since we have multiple sessions sharing the cache - please let me know if you see this without -remote.

It's a cache invalidation issue where we end up type-checking a package with 2 different versions of one dependency (so somehow there are 2 "contexts" in this case). This is more likely to happen when you have a workspace structured like this:

package a imports package b and package c
package b imports package c

Please do add more detail and a log if you see it again. The sequence of file changes will help us understand what steps are needed to repro.

[myitcv]

please let me know if you see this without -remote.

As I mention above, I don't have any repro steps as yet. When I do I'll try with and without remote.

[myitcv]

Quick update: I'm seeing this semi-regularly now, although still not able to 100% repro.

The setup is roughly this:

• I'm working on a stack of changes in a branch, let's name them 1-10
• I start work (i.e. no gopls currently running) via git rebase -i to edit 8
• I do some work, add the changes and git rebase --continue
• I get a conflict during the rebase of 10, fix those changes, add and git rebase --continue
• I then go back to doing some work to edit 8

Now I'm in the bad state.

[findleyr]

Thanks very much for the details. Couple questions:

When you say 'no gopls currently running', you mean no session (i.e. forwarder), right? The daemon is running through all this?

How do you get out of the bad state? Do you restart your session? Do you have to kill the daemon?

[myitcv]

When you say 'no gopls currently running', you mean no session (i.e. forwarder), right?

No, I mean no remote. This was simply to indicate I'm starting from cold/fresh.

How do you get out of the bad state?

At the moment, quit all editor sessions and then killall gopls 😄

[atombender]

@stamblerre This smells like the same bug? I was happily editing some tests when, suddenly, another file (which is fine and wasn't being edited) in the same test package started showing as erroring. The error was on an import line:

	gogo_proto "github.com/gogo/protobuf/proto"
	^
	"github.com/gogo/protobuf/proto" imported but not used as gogo_proto

and also on this later line in the file:

func assertMutationFailure(h *harness.Harness, namespace string, muts []*proto.Mutation, errorType gogo_proto.Message) {
^
Message not declared by package proto

Log: gopls.log.gz. (Note: Had to scrub a lot of didOpen log messages as it logs the whole file contents, and this is a private repo.)

[atombender]

I can actually reproduce this error consistently, even across restarts. The file keeps getting the same error when editing other files. Let me know if there's anything I can do to get more diagnostics.

[findleyr]

@atombender, thank you for the report, and for attaching your logs. I'm not positive that your error is the same bug. How are you invoking gopls - which editor are you using and are which flags are you passing?

@stamblerre and I discussed, and think this is probably unrelated to using -remote based on reports of this bug surfacing without that flag. Unassigning for triage, though this is still a high priority bug.

[gopherbot]

Change https://golang.org/cl/232197 mentions this issue: internal/lsp/cache: add logic to detect golang/go#38403 and panic early

[atombender]

How are you invoking gopls - which editor are you using and are which flags are you passing?

VSCode. I just have -rpc.trace.

[stamblerre]

I have a reasonable guess about what the cause of the bug is, so hopefully the CL above will be able to address it.

@atombender: I do not think you're seeing the same issue, but unfortunately, I cannot make good sense of your log. Based on the changes you were making, it doesn't seem like gopls would've been recomputing the imports for your package. If you're still able to reproduce it - are there specific repro steps? What happens when you go into the test file - do the errors remain, or do they disappear? If you're able to produce a small repro case, that would be ideal for investigation.

[atombender]

@stamblerre Unfortunately, that was 5 days ago, and I'm not able to reproduce it right now, even if I reset my work back to that point in time. I will let you know if it happens again.

[myitcv]

@stamblerre I have a stack of CLs to rebase, but at that point I will try out this debugging CL and report back.

[atombender]

Had one of these happen again. As before, I am using GOFLAGS=-tags=integration, and the files here are not excluded.

I wasn't editing that file when the error popped up. It showed up as I was editing a different file, I believe harness.go in the same package.

gopls.log.gz

[atombender]

I have been able to isolate it in a repo that I'll share in a moment.

[atombender]

@stamblerre https://github.com/atombender/gopls-issue-38403

[gopherbot]

Change https://golang.org/cl/232817 mentions this issue: internal/lsp: fix caching issue with duplicate handles

[stamblerre]

Thank you very much for the repro. I think this is a different issue so I filed it separately: #38927.

[stamblerre]

We just got a new report of this on Slack: https://gophers.slack.com/files/U15F7NXAQ/F014ZH71LCW/gopls.log?origin_team=T029RQSE6&origin_channel=CJZH85XCZ.

[niaow]

Currently I have this occurring in 2 packages.

One of the instances is a direct assignment of a concrete stdlib type on these 2 lines:
https://github.com/pilosa/pilosa/blob/9dc1775b93464f78acc8573cfad2f405b1175fb5/server/tlsconfig.go#L142-L143

cannot use certPool (variable of type *x509.CertPool) as *x509.CertPool value in assignment
cannot use certPool (variable of type *x509.CertPool) as *x509.CertPool value in assignment

In another (not public) package, I have an issue with *grpc.ClientConn being passed into a function accepting grpc.ClientConnInterface (which appears to be caused by a type check error on an interface method argument):

cannot use conn (variable of type *grpc.ClientConn) as grpc.ClientConnInterface value in argument to pb.NewPilosaClient: wrong type for method Invoke

[stamblerre]

This issue has popped up now and again, but it seems to be less prevalent these days.
For v1.0, I would like to resurrect and merge https://go-review.googlesource.com/c/tools/+/232197.

[stamblerre]

@heschik's rewrite of the cache has likely resolved this issue, especially since no one has seen it in months. Closing.