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.

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

/assign

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?

Thanks @findleyr . I had some "issues" with my PR, but will work through them and have a better one soon 😅

Thanks for the advice too, I am new to the go/tools codebase, so it will be helpful to get my bearings and much appreciated.

I'll consider your points and see what can be done for each of them.

Regarding appearance, I was thinking to include the receiver, in case you want to know whether it is MyStruct or *MyStruct

For what its worth, Goland does it like this:

type MyStruct struct {
    Value1 int
    Value2 int
}
Methods on (*MyStruct):  Add(x int) int
                         Multiply() int
Methods on (MyStruct):  subtract(x int) int

My first thought was to just include the whole signature, but I don't feel too strongly in either direction though.

I'll un-abandon my PR and mark it WIP until I can get it to a better place.

Cool! This is a great place to contribute as the change is mostly isolated to hover.go (though our hover handling is a bit hard to follow).

Something like what you propose looks good to me. IIRC if we use go/types.TypeString or go/types.ObjectString, we will format the receiver (func (*MyStruct) Add(x int) int), which we probably don't want. So we may need to do a bit of massaging to get it into that form.

Another thought: it would be nice to link to the method locations using file:// links. Does not need to be done in the first pass though.
microsoft/vscode#8223 (comment)

I dont see this feature in action.
gopls is configured in VSCode as language server.

Am i missing something? @MathiasHandle

@ashu12318 This is in gopls/v0.10.0 milestone and gopls v0.10.0 isn't yet released.
You can try by installing a dev version (warning: once you install a dev version, vscode go extension's auto update logic won't kick in any more).

git clone https://go.googlesource.com/tools
cd tools/gopls
go install

@brianpursley Thanks for your working. BTW, I'd like to know why the hover does not show all methods (included those that are added via embedding). I think it will helpful to know the all available methods.

Hmm, we could do that. I think we were being conservative about the amount of screen space used by hover. But now that I reconsider the question, I agree that showing all methods would be better. (I feel like I may have been the one to suggest concrete methods only, in which case it is my bad).

Opened #61634.