Display the concrete type of a expression/item.

[Ciel-MC]

I always find myself adding let a = in front of lines to see what type things are, like when using serde and want to check what error the method returns, which is very inconvenient.

The hover now only shows Deserializer::Error, it would be nice to have a way to show the concrete type of the expression/item hovered/the cursor is on, something like (Vec<u8>, Packet) -> Result<(), SomeSerializeError>.

I know inlay hints are a thing, but they aren't displayed/not always desired everywhere. Plus inlays hints on (neo)vim isn't very cut out for this purpose yet either.

[Veykril]

You can select the thing you want to see the type of and then hover the selection to get the full type of that selected thing. This is a server extension thoug so your client needs to have support for it.

[Ciel-MC]

You can select the thing you want to see the type of and then hover the selection to get the full type of that selected thing. This is a server extension thoug so your client needs to have support for it.

Hmmm, neovim doesn't seem to have to implemented, ouch. Do you mind linking some resources to what one might need to start implementing it?

[Veykril]

I don't know anything about neovim, all i can point you to is the lsp extension from our side https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#hover-range

[Jacobfaib]

I'll second this feature request. This is something I sorely miss from e.g. clangd as it helps immensely when dealing with other peoples code. Obviously this feature is very LSP-server-implementation dependent (as they need to properly render the information) but from what I gather here rust-analyzer does not expose any information about this at all?

See for example what clangd produces when hovering over std::vector<int>::push_back() (as denoted by blue highlight):

vs rust-analyzer:

The latter tells me very little.

[ChayimFriedman2]

As said, we have a protocol extension for that. I don't know if Neovim implements it, and can understand if not. The only thing you can do is to try to push Microsoft to merge it into the protocol (microsoft/language-server-protocol#2027), although they seem to not really care.