Compiler diagnostics improvement wishlist

[stjepang]

To expand a little on this: when parens/brackets/quotes are not closed or don’t match, I wish the compiler tried to analyze identation levels of the relevant lines of code and gave a hint (best guess) on which delimiter is the problem. Maybe even a suggestion for the fix.

Hunting for these kinds of errors can be frustrating. I usually reindent my code in Vim and then scroll through it to see where indentation becomes messed up. The compiler could be of great help here.

[GolDDranks]

The other day I tried to use to_owned() on a reference. I was surprised to find that the result wasn’t an owned, cloned copy, but another reference, which caused a type mismatch. The problem was that the struct didn’t implement Clone. I think that to_owned() returning a non-owned thing is surprising and there should be a help message that explains that you should derive Clone for that struct for it to work.

[Deewiant]

E0282 “type annotations needed” sometimes offers too little context. For example:

fn main() { Err(1); }

Leads to:

error[E0282]: type annotations needed
 --> asdf.rs:1:13
  |
1 | fn main() { Ok('x'); }
  |             ^^ cannot infer type for `E`

But what is this E? The program certainly doesn’t mention it. Okay, I can check the documentation for Result and see that it’s Result<T, E> and make the connection between that E and the one in the error message, but I think that’s asking a bit much.

Here’s a more confusing case:

fn main() { (|| { Err('x')?; Ok(()) })(); }

Now we have:

error[E0282]: type annotations needed
 --> asdf.rs:1:19
  |
1 | fn main() { (|| { Err('x')?; Ok(()) })(); }
  |                   --------
  |                   |
  |                   cannot infer type for `_`
  |                   in this macro invocation

I honestly don’t know where _ comes from here.

Cases like the above are not that problematic, after all we were just dealing with Result and some simple expressions. But in general, with more complicated interactions and generic types from less familiar crates than std, it can be tricky to see what exactly the compiler cannot infer.

Concretely, I think this could benefit from something like a note saying could only infer Result<char, E> where E is still generic.

[canndrew]

Giving tons of error messages due to the same problem is not helpful.

To expand on this: when I run cargo build in a terminal I always scroll all the way to the top to see the first error messages because I don’t trust anything else to be relevant. I would like it if there was a way to limit the number of errors through a global config setting (so I don’t have to scroll to the top), but it would be just as good if rustc was very strict about not any emitting any errors that could possibly have been caused by an earlier error.

[fweimer]

“expected type parameter, found (something else)” is my personal favorite. The error message is actually not bad in isolation, but this:

fn func<T, U>(t: T) -> U {
    t
}

results in:

error[E0308]: mismatched types
 --> file.rs:2:5
  |
1 | fn func<T, U>(t: T) -> U {
  |                        - expected `U` because of return type
2 |     t
  |     ^ expected type parameter, found a different type parameter
  |
  = note: expected type `U`
             found type `T`

And this is confusing because syntactically, at the indicated place, you cannot use a type parameter at all.

[petrochenkov]

The first module reform thread had a great user story about how missing help/suggestions make learning module system harder than it needs to be:

Revisiting Rust's modules

I think myself that the biggest issue with Rust’s module system is language not helpful enough if you get it wrong unlike other parts of a language, which is very likely if you are learning Rust. When making a new project in Rust, a following tree is created. |-- Cargo.tml `-- src `-- lib.rs src is encouraging in saying to an user - hey, put more stuff here - this is a good design here as it makes it clear that you can put more files - too bad that rest of the compiler doesn’t work togeth…

I think all the items in that report should be covered by diagnostics.

[abreis]

Smarter handling of code broken into multiple lines. For example:

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/a/mod.rs:39:18
    |
39  |                   .function(one, two)
    |                    ^^^^^^^^ expected 3 parameters
    | 
   ::: src/b/mod.rs
    |
88  | /     pub fn function(
89  | |         self: &mut Self,
90  | |         p_one: Something,
91  | |         p_two: Something,
...   |            // missing (3rd) parameter is outside context
104 | |         }
105 | |     }
    | |_____- defined here

Here, the context for the error doesn’t go far enough to show the actual 3rd parameter that is missing.

Newcomers to the language might also see 3 parameters in the error (self, p_one, p_two) and wonder why this thing is now requiring us to pass Self explicitly (it isn’t).

It gets a bit better if the function declaration is in a single line. It would be cool if the actual missing parameters were underlined, instead of just pointing to the whole declaration:

88 |     pub fn function(self: &mut Self, p_one: Something, p_two: Something, p_three: Something) -> Result<Something, ()> {
   |     ------------------------------------------------------------------------------------------------------------- defined here

[matthieum]

cargo test stutters.

I suspect that the issue is that when executing cargo test the compiler is invoked twice: once in the regular mode, and once with the test feature defined (to actually compile the tests).

The end result, however, is that any error/warning in the “regular” mode is outputted twice. It’s not the end of the world, but I’ve never liked spamming

[nikomatsakis]

I strongly, strongly want to redesign the borrow checker error messages “from scratch” to use a lot less jargon. e.g., I think we only really need to talk about “borrow”, “read” and “write”. Words like lifetime etc aren’t needed. I’ve been meaning to write up a proposal on this at some point.

[emk]

I don’t have any concrete examples right now, but over the last year or so, the worst error messages that we regularly encounter at work are those involving diesel. We get tons of references to semi-internal traits, and also error messages containing type expressions like (((((((((((((((((((_))))))))))))))))))), except there are maybe three screens of nested parens.

Clearly, some of these error messages are caused by the specific design of the diesel crate, but diesel is far and away the best option we’ve found for type-checked SQL. I’m just brainstorming here, but maybe Rust could somehow provide more tools to library authors so that they could help guide the compiler towards generating more comprehensible error messages?

If I run into any specific examples in the immediate future, I’ll try to post them here.

[bjorn3]

Maybe automatically pipe output through less or more when the number of errors is above a certain threshold.

[djc]

One example that really sucks is when you have a call site where two different versions of the same trait are being referenced (one as required, the other as implemented). The compiler doesn’t understand what’s happening, and just tells you that two traits that are absolutely identical are incompatible.

See also https://github.com/rust-lang/rust/issues/44798 (Better error message for “[E0601]: main function not found”) and https://github.com/rust-lang/rust/issues/44695 (Ergonomics: &String does not implement PartialEq).

[gbutler]

I’d say this is 100% clear and I’m not a Rust programmer. This says, “You’ve declared that this function returns something of type U, but, you are returning t which is of type T”.

[canndrew]

Maybe automatically pipe output through less or more when the number of errors is above a certain threshold.

Well I do, really. But It’s annoying to type cargo test --color=always 2>&1 | head -n30 rather than just cargo test

Edit: Oh, automatically. Yeah, that’s a good idea. I didn’t read your comment properly the first time.

[aidanhs]

Syntax errors (previously noted in this thread) are annoying because they cause a cascade of unrelated failures.

https://github.com/rust-lang/rust/issues/32577 is a fun one where the borrow error message points to the wrong borrow.

https://github.com/rust-lang/rust/issues/42984 had me scratching my head for a while. I suppose my issue was that I didn’t understand (and still only vaguely have an idea) of what was causing the borrow of buffer to last for so long (note that changing from a trait object to a struct fixes it). I haven’t thought about it too much, but something like a ‘breakdown’ mode where the compiler explains the decisions it’s made about a lifetime might be useful?

[theotherphil]

This issue just caused me a lot of confusion: https://github.com/rust-lang/rust/issues/48701

[Eh2406]

error[E0405]: cannot find trait `Hash` in this scope
   --> src/main.rs:132:6
    |
132 | impl Hash for Person {
    |      ^^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
    |
1   | use util::read2::imp::winapi::_core::hash::Hash;

Specifically that last line where it did not suggest std.

[Kixunil]

My recent trouble:

help: the following trait is implemented but not in scope, perhaps add a `use` for it:
   |
1  | use std::os::ext::ffi::OsStringExt;
   |

So I happily put use std::os::ext::ffi::OsStringExt; where needed only to get this error message:

error[E0433]: failed to resolve. Could not find `ext` in `os`
  --> src/lib.rs:37:22
   |
37 |         use std::os::ext::ffi::OsStringExt;
   |                      ^^^ Could not find `ext` in `os`

warning: unused import: `std::os::ext::ffi::OsStringExt`
   --> src/lib.rs:37:13
    |
37 |         use std::os::ext::ffi::OsStringExt;
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: #[warn(unused_imports)] on by default

error[E0599]: no function or associated item named `from_vec` found for type `std::ffi::OsString` in the current scope

...

    help: the following trait is implemented but not in scope, perhaps add a `use` for it:
   |
1  | use std::os::ext::ffi::OsStringExt;
   |

Which is quite ridiculous.

This was confusing too:

error[E0308]: mismatched types
  --> src/lib.rs:26:25
   |
26 |                         Err(_) => true,
   |                         ^^^^^^ expected struct `std::vec::Vec`, found enum `std::result::Result`
   |
   = note: expected type `std::vec::Vec<u8>`
              found type `std::result::Result<_, _>`

I don’t remember how I solved this (I found it in terminal output), so I have no idea what the problem was.

Also, sometimes compiler prints out helpful “did you mean?” message and sometimes it doesn’t even if it probably could if it tried harder (looking into more modules). Ideally I could write use Whatever and get the list of all valid imports.

[Twey]

The errors that result from having multiple versions of a crate can be quite inscrutable.

A nice one I got today:

29 |         ReadBincode::new(new_inner(channel))
   |         ^^^^^^^^^^^^^^^^ the trait `std::convert::From<std::boxed::Box<bincode::ErrorKind>>` is not implemented for `my_module::Error`
   |
   = help: the following implementations were found:
             <my_module::Error as std::convert::From<std::io::Error>>
             <my_module::Error as std::convert::From<std::boxed::Box<bincode::ErrorKind>>>
   = note: required by `<tokio_serde_bincode::ReadBincode<T, U>>::new`

Edit: in fact, that’s part of a more general complaint about namespacing: namespacing in errors is done on a rather blanket basis, which can be a bit unhelpful.

On the one hand if you have only one Result (or OsStringExt) in scope it can make errors unreadable to refer to it as std::result::Result (resp. std::os::ext::ffi::OsStringExt) once the types get big — often to understand an error message I have to paste it into a new emacs buffer and manually remove a lot of the namespacing and format the types across multiple lines so I can see what’s actually going on.

On the other hand, in cases like the above where there are multiple things with the same name being referred to, it would be nice to have the types and traits prefixed by their crate and version — if the error read, for example,

29 |         ReadBincode::new(new_inner(channel))
   |         ^^^^^^^^^^^^^^^^ the trait `From<Box<bincode[0.8]::ErrorKind>>` is not implemented for `Error`
   |
   = help: the following implementations were found:
             <Error as From<io::Error>>
             <Error as From<Box<bincode[0.9]::ErrorKind>>>
   = note: required by `ReadBincode<T, U>::new`

(using the shorthand module names that are in scope where possible) the cause of the error becomes immediately clear.

[ekuber]

Thank you for all the replies. I’m glad to see that most of the responses are for things already in the backlog, which means that we’re already making progress towards fixing them. This feedback is invaluable to allow us to focus our efforts.

For future reference, some tickets to follow:

@iamcodemaker: https://github.com/rust-lang/rust/issues/47759

@isaacg1: https://github.com/rust-lang/rust/issues/48724

@GolDDranks: https://github.com/rust-lang/rust/issues/48876

@Deewiant: https://github.com/rust-lang/rust/issues/48089

@abreis: I know there’s a ticket but can’t find it. Diagnostics try to show you the code as it appears in the file as much as possible. I find the idea of reformatting the code for some diagnostics (like this one) interesting. It’ll probably be lower in priority as I feel there’re lower hanging fruit that need to be addressed, but it’s definitely worth exploring.

@emk: https://github.com/rust-lang/rust/issues/43354

@Eh2406: https://github.com/rust-lang/rust/issues/42944

@Twey: https://github.com/rust-lang/rust/issues/22750, needs some coordination with cargo.

Feel free to keep them coming!