cargo-clippy should not fail early on lints that default to deny

[sxlijin]

Latest stable cargo check and cargo build (1.53.0) both succeed on BurntSushi/ripgrep@0ff5dd2, but cargo clippy fails on a lint that defaults to deny.

My expectation with a linter is that, on a well-formed AST (i.e. one that successfully can be compiled), it should show me all the lint errors in the code being linted so that I can triage/address them at my/our own discretion. Currently clippy bails out fast.

Although it is possible to downgrade deny lints to warn, I don't think this is very desirable, since it causes the user to lose information about the severity of the lint issue.

It was pointed out to me in the Zulip (thanks @jyn514 !) that there are a few levels of issues here:

• this can't be done in just clippy and needs rustc work for this to happen when compiling a single crate
• for inter-crate compilation, rustc would need to start distinguishing lint-only errors in output

[jyn514]

for inter-crate compilation, rustc would need to start distinguishing lint-only errors in output

To clarify: it would be fine for this to be rustc-only at first, but it doesn't solve the full issue if there's a path dependency, because rustc would print all lints for the first crate, error out, and then cargo would see the error and stop before compiling the next crate in the workspace.

[SNCPlay42]

See also #82761

[jyn514]

Closing in favor of #82761.