Support "get type of the expression" functionality

[matklad]

It's very useful to be able to get the type of the expression at the cursor position. The way this feature should ideally work is that you place the cursor on the target expression, like 1 +<|> 2.foo(), then press "extend selection" several times until you select the the whole expression, and then invoke "show type".

Unfortunatelly, LSP does not have an API for this sort of functionality yet, so we need to hack it a bit.

I propose the following plan:

• define type_of_expression(&self, FileRange) -> Option<String> API on the Analysis
• implement textDocument/hover on top of it. Hover talks about positions, not ranges, so the implementation should first find an ast::Expr at the given offset (using find_node_at_offfset) and then invoke type_of_expression.
• Implement our own extension ra-lsp/typeOfExpression which sends a range instead of a single offset.

See this issue for the implementation tips.

[h-michael]

I try this, before #388.

[h-michael]

@matklad
I think type_of_infer needs Hir::Expr and that is discussed at #386.
Did I get that right?

• add Hir::Expr
• add type_of_expression to ra_analysis
• add textDocument/hober
• add ra-lsp/typeOfExpression that might be as textDocument/codeAction

[matklad]

@h-michael I am not sure: we already have Analysis::type_of which works with ranges, here:

https://github.com/rust-analyzer/rust-analyzer/blob/5a866a772c863ba7e3ec8bad353c1b6997a7a62a/crates/ra_analysis/src/lib.rs#L373-L375

So we only need to expose that to the LSP layer, by writing appropriate handlers in ra_lsp_server crate.

hir::Expr is required to make the implementation of Analysis::type_of more powerful, but it shouldn't affect the interface.

[h-michael]

@matklad
Now, ra_lsp_server#handle_hover shows Analysis#doc_text_for's results.
Might we merge Analysis#type_of's result with above, or replace with Analysis#type_of's result?

[matklad]

I think we should prefer to show docs over showing the type.

[h-michael]

I think we should prefer to show docs over showing the type.

What you said is that we show type by ra-lsp/typeOfExpression or textDocument/codeAction instead of textDocument/hober ?

[matklad]

No, I mean the logic should be as roughly follows:

fn handle_hover(position) {
    lf let Some(docs) = analysis.doc_text_for(position) {
        return docs
    }
    if let Some(type_of) = analysis.type_of(position) {
        return type
    }
}

[h-michael]

I see, thanks for explaining a detail!

[DJMcNab]

This should be handled in description_of, btw.

[h-michael]

This should be handled in description_of, btw.

I also think it is better.

[h-michael]

But I think if NavigationTarget#description were failed, type_of may be also failed.
I try to implement by handling in NavigationTarget#description for now.

[matklad]

Blocked on upstream: microsoft/language-server-protocol#377

[matklad]

Actually, there's no reason to wait for the upstream -- we can just impletent this extension on the server, emacs and vim folks will probably pick it up, and then we can poke upstream until this is documented. So, mentoring instructions:

• take a look at the https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/docs/dev/lsp-extensions.md#L1
• and https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/crates/rust-analyzer/src/lsp_ext.rs#L1
• add hoverRange server capability.
• change HoverParams to contain Position or Range. See lsp_ext::CodeAction for how to extend existing structures
• document the extension
• extend the implementation to support ranges: https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/crates/ide/src/lib.rs#L405-L414
• plumb this to LSP: https://github.com/matklad/rust-analyzer/blob/cabb679cbb7d94fba5bdbcfdb0dc66e9fdd47415/crates/rust-analyzer/src/handlers.rs#L858-L881

[alexfertel]

@matklad Can I take a jab at implementing this?

[matklad]

@alexfertel sure!

[lnicola]

@alexfertel it's yours.

[alexfertel]

Hey, guys, sorry to be this slow, I haven't had a lot of time and there's a lot of reading (both code and not code) to be done, so I can tackle this implementation.

I promise that I will eventually submit a PR, hopefully in the next few days.

[Veykril]

No rush, it takes time to get familiar with unknown codebases. If you got questions about things you don't understand or which seem unclear feel free to hit up the zulip channel.