Cosmetics: Don't print full module path in errors when the source file imports the Structs/Traits concerned by the error.

[najamelan]

I'm sorry if I bring something up that has been thought of before, but I couldn't find any issue through search. Currently rustc will print errors like this:

error[E0609]: no field `name` on type `&mut std::rc::Rc<std::cell::RefCell<State>>`
  --> src/main.rs:68:10

Given that the source file in question has:

use std::cell::RefCell;
use std::rc::Rc;

This error could look like this:

error[E0609]: no field `name` on type `&mut Rc<RefCell<State>>`
  --> src/main.rs:68:10

Now the example above is pretty trivial, but we all know how unwieldy and unreadable error messages can get, and I think any chance to shave off some text and make it brief and readable should be taken.

One could fear that it might be harder to figure out the exact constructs referred to, but given that errors are against code the dev wrote, and the dev uses these shortcuts through use I think that in practice this should be preferred in almost all cases. In the worst case the dev has to look at their own code to know what modules errors refer to.

Unfortunately I can't promise that I could provide a pull request implementing this since I have never hacked on rustc and I have limited time available, but if the fundamental idea is appreciated and someone is willing to seriously mentor a complete beginner in rustc dev, I would be up for trying. I will have time to develop between mid febuari and mid april.

[hellow554]

What if you have multible structs Rc? When to print which?

[najamelan]

@hellow554 Could you show an example. As far as I can tell when you import an Identifier with use, you cannot create another with the same name, because that would redefine the symbol. So if your code has use std::rc::Rc you can write Rc, and if an error occurs for that use, the error message could just show Rc.

Maybe some consideration needs to be made for how imports happen within macros. That's not exactly clear to me.

[estebank]

Duplicate of #21934. CC @pnkfelix as per our conversation in the all-hands, this is something tangential to other things you'll be tackling. I know that this won't happen in the short term, but would you be able to spare cycles to help mentor someone to do the work needed for this when you do start making the changes needed to enable this?

[najamelan]

@estebank Even though the issues seem related, I would specifically suggest shortening the names, regardless of private vs public paths. As an example, in the following image all paths are public, but that's not the point:

This code uses all of the involved types without paths like:
use tokio:: { prelude::{ stream::SplitSink }, net::{ TcpStream }, codec::{ Framed } } ; The suggestion here is to shorten the paths even if they are public.

Link from hackernews with more examples of unwieldy long error messages.

[najamelan]

I would even suggest to ban paths completely from types in error messages and to include the relevant use statements from the users code for disambiguation like:

use tokio   :: { net::{ TcpStream }, codec::{ Framed } };
use futures :: { stream::SplitSink                     };

let mb: Inbox<MyPeer> = Inbox::new();

error: the trait bound `SplitSink<Framed<TcpStream, [...]> is not satisfied`

For clarity, I abbreviated the error message here with the elipsis [...] for simplicity. I don't suggest rustc to do this. Also, I can't show the underlining rustc does in github markdown...

[najamelan]

Ha, this does seem to be a duplicate of #50310 though. Only just found that one now, and it's still open.