x/tools/gopls: typeDefinition: support more kinds of syntax

[adonovan]

The LSP typeDefinition query reports the location of the definition of a type. Currently, it requires a symbol, whose type it computes, and from which it then tries to pick the most salient named type. But there are lots of other expressions for which it could give useful information:

• any expression
• a struct field
• imported package names.

gopls should support more of these.

(Unfortunately the LSP provides no way to support the "describe type" feature of the late cmd/guru, which reported the type of the selected expression: TypeDefinition only returns a location, and Hover does not accept a selection. So there's no way to ask the type of just the "f(x)" portion of f(x).y. We should lobby for LSP to add a selection to Hover.)

[vikblom]

Hi, I'd be interested in helping out with this, although I am a bit fuzzy on what should be added.

As far as I know I only use typeDefinition as a goto/jump.

Playing around with gopls v0.16.0 it seems like struct fields (in definitions, assignment, and access) can be "jumped from". Is there a case I'm missing?

The same goes for an expression like

s.view.importsState.runProcessEnvFunc(ctx, s, fn)

where the snapshot, view and importState types can all be reached. Although the type of the function return, which is error, does not work, so perhaps that is a good place to start?

[findleyr]

@vikblom indeed, struct fields do work. I think that decreases the utility of this issue significantly; jumping to the type definition of call expressions can be achieved by jumping on the function name, since it traverses through the structure of simple expressions to find the "element" type.

Perhaps https://go.dev/issue/66557, which you've already identified, is a better place for a next contribution.