Optimize the user experience when line gets too long after inlay hints are inserted.

[crlf0710]

Generally the code is usually formatted with the rustfmt, which keeps the characters per line below a certain limit. However when inlay hints get inserted, the lines sometimes gets too long, or even trimmed by screen edge.

Not sure what's the best solution for this. Maybe when a line will become too long after inlay hints are inserted, move all the hints out of line into a separate line using tiny font sizes as annotations?

[Veetaha]

I guess we could opt out showing inlay hints when the length of the line of code goes over some user-defined limit.
Is this something we should tackle from vscode frontend part, @matklad ?

[matklad]

We can do that, but I am unsure if the cure won't be worse than disease. I guess we should just do whatever IntelliJ does in this case (which IIRC is nothing).

[SomeoneToIgnore]

It would be great to get the code or at least see the screenshots of such cases.
The one that gets trimmed is a very interesting one.
Maybe there are some things we can shorten, but do not know about them yet: for instance, we still do not use type aliases in the hints.

[crlf0710]

Sure, one example is here:
https://github.com/crlf0710/charlesmine-rs/blob/41c6b473daaeb72cf8e9d6bee53682866374563c/src/controller.rs#L53

This line doesn't look very long by itself, however with inlay hints added, it looks like this:

the t is on column 60, and the inlay hint itself has 45 characters. When the left panel is not collapsed, the part after ::Targ|.... is trimmed off.

[SomeoneToIgnore]

That's an interesting case actually, first time ever I see the <_ as _> hint.
I would expect it to show the corresponding enum type instead, so that particular place can be improved, I think.
Not sure how to reproduce it though :)

No good ideas for the general case alas.

[crlf0710]

Create a small repro, don't know if this helps:

trait T1 {
    type O;
}

struct F<X: T1>(X);

impl<X: T1> F<X> {
    fn f<F>(&self, v: F) where F: FnOnce(&X::O) {
        unimplemented!()
    }
}

struct U;
impl T1 for U {
    type O = ();
}


fn main() {
    let s: F<U> = F(U);
    s.f(|z| {});
    println!("Hello, world!");
}

z is annotated: z: &<U as T1>::O here.

[SomeoneToIgnore]

Thanks a lot, small repros help tremendously.

Yet this example does not show any type hints for me since RA fails to infer its type:

I wonder, can that be caused by the rustc version you use?
I'm on the latest stable (1.41.0) and the latest RA (58f4dcf)

[crlf0710]

I'm on the latest stable (1.41.0) and this version https://github.com/rust-analyzer/rust-analyzer/tree/2020-02-11 of pre-compiled ra.

[Veetaha]

@crlf0710, I wouldn't be so sure about the version of precompiled ra). If you installed 2020-02-10 version of ra and then updated to 2020-02-11 you might not have downloaded the 11 version binary. This issue is tackled in #3162. To be totally sure you just press Ctrl+Shift+P, write > Toggle Developer Tools and you'll see the real version in the console tab:

[crlf0710]

Thanks for the instructions! Here is my result.

[Veetaha]

Hmm, yeah, you do use 2020-02-11 ra_lsp_server release.

[lnicola]

I can reproduce this:

[SomeoneToIgnore]

On a newer version it started to for me too, weird.

But after I looked at it, I think this particular one is type-inference related, so we better fix that, not the inlay hints.
The type of the closure parameter should be (), shouldn't it?
We need to summon @flodiebold to get a guidance on the issue.

[lnicola]

That seems reasonable, but our type shortening doesn't seem to work great in this case:

[SomeoneToIgnore]

I don't think this particular case differs from this one:

Or, rather, it differs in a way that it's type inreference-related: instead of thinking about the hints shortening for this case, we need to concentrate on type resolution to eliminate all <_ as _>::_ for good from the hints.

As for the long identifier names, I think it's a minor case compared to the complex types with <<<>>>, and those we're already trimming, if the correspnding setting is set.

So no bright ideas currently, especially with intellij-rust having neither also :)