Skip to content

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

Closed
@sxlijin

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-clippyArea: ClippyA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-feature-requestCategory: A feature request, i.e: not implemented / a PR.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions