x/tools/gopls: support showing all interfaces that a given type implements

[stamblerre]

Should this be part of the textDocument/implementation request or is this a separate feature? Perhaps we need to request clarification in the protocol.

[muirdm]

@stamblerre I've run into this a couple times. I come across a concrete method and run find-references on it, but get nothing back. I'm mildly confused until I figure the method might be used to satisfy an interface, but there is no way to find that interface easily to continue my code exploration.

Would you be opposed to making textDocument/implementation also work backwards from concrete type/method -> interface type/method for now?

We should also explore a proposal to add "implements" to the LSP spec, but it is sort of a unique problem to Go since most languages require you to explicitly declare when a type implements an interface, so going from concrete -> interface isn't hard for the user.

Personally, I don't really want another flavor of find-something-something to choose from as a user, but of course I could always just make my editor search both and combine results if I don't want to think about it.

[stamblerre]

Would you be opposed to making textDocument/implementation also work backwards from concrete type/method -> interface type/method for now?

Yes, I think it's time to give this a try. I think it's a reasonable solution. But I think we could also try having find references include these results.

[gopherbot]

Change https://golang.org/cl/219678 mentions this issue: internal/lsp/source: support inverse "implementations"

[inliquid]

Any progress?