@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.

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.

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

Any progress?

The above CL has been merged at master, but it is not part of the gopls/v0.3.3 release.

I use @master. Does it work only with interfaces/types located within same module? I don't see this feature working:

Yes, it only works on packages in your module and their transitive dependencies.

So there is no chance to see if we implement smth like fmt.Stringer, or io.Reader? Do you think it's okay to have such limited fuctionality?

Still, it doesn't work:

Are you sure you have the changes in your running gopls? Your example works for me, and fmt.Stringer/io.Reader also work.

Well, I update from master every day, so I suppose this was merged few hours ago? Let me check. Is there any chance, for instance, if I ask to find implementations navigating at Stringer in fmt package, that it will also find that it's implemented by some of my project's types?

Yes, find-implementations on fmt.Stringer should list a ton of things including any types in your workspace that implement fmt.Stringer.

Nice, finally it looks like something usable and helpful. Like it was with bingo > than a year ago :P

So does it work for you now? What was the problem?

When I open this project: https://github.com/benthosdev/benthos-plugin-example
and navigate to https://pkg.go.dev/github.com/Jeffail/benthos/v3/lib/types?tab=doc#Output

It shows that there is no local type implementing it:

However this type implements it:
https://github.com/benthosdev/benthos-plugin-example/blob/master/output/blue_stdout.go#L35

To be honest before that I saw just one single time that feature worked (but this particular type was missing as well in list of implementations of types.Output, so I was going to file that particular issue), but after several restarts I never seen this been working again, just "no implementaions" message.

I can reproduce it not working when you run find-implementations on the declaration of the Output type. But, it works when you run find-implementations on types.Output within blue_stdout.go, and running find-implementations on the declaration of BlueStdout also works (i.e. it lists the "Output" interface). Is that consistent with what you see, or does it not work at all for you?

Yes, right now it's same.

The issue is the github.com/Jeffail/benthos/v3/lib/types dependency is loaded in ParseExported mode when github.com/benthosdev/benthos-plugin-example/output is loaded, but when you run find-implementations from github.com/Jeffail/benthos/v3/lib/types/interface.go it uses the ParseFull version, so the named types in the interface no longer match.

@stamblerre I guess the solution is to re-type check a package's dependents when it transitions from ParseExported to ParseFull? In other words if you directly open a file that was previously parsed in ParseExported, you need to invalidate type data of any dependent packages so they properly depend on the ParseFull version.

Actually I don't open it directly, I just Ctrl-Click on types.Output, and that's it. Another question is that I don't see unexported interfaces or implementations. This forces me to use exported things most of the time, otherwise how do I know there is something else if tool doesn't show it? Goland shows both exported and unexported, and this makes it very useful.

gopls shows unexported interfaces and implementations. Do you have steps to reproduce them not showing up?

For example, mentioned above BlueStdout implements this interface: https://github.com/Jeffail/benthos/blob/v3.10.0/lib/broker/fan_in.go#L79
It's shown in Goland but missing with gopls.

That is related to the other issue. The broker package is loaded in ParseExported mode which means the function bodies and un-exported objects are elided. That type is defined in the function body (and is unexported), so gopls can't find it.

Is this gonna be fixed?

Fixing the first issue of finding implementations starting from a non-workspace dependency seems relatively straight forward, but fixing the second issue will take more consideration. gopls loads non-workspace dependencies in export-only mode to reduce memory usage, which is a concern for many users.

I understand it's not trivial. Would be nice to have it anyways, thank you.

I've reached the same problem. But another maybe unrelated puzzle: why ubuntu(in a virtual machine) vscode can successfully find all references even without gopls? I compared them side by side and cannot figure out why... But the same time, ubuntu vscode seems missing a lot of syntax check.

Ok, I got what i am missing. The references result turned normal after I moved the project into $GOPATH/src. Noticed in ubuntu, the project "gocaml" has a copy under $GOPATH/src. When I use "Find All References" inside other copy, it will show result in $GOPATH copy. The ubuntu pic shows the "references" followed by relative path showing the reference is outside of project path.
Sorry, newbie to Go world. A lot "weired" to learn to make sense. The "sense" is for old go project without go.mod, maybe move into $GOPATH/src is the right way to make everything work.

I think this issue falls under the broader category of figuring out how to better handle the full vs exported ASTs. This needs to be resolved in the context of running analyses correctly too, but I don't think it will happen until after gopls/v1.0.0. We can perhaps continue the conversation on #38278. Closing this as a result.