`--cap-lints` ignored by `clippy --fix`

[kraktus]

Summary

While the --cap-lints flag is correctly taken into account when using cargo clippy, it is ignored when using cargo clippy --fix.

I'm not sure if the unexpected behaviour comes from the clippy driver or from rustfix, but passing the flags directly using RUSTFLAGS work as intended.

Reproducer

I tried this code:

pub struct Foo;

impl Foo {
    pub fn new() -> Foo { // new_without_default AND use_self
        Self
    }
}

fn main() {
    let a: u8; // unused_variables
}

running: cargo clippy --fix -- --cap-lints=allow

I expected to see this happen:

Nothing, same behaviour as for RUSTFLAGS="--cap-lints=allow" cargo clippy --fix

Instead, this happened:

Suggestions were applied

Version

rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: aarch64-apple-darwin
release: 1.64.0
LLVM version: 14.0.6

Additional Labels

No response

[flip1995]

If Clippy is not enabled, the arguments passed to Clippy are not forwarded to rustc:

rust-clippy/src/driver.rs

Lines 346 to 351 in 5b09d4e

	if clippy_enabled {
	args.extend(clippy_args);
	rustc_driver::RunCompiler::new(&args, &mut ClippyCallbacks { clippy_args_var }).run()
	} else {
	rustc_driver::RunCompiler::new(&args, &mut RustcCallbacks { clippy_args_var }).run()
	}

This includes --cap-lints=allow. I'm not sure why that is the case and if we were to forward them, if it would be problematic.

It probably would break things, because then we would also forward lint level flags to rustc, when compiling/checking dependencies.

---

Playing around with this a bit more, I don't think that this is the issue though. I think the issue is in how rustfix invokes Clippy/rustc and that it doesn't forward flags like this.

[kraktus]

Interesting. I'm not well versed in the rustfix <--> clippy dance, so I don't know if suddenly taking those arguments into account would be considered a breaking change.

I think at least warning ignored arguments would make sense