new feature: describe (type of) selected expression

[adonovan]

When and reading and analyzing code, aside from navigating the reference graph, the most common need I encounter is to understand what the type is of a given expression. The expression needn't be a name; it could be a subexpression of a larger expression; and it could be either a type or a term.

In the Guru tool (an early "editor-agnostic code oracle" like an LSP server, but specific to Go), one could select any subexpression and learn immediately:

• what it is (e.g. a call to a built-in function; a map index expression; etc)
• where it is defined, if it is an identifier (overlapping functionality with "go to definition")
• what is the underlying type of the selected expression, whether a term or type. In Go, this determines its representation and what operations are available.
• the size and alignment of the type, in bytes. This is useful during performance optimization.
• the set of fields and methods, expressed compactly one per line, with "inheritance" and embedding flattened out. This feature overlaps with completion, but completion is triggered by edits, whereas this information is useful during reading too.

You can see a short GIF animation of the feature here: http://golang.org/s/using-guru#heading=h.re7ifmz33xbj

LSP's existing operations don't seem to cover this set of features. The textDocument/hover request provides only a point in the code, not a selection, so it cannot identify a particular subexpression of interest. The textDocument/typeDefinition request also provides only a point, only works on named entities, and only traverses the type one step at a time, rather than reporting information about the flattened type and all its computed fields and methods.

Might it be worth adding an operation to the protocol that answers the question "what does this selection mean"?

[rwols]

Would #377 solve this?

[adonovan]

Would #377 solve this?

Definitely a step in the right direction, though the feature I described would show more detail than seems appropriate for
a hover text, such as links to each field and method. Many editors have persistent tree widget panes that would be a good way to present some of this information.

[dbaeumer]

We could reuse parts if he InlayHint which does exactly this but only for specific locations.