Support for rust-analyzer.inlayHints.typeHints and rust-analyzer.inlayHints.parameterHints

[typoon]

Hello,

With the added support for decorators on NeoVim is it possible to add support for inlay typeHints? Like the screenshot below, where we have chainingHints (already implemented) and then in the last line we have the typeHints (for vars a and b)

Thanks!

[steelx]

even a variable type hint would be super helpful :)

[weirongxu]

Extend nvim_buf_set_extmark to also set decorations. Decorations are visual properties added upon an extmark. Currently the supported decorations are:

virtual text added at the EOL of the extmark.
highlight the byte extent of the extmark.

neovim/neovim#11745 (comment)

As bfredl said, the current nvim_buf_set_extmark API only supports virtual text and highlight, maybe nvim is currently focusing on related features of treesitter

[al-jshen]

Type hints in the middle of the line might be a little confusing (what did you type, what is a type hint) or distracting depending on your color scheme. I don't know if the hints would be treated as normal text (how would that work?) but if not, then there might also be unexpected behaviour when you try to move around. I think what is shown in this picture here might be more useful. The type hints just look like regular chaining hints, and appear at the end of the line. This is https://github.com/nvim-lua/lsp_extensions.nvim with nvim-lsp on neovim 0.5.

[fannheyward]

@al-jshen ChainingHint is already supported.

[typoon]

@al-jshen Type hints at the end of the line do not seem like a good idea. In the example you gave, there are two variables and a single type hint. The vars could have different types in certain situations, then having to look at the vars and at the end of the line to do the matching makes it harder. Also, if the line is closer to 80 chars (or 99 in rust's case) you have to deal with li e breaks and thing may get messy. Having a color for the type hints that is different from the color of types should be enough. Many editors do it like that and nobody gets confused.

[al-jshen]

Chaining hints are only supported for the middle of the chains though, not on the last line with the ;. There are also no hints for assignments like let x = 5;

Yes, I suppose that separate type hints might be useful. I was only thinking of this case where you have two values interacting directly, and they'd have to be the same type anyways. I haven't used any other editors so I don't know what it's like. I guess I'll just have to see when (if?) this is eventually implemented. :)

[oblitum]

This decoration API doesn't seem to bring anything new in the sense of neovim/neovim#9496 and it was noticed long time ago (#256 (comment)).

[fannheyward]

rust-analyzer.inlayHints.typeHints is supported in v0.18.0.

[the10thWiz]

I would like to see future support for this feature to allow multiple type hints per line. I'm willing to build this myself, but I'm interested to hear some other opinions on the actual implementation.

A simple situation where the current implementation fails: let (a, b) = (0, ""); This shows &str, since rust-analyser reports hints for both, and each one added overwrites previous hints.

A simple solution might be to create an expanding hint, so let (a, b) = (o, ""); would show i32 &str (with appropriate seperators). Another future improvement might be a CocCommand to retrieve them for use in other situations.

[oblitum]

@the10thWiz a proper implementation would need neovim/neovim#9496 (comment), but as there's no such thing yet, a current possible implementation could involve usage of conceal, as it's often employed in LaTeX, or Haskell. I'm not sure whether conceal can actually be used at all on this case though.

[the10thWiz]

My suggested (temporary) implementation is to simply add more virtual text to the end of the line. This would likely be assisted by adding multiple separators, one for each type of hint. This would hopefully make it easier to tell what each hint is for.

I have actually already implemented my temporary solution, which looks something like this: let (a, b) = ("", 0); ‣&str ‣i32 (I'm not really able to take screenshots right now). Basically, there is some extra code that first checks if there's already another hint on the line, and adds it rather than clobbering it.

I do not believe that conceal would be an applicable solution, since virtual text does not (to my knowledge) get syntax highlighting. It might be possible (although difficult and likely not worthwhile) to insert text into the buffer, but prevent it from getting written with the document. It would also need to be stripped out for almost any operation that touches the buffer...

An alternate solution for some hints would be to provide them in some type of hover. This would most likely be implemented as a floating window, placed just above the current line, and can contain all the hints for the current line.

When/if anti-conceal does stabilize, it would be nice to take advantage of, but until then, we can do reasonably well without. It would be nice to take advantage of param name hints at some point.

[fannheyward]

@the10thWiz thanks for your PR, released in v0.21.0.

[typoon]

So, I have added a little logic to @the10thWiz change just to show the name of the symbol together with its type so it is easier to see and make sense of it.

With this, it gets it pretty close to the ideal solution.

[the10thWiz]

An ideal implementation would look something like ‣(my_str: &str, an_int: i32, x: f64), but this would require some serious work. A much easier improvement would be to add a separate seperator symbol for chaining hints, since they are a return type, not a variable type. The default could be ->, although there is probably a better UTF-8 character.

If we do want to use -> for chaining hints, it might be a good idea to set the default type hint separator to :, to match rust. However, this might be somewhat confusing and needs some testing.

[xltan]

So, I have added a little logic to @the10thWiz change just to show the name of the symbol together with its type so it is easier to see and make sense of it.

With this, it gets it pretty close to the ideal solution.

I think this is too verbose, can we have an option to get rid of the variable name?

[xltan]

Most case, we will only have one variable, which will give you something like this.

struct SomeStruct;
let some_var = SomeStruct;  ‣some_var: SomeStruct

[fannheyward]

@xltan rust-analyzer.inlayHints.typeHintsWithVariable is added, default true, please give it a test.

[xltan]

cool, works as expected, thanks👍

[svenstaro]

I think this should be reopened as parameterHints doesn't seem to be supported yet.

[fannheyward]

@svenstaro we can't add parameterHints by now because we can't set text/virtual text inline. This needs vim/nvim to add this support.

[svenstaro]

Ah, is there some kind of upstream ticket tracking this feature in vim/nvim?

[fannheyward]

@svenstaro I don't know.

[oblitum]

@svenstaro neovim/neovim#9496 (comment)

[svenstaro]

Welp, that doesn't look like it's going anywhere soon. Thanks for the reference, though.