x/tools/gopls: find references should link concrete methods to interface methods

[muirdm]

For example:

type fooer interface {
  foo()
}

type impl struct{}
func (impl) foo() {}

func _() {
  var f fooer = impl{}
  f.foo()
}

Currently if you find-references on the "foo" struct method, you don't get anything. It would be useful to return the interface method "fooer.foo". Otherwise, there is no way to find how the concrete "foo" method is used. (It would still be a two step process: first jump to the declaration of fooer.foo, then run find references again to see where it is used).

The same logic doesn't apply to the "impl" struct itself since it will actually be referenced somewhere when it is constructed.

Another idea would be to overload the find-implementations to work in reverse as well. In other words, if you run find-implementations on a concrete type or method, it would show you the interface types/methods that are implemented.

[gopherbot]

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

[muirdm]

I've realized that making find-references work this way has the disadvantage of needing to search all packages, not just transitive dependents.

Overloading find-implementations is better in certain ways but probably too confusing/undiscoverable since no one will expect it to work backwards as well.

Do you have any thoughts @stamblerre?

[stamblerre]

We do have an issue tracking the reverse of implementations, which I agree is a better fit here. Maybe it's something we could do through a custom gopls-only textDocument/implements method that we could then propose to the LSP folks as an addition to the protocol? It seems like they like to have a reference implementation before adding a feature, so it would basically act as proof to them that this is useful.

[muirdm]

Sounds good. Closing as dupe of #35550

[stamblerre]

Reopening because of the discussion on microsoft/vscode-go#3140. Not sure if this is worth implementing, but it might be nice to reconsider in light of recent changes to gopls.