Only first cap-lints argument is used

[Mark-Simulacrum]

rustc --cap-lints=warn --cap-lints=foo should give an error on the invalid "foo" passed, but currently this does nothing.

It is not completely clear what exact behavior we want on --cap-lints=allow --cap-lints=forbid for example, though.

Currently this means that there's no way to override Cargo's default behavior on dependencies via RUSTFLAGS, for example.

[GuillaumeGomez]

Shouldn't only the last cap-lints instance be considered instead of just the first one?

[Mark-Simulacrum]

I believe the behavior we determined is that the first one is -- using the last one feels like 'the right thing' but I'm not sure it's feasible to make that change very well.

[GuillaumeGomez]

We can't know unless we try.

[steveklabnik]

Triage: given this code:

fn main() {
    100u8 << 10;
}

produces this:

~\tmp> rustc --cap-lints=allow --cap-lints=deny foo.rs
~\tmp> rustc --cap-lints=deny --cap-lints=allow foo.rs
warning: unused bitwise operation that must be used
 --> foo.rs:2:5
  |
2 |     100u8 << 10;
  |     ^^^^^^^^^^^
  |
  = note: `#[warn(unused_must_use)]` on by default

error: attempt to shift left with overflow
 --> foo.rs:2:5
  |
2 |     100u8 << 10;
  |     ^^^^^^^^^^^
  |
  = note: `#[deny(exceeding_bitshifts)]` on by default

That is, nothing has changed, the first parameter wins.

[weihanglo]

Do we ever want to change the behavior?

Cargo probes rustc information with extra rustc calls. If user provides RUSTFLAGS=--cap-lints=allow then some errors will be supressed and Cargo will fail (#116626 (comment)). If we are not able and not going to change, I think we can have a workaround in Cargo by passing an extra --cap-lints to override the user provided one.

Granted, Cargo should communicate with rustc through a better interface :)

[jieyouxu]

This is behavior of a stable compiler flag interacting with each other. If we do change it so last instance takes precedence, can that break users who rely on the first-instance wins behavior?