`--message-format` short doesn't give enough information for mismatched types

1

Given the following

fn main() {
    function(false);
}

fn function(_param: String) {

}

fn return_value(value: f64) -> f64 {
    5.
}

If I check it with cargo check --message-format short, I get

src/main.rs:2:14: error[E0308]: mismatched types
src/main.rs:9:17: warning: unused variable: `value`

With cargo check --message-format human

error[E0308]: mismatched types
 --> src/main.rs:2:14
  |
2 |     function(false);
  |     -------- ^^^^^- help: try using a conversion method: `.to_string()`
  |     |        |
  |     |        expected `String`, found `bool`
  |     arguments to this function are incorrect
  |
note: function defined here
 --> src/main.rs:5:4
  |
5 | fn function(_param: String) {
  |    ^^^^^^^^ --------------

warning: unused variable: `value`
 --> src/main.rs:9:17
  |
9 | fn return_value(value: f64) -> f64 {
  |                 ^^^^^ help: if this is intentional, prefix it with an underscore: `_value`
  |
  = note: `#[warn(unused_variables)]` on by default

I like the --message-format short because it can be easier to read errors when there are lots of them. Unfortunately the src/main.rs:2:28: error[E0308]: mismatched types doesn't have enough information to make an action. The unused variable: 'value' warning is good because it tells that value is unused. It would be nice if the src/main.rs:2:14: error[E0308]: mismatched types had the same sort of information in the diagnostic title.

src/main.rs:2:14: error[E0308]: mismatched types: false not assignable to String would be much better

1 Like
2

It has enough information to make the action of looking up the signature of function, doesn't it? believe it or not, this is how people would program before modern verbose compiler errors.

2 Likes
3

You're absolutely right. That's why I opened #126804, but it is sadly a bit difficult to land quickly because of how some tests are written, and there are some issues where the primary span label is redundant with the main message and there's disagreement on whether removing that "redundancy" and then rely on the previously linked PR to give full context in short messages is worth it. The alternative would be to add more info to the E0308 message, but I personally find that level of redundancy to be counter productive (people stop really reading big chunks of the errors that way).

If you don't mind me asking, could you tell us more about why you use the short message format? Is it just the level of information density? You don't miss the additional code context, note, label, help and suggestion information?

4

Not the OP, but a data point: recently I’ve used VSCode+rust-analyzer to write some Rust (instead of my usual tool a JetBrains IDE). I typically have VSCode’s terminal open at the bottom of the window. Given that the terminal panel is typically maybe 10-15 rows tall, vertical space is at a premium. I’d say that in my use around 95% of the time the extra help is just unneeded noise, and context is available by simply clicking the filename:lineno to open the troublesome location in the editor.

(I’d find it optimal if the IDE displayed the errors as a terse list, with the full message shown for the currently highlighted/selected error. But that’s up to IDE authors.)

1 Like
5

I'm also not the OP, but I do use --message-format short almost exclusively.

Is it just the level of information density?

Yes.

I typically have one window for vim (with no language server or other "IDE stuff" beyond syntax highlighting) and another for running cargo check --message-format short. I'll often have 20-30 errors (or more) to work through, and I want to pick out the ones that are most interesting, or related to the last piece of code I touched, or I want to find a group of related errors (like "fix all callsites of foo") to fix all at once. This is much easier with short format, which lets all the errors fit on one screen. With human, it's hard to spot patterns because they're potentially spread over hundreds of lines of output.

You don't miss the additional code context

If there's an error on line 400, I have to pull up that line in my editor anyway, at which point I'll see the same code in the editor that would have appeared in the snippet. However, for overlapping borrow errors, I often do want to see both borrows that are involved in the conflict, and I'll switch back to human format for the full multi-part snippet.

help and suggestion information?

I don't usually look at these. I'm pretty experienced with the language at this point, and in most cases I can think of a fix as soon as I understand specifically what rustc is unhappy about. The one exception that comes to mind is the suggestion to add a Self: 'a bound that's required on some GAT declarations.

note, label

I also mostly ignore these, with a few exceptions. For type errors, if I can't guess the problem just from looking at the indicated line and column, then I'll read the human output to see the inferred and expected types. Similarly for "type doesn't implement trait". And for linker errors, all the useful information is in the linker output, which is emitted as a note.

There are probably some things I'm forgetting, but the ones I've mentioned cover the vast majority of cases where I have to fall back from short format to human format.

1 Like
6

You're making me wonder if it'd make sense to have a config for "expand these errors, give me short for these others".

As an additional question for everyone, if you're using VSCode, there is a pane that shows the list of every error as a single line, and there's also a link in the inline diagnostic that only shows the text to expand error and show the full ASCII-art compiler output. This seems to be the closest to the "ideal experience" where you get the summary but can get the full output through human interaction.

1 Like
7

A power law appears to be at work here. I use VSCode, and it works very well for me.

  • 90%: Seeing the read squigglies, I already know my mistake (e.g., "cannot borrow X as mutable").
  • 9%: A brief glance at the error description is required. (I'm having trouble coming up with an example. It's probably some random instance of the 90% bucket that I just didn't consider, and seeing the message it's immediately obvious.)
  • .9%: The full error message is integral to understanding and solving the issue (e.g., "X is not Send because it contains Y over here").
  • .1%: I pull my hair out for an hour or more (e.g., "implementation of X is not general enough").
1 Like
8

I'm using short messages in cargo-xcode, because Xcode can only extract one-liners from the build log.

9

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.