Recently, Niko and I landed our first batch of changes in rethinking how we display compiler error messages. Error messages in Rust, especially ones like borrow checker errors, have a lot of moving parts to them. As a new user, the first time you see errors like this can be daunting. The information is there, but you have to wrap your head around it to know what to do next.
We’ve got a new design that we think helps to bring out the most important information. You can try it out using a nightly build and setting the RUST_NEW_ERROR_FORMAT environment variable (eg, “export RUST_NEW_ERROR_FORMAT=true” in bash). Here is how it looks.
The new format has a few advantages over the previous format:
- We’ve removed the redundant line information, which cuts down on noise
- Put your source front and center
- We use callouts, bolding, and coloring to focus your eyes on the key part of the error while also noting important other bits of information
As you can see, it’s not that we’re really showing different information than we were previously, we’re just displaying it in a way that’s a bit easier to read and understand.
We’re not done, yet, and we’d love your help. We have a set of improvements we’d like to make which are tracked with this meta-issue: https://github.com/rust-lang/rust/issues/33240. Feel free to file formatting issues, readability issues, missing info bugs, etc and mention the meta-issue. So far, we’ve been converting borrow check errors to the new format. We’d also like to convert region check errors as well. We have some ideas, and if you like to help out let’s chat.
We’d like to keep design discussions on the format here on the internals list as it’s nicer to have to have full discussions here.
Also, if you are a maintainer for one of the Rust editor plugins, we’re currently discussing how the new errors and editors interact in this thread: Editor compatibility and the new error format
For those that are still reading and are curious about the ins and outs of the design, here’s a quick overview of the different parts.
Header: The header is now split across two lines. The first line starts with an indicator of what the message type is (Error, Warning, etc), followed by the main message text and then by the error code. The second line is indented underneath and gives the location. This should let your eye quick “lock on” to what the message is about, and then where it is.
Line number column: The line number column replaces the are where we previously put the full filepath. Same idea here, we want to give you a way to see what lines the errors were on. We separate these lines with the |> to help separate the line numbers from the source. This serves double duty by also creating a box around your source. The combination of this and the indentation above makes it easy, at a glance, to see each error separately and find each of the parts.
Source code area: Your source code. We pull out the relevant lines that have error/warning/note spans (just as before) but grouped in the same order you might see them in your source. We also have labels on each span. Ideally, for readability, all spans should have labels, but we haven’t quite gotten there yet.
Optional notes: We still have the optional notes, just like we did with the old error format. Things like expected/found will show up here, for example.