Improve type hints for long/deeply nested types (parser combinators etc.)

[zesterer]

Hello!

I'm the author of chumsky, a parser combinator crate. As I'm sure you know, parser combinators involve combining simple parsers together with the type system to produce parsers for more complex syntaxes.

Unfortunately, this can result in very large types that, although very useful to the compiler, are almost entirely useless for the programmer trying to work with them (each parser has a virtually identical API to any other, and so the type conveys no real meaning: only the traits that it implements matter).

I'm not personally a user of rust-analyzer, but I have a few users that are, and I've noticed that they're getting rather intrusive type annotations within combinator code, like so:

It would be great is there were a way to opt out of inline type hints (perhaps with an override) that could be controlled by crate developers. Perhaps it would be possible to have some sort of #[rust_analyzer(no_hint)] attribute that I can add to my combinator types that would be understood by rust-analyzer?

My apologies if this has already been requested: I checked existing issues already and was unable to find something similar.

[jhgg]

I don't think we should allow crate developers to turn off inlay hints - I fear this might lead to even more confusion for the end user. But perhaps we should endeavor to render something more sensible for inlay hints in places like this, similar to what is done for iterable chains already.

[1Dragoon]

Couldn't type aliases solve this?

[flodiebold]

No, because 1. rust-analyzer doesn't use type aliases when displaying types, and doing so is kind of complicated, and 2. type aliases can't really simplify such a nested type much anyway. padded() has to return Padded<Self>, so a type alias wouldn't help. Returning impl Parser would help, but has other problems.

[rami3l]

Playing with @zesterer's idea a bit, I'm wondering how we might get lib authors involved in this process by allowing them to annotate for example, "I want this to be displayed as some impl Parser instead of the concrete type".

For the reference:

• Optimize the user experience when line gets too long after inlay hints are inserted. #3138 (comment) shows that this issue is not uncommon when using external libs.
• Shorten type hints for std::iter Iterators #6154 shows how this issue is mitigated by showing impl Iterator for iterators.

[Veykril]

Ideally via #11556 would be my first thought