x/tools/gopls: Display struct methods

[MathiasHandle]

Is your feature request related to a problem? Please describe.

I have difficulties finding all available methods for given struct, hence this request.

Describe the solution you'd like

When on hover on struct I'd like to display all methods belonging to that struct.

This should work across files. As currently the outline view displays only types defined in currently opened file.

There are 2 solutions that come to my mind:

1) Display methods in hover docs (preferred solution)

• I've took this implementation from JetBrain's Goland IDE as I find it as a best solution

2) Sort methods in outline view

• If the first implementation wouldn't be possible, I think this could still make code navigation easier.

Currently the outline view can be sorted by
1.) position
2.) Name
3.) Category

But the methods aren't visually assigned to struct they belong to.

Additional context

These proposed changes don't make sense in this simple example, but in real project with a lot of types, methods, packages, etc.. it would make better & cleaner code navigation.

[hyangah]

We discussed this offline and agree that the option 1 is reasonable.

Relevant code location:

https://github.com/golang/tools/blob/3d474c89054e6c6094b99e57fe652ad6d45c2976/internal/lsp/source/hover.go#L246

For people who love more concise hover docs, I think this should be controlled by an option but I will leave @findleyr for the guide.

[gopherbot]

Change https://go.dev/cl/420714 mentions this issue: internal/lsp/source: add functions to struct hover output

[brianpursley]

/assign

[findleyr]

Thanks @brianpursley. I commented on your CL, but I think we should use the type-checker to compute the method set for us, rather than trying to resolve it ourselves (resolving a method set is a surprisingly difficult task!).

go/types has a function that does this: go/types.NewMethodSet. Here is an example: https://go.dev/play/p/7s8iE66SJjH

You can get the type by looking it up in types.Info.Types, and then pass it to NewMethodSet to compute a representation of its methods. This will work for more than just structs: any defined type may have methods. We probably don't want to do this for interface types though, as I think it will be redundant with the type definition.

Other questions to answer:

• do we want to show all methods (included those that are added via embedding), or just those that are directly defined (if just the latter, maybe we don't even need NewMethodSet and could just use the go/types.Named API.
• how do we want to qualify names in the type signature. Relative to the package defining the type, or relative to the current package being hovered? go/types.TypeString and go/types.ObjectString provide APIs for formatting types and objects with a custom qualifier
• how best do we present the methods visually? Do we want to include their receiver, or just show their name and function signature?