Message caching does not allow switching --message-format between short and human

[SuperCuber]

I ran this command:

cargo check --message-format short

On previous versions, this outputted one error per line.
Instead now, it outputs the same as --message-format human.

However, cargo build --message-format short outputs as expected.

EDIT
Seems like it's also an issue with cargo build. I played around with it, this is how to reproduce:

• Save your main.rs file
• try check or build with --message-format human - works as expected
• try --message-format short - still displays human
• re-save main.rs
• try --message-format short - works as expected
• try --message-format human - still displays short

Meta

rustc --version --verbose:

rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-unknown-linux-gnu
release: 1.48.0
LLVM version: 11.0

cargo --version --verbose:

cargo 1.48.0 (65cbdd2dc 2020-10-14)
release: 1.48.0
commit-hash: 65cbdd2dc0b7e877577474b98b7d071308d0bb6f
commit-date: 2020-10-14

[ehuss]

Transferred to the rust-lang/cargo repository.

This is a known issue where the cached messages do not allow switching between human and short (see #7450 for a little more discussion). It was decided that switching the format shouldn't trigger a rebuild, and it is not currently possible for the compiler to emit both formats at the same time.

For now, I suggest either avoiding switching between formats, or just accept that cached messages may be in a different format.

[SuperCuber]

I see... I've seen in a related Clippy issue that you could use --release as a semi-workaround for this because it is seperate from the debug build that an automated linter triggers, so I guess I will try to use that.

Don't know if I should close the issue or not because it seems like it won't be fixed, but I do want to voice my opinion that this behavior is pretty unexpected and breaks at least my workflow.

[ehuss]

I think it is fine to leave this open, just with the caveat that it will likely be difficult to fix.

[divagant-martian]

I'm using cargo 1.55.0 and errors are printed in one line, warnings in human format

[JShorthouse]

It was decided that switching the format shouldn't trigger a rebuild

Just ran into this issue... my opinion is that a rebuild would be preferable to the current behavior.

I would rather have to wait and eventually be shown the output I want, than be shown the wrong output I've specifically told cargo I don't want.

I think the following would make sense:

• cargo check: (with no explicit format) just show whatever is cached
• cargo check --message-format=: always honour the specified message format, even if it requires a rebuild