Implement textDocument/typeDefinition

[kjeremy]

From #197

@aochagavia :

Regarding type checking, we need to be able to:

Get the type of the expression under the cursor
List the available functions for the type (which means knowing which traits are implemented by it)

On the LSP front this would involve implementing textDocument/typeDefinition.

[DJMcNab]

We also need to handle type parameters properly (I.e. typeDefinition should jump to the function signature/impl <trait>)

[matklad]

@kjeremy note that "get type of the epxression" is actually required for signature info as well.

For something like

(foo)(1, 2, 3)

You need to figure out that (foo) expressin has a funciton type

[matklad]

We now have type_of in the analysis:

https://github.com/rust-analyzer/rust-analyzer/blob/4a3d6aa26a1c71dadc91f37f9d5f8662b51c138a/crates/ra_analysis/src/imp.rs#L492

Let's expose it on the LSP layer. To do this, one needs to add a handler function here:

https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/ra_lsp_server/src/main_loop/handlers.rs

and register it over here:

https://github.com/rust-analyzer/rust-analyzer/blob/4a3d6aa26a1c71dadc91f37f9d5f8662b51c138a/crates/ra_lsp_server/src/main_loop.rs#L277-L297

[h-michael]

I'll try it.

[h-michael]

type_of function needs FileRange, but TextDocumentPositionParams does not have range.
Is there function which build FileRange from params which TextDocumentPositionPrams has.

If there is not, I'd like to add that function.
Where should I add to that function?

[matklad]

Oh, wait, typeDefinition is not "show the type of selected expression", it is "like go to declaration, but instead go to the type of the declaraions". So, if you have let x = Foo::new(); x<|>, typeDefinition on the second x should focus the editor on the file where Foo is defined.

Looks like there's no built-in support for get type of the expression on the LSP at the moment, but it souldn't be too hard to add an extension for this. First, one needs to define TypeOfExpression request here:

https://github.com/rust-analyzer/rust-analyzer/blob/e2bc57e3c89e469eee772aa8e42df1d453fea922/crates/ra_lsp_server/src/req.rs#L28-L47

Params would be a text document id and a range, response would be a string

Then one should add & register handler as described above.

Then, for VS Code, in typescript, one should define a new ra-lsp command here:

https://github.com/rust-analyzer/rust-analyzer/blob/e2bc57e3c89e469eee772aa8e42df1d453fea922/editors/code/package.json#L78-L81

register it here:

https://github.com/rust-analyzer/rust-analyzer/blob/e2bc57e3c89e469eee772aa8e42df1d453fea922/editors/code/src/extension.ts#L46

and write the actual implementation here

https://github.com/rust-analyzer/rust-analyzer/tree/e2bc57e3c89e469eee772aa8e42df1d453fea922/editors/code/src/commands

The implemntation should work like the one for extend selection, and use VS Code API to show a message with type to the user.

[DJMcNab]

In Typescript, the type is shown on hover. Should we try and emulate that too/instead.

[matklad]

Good point! I think we should have both: hover doesn't allow selecting the expression, and it is useless for folks who don't use mouse :)

[h-michael]

Oh, wait, typeDefinition is not "show the type of selected expression", it is "like go to declaration,

I see that.

Looks like there's no built-in support for get type of the expression on the LSP at the moment, but it souldn't be too hard to add an extension for this. First, one needs to define TypeOfExpression request here:

I also think geting the type of expression might be implemented as hover for now.

[h-michael]

hover doesn't allow selecting the expression

LanguageClient-neovim handles textDocument/hover by mapped command and current cursor word.
We can use it without mouse.

[h-michael]

BTW, implementing showing type definition whether textDocument/hover or textDocument/codeAction, I want to know the way calling type_of function from textDocument/typeDefinition which does not have FileRange.
Because I think that implementing go to type definition need knowing current cursor expression type.