cargo clippy --fix -- D warnings

[hombit]

I'm trying to figure out how to make cargo clippy fix what it can and return non-zero status code if it cannot. My naive approach was to run cargo clippy --fix -- -D warnings, but it doesn't prolongate warnings to errors, it even downgrade errors to warnings.

A simple code snippet to demonstrate it:

pub fn f() {
    if 100 > i32::MAX {}
}

This generates error by default, but with --fix it is just a warning

[flip1995]

-D warnings doesn't really make sense with fix. This is because when you use --fix you want that your code gets fixed and rustfix doesn't care if it fixes warnings or errors.

I might just not get the use case here. As a workaround, I can suggest to run cargo clippy -- -Dwarnings after running cargo clippy --fix.

[hombit]

Thank you for the answer! For me it is strange that when cargo clippy --fix cannot actually fix it just prints a warning, not error. My idea was to use it at pre-commit.ci as a single command, which could have three different results: 1) clippy found nothing, CI is passed, 2) all issues clippy found are fixed, CI commits these fixes, 3) clippy found some issues it can not fix, CI fails. I understand and agree with your suggestion, but I feel like either I missed something on docs, or just haven't fully got the idea of --fix, now it looks more like subcommand for me, not just an option

[flip1995]

--fix is more or less a cargo subcommand. You can run cargo fix which will apply all suggestions cargo check gives you. However due to historical reasons Clippy uses cargo clippy --fix instead of cargo fix --clippy (or something similar).

For cargo fix adding -- -Dwarnings wouldn't even work. Being able to specify lint levels on the cargo command line is a Clippy feature. That this is also possible with cargo clippy --fix is more a coincidence/oversight - as I said before, it doesn't really make sense.

In the background, Clippy just uses cargo fix/rustfix, so it adopts the behavior of it. I don't really know why not being able to apply everything is considered a warning in rustfix and not an error. But then again, rustfix is not meant for being used in CI. I would also argue that using it as a pre-commit hook is also questionable, because it changes code that then will be commited without re-checking the changes that it did or didn't do.

---

I can see that erroring if not all warnings/errors could be fixed is something useful in rustfix to have. But -D warnings is not the way to go here. I'm not 100% sure how best to address this, so I'd suggest you test if this is possible with just cargo fix and if it is not, this is probably an issue that needs to be addressed in cargo/rustfix first, before we can do something about it in Clippy.

[hombit]

Thank you, it makes much more sense for me now! Answering your question about CI usage: I see the same use-case as for using cargo fmt in CI: 1) it should not change what code actually do, 2) it commits to PR branch only, so it is considered as WIP changes, 3) after it commits other CI checks will run, including tests, 4) final decision about merging a PR makes a human

[flip1995]

Agree to disagree here. I'm of the strong opinion that CI should only run checks (cargo fmt --check instead of cargo fmt) and then the PR author should address the issues. But I know that the way you described it, is also used in some places and has its benefits.