x/tools/gopls: race conditions result in confusing error message

[stamblerre]

Forked from microsoft/vscode-go#2759, as well as several messages on Slack.

This is a fairly unreproducible bug, but it seems that we have a race condition wherein a package may be type-checked with 2 versions of the same dependency. This seems to happen more frequently with packages with test variants. It results in error messages that read something like "type X cannot be used as type X in ...".

[gopherbot]

Change https://golang.org/cl/196537 mentions this issue: internal/lsp: add handling to make sure we never re-check an import

[stamblerre]

After investigating yesterday, the issue here seems to be that, with CL 186839, the deletion of an item from a map doesn't necessarily cause it to be garbage collected, so we may end up re-using an old cache entry when we wanted to force the type checker to recompute the entry. This will be fixed when we improve our cache invalidation strategy.

[atombender]

I'm getting something that seems to be a race condition. Could this be the same cause?

While editing code, I'll suddenly get nonsensical errors such as:

switch intent.Status {
  case stripe.PaymentIntentStatusSucceeded:
^ cannot compare stripe.PaymentIntentStatusSucceeded == intent.Status (mismatched types stripe-go.PaymentIntentStatus and stripe-go.PaymentIntentStatus)

...which indicates that it has two sets of type information for the same imported package. The imported package has not been updated, so I don't know why gopls would keep two sets.

The problem manifests as type errors (types not assignable, comparable, ertc.) and import errors.

gopls output here.

I'd be happy to report as separate issue.

Running 5eefd052ad727afc5e2e7b034c752b9d3d902b3b.

[myitcv]

Also seeing this within govim using gopls and x/tools a8d5d34

[gopherbot]

Change https://golang.org/cl/198317 mentions this issue: internal/lsp: use dependencies in cache keys

[stamblerre]

This error should be resolved as of the above CL.