x/tools/gopls: implementations fails on internal/lsp/source

[stamblerre]

Going to the implementation of a function in an interface in internal/lsp/source/view.go always fails.

[stamblerre]

@ridersofrohan investigated this issue, and it comes down to the different types.Objects having pointers to different types.Packages. This is a result of the way that we type-check dependencies. In this case, what happens is:

• The request originates in internal/lsp/source/view.go, which is type-checked in source.ParseFull mode (since it is an open file).
• The implementation is internal/lsp/cache, which depends on internal/lsp/source. This package is also in the workspace, which means that it has also been type-checked in full mode. All packages check their dependencies in exported mode. internal/lsp/source is a dependency of this package, so it has been checked in source.ParseExported mode. As a result we end up in a situation where we are comparing 2 different types.Packages.

I'm not sure what the best approach is here. We could probably check if the identifier's package is a dependency of the package being investigated and switch the package being compared?

[gopherbot]

Change https://golang.org/cl/209759 mentions this issue: internal/lsp: always ParseFull in-workspace dependencies

[muirdm]

This still happens for me sometimes. After restarting gopls find-implementations always works, but then later I come back and find-implementations stops working. I would guess the workspace package list is getting out of sync or breaking in some way, but I haven't tracked it down yet.