I'm trying to write a pre-commit hook that (1) applies fixes from clippy --fix, and (2) fails if there are any remaining clippy errors, by returning a non-zero exit code.
If I just run clippy --fix, it will apply fixes, but it returns a success error code even if the build has unfixable errors. Is that expected behavior?
The only solution I found is to run clippy --fix && clippy, but that compiles everything twice, which is obviously not ideal.
Unfortunately that's the only way to guarantee that you don't have any lints left over. The adjustments made by --fix could trigger/expose new lints not caught the first time.
Thanks for explaining, that makes sense. It also explains why the result isn't cached between the first and second clippy.
It still seems like there's room for improvement. Consider this code:
#[deny(clippy::all)]
fn main() { drop(0); }
It's a lint error, and not fixable. If I run cargo clippy, I get exit code 101 as expected, because there's an error. However if I run cargo clippy --fix, I get exit code 0, despite the error. Clippy sees the error, then throws that information away and returns a success code. So if I want to fail on errors, I can't rely on the exit code like usual and instead I have to run clippy again without --fix. Is there a way to access the result of the first build without building twice?
Imho that's just a clippy bug, it should be failing in that case
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.