"-A warnings" cannot be overwritten later by `#[warn]` (but other "-A lint" can)

[RalfJung]

Given the following code

#![warn(warnings, unused)]

fn main() {
    let x = 13;
}

running rustc -A unused test.rs shows a warning that x is unused as expected (since the module scope takes precedence over the command-line arguments). However, rustc -A warnings prints nothing.

This is caused by the following special handling:

rust/src/librustc_session/session.rs

Lines 1178 to 1189 in 01ffbcb

	// FIXME: This is not general enough to make the warning lint completely override
	// normal diagnostic warnings, since the warning lint can also be denied and changed
	// later via the source code.
	let warnings_allow = sopts
	.lint_opts
	.iter()
	.filter(|&&(ref key, _)| *key == "warnings")
	.map(|&(_, ref level)| *level == lint::Allow)
	.last()
	.unwrap_or(false);
	let cap_lints_allow = sopts.lint_cap.map_or(false, |cap| cap == lint::Allow);
	let can_emit_warnings = !(warnings_allow || cap_lints_allow);

The FIXME already describes the problem, but I haven't found an open issue for this.

The special case was introduced by this commit as part of #21248. Looks like it is a hack needed to silence some otherwise unsilenceable warnings -- but I am not sure if the hack is still needed, or if there isn't a better way to do this.

[FabianWolff]

The other direction also doesn't work: -D warnings can't be overwritten either, it seems.

struct X {
    #[warn(dead_code)]
    a: i32,
}

fn main() {
    let _ = X { a: 2 };
}

compiled with e.g. -D unused leads to

warning: field is never read: `a`
 --> t1.rs:3:5
  |
3 |     a: i32,
  |     ^^^^^^
  |
note: the lint level is defined here
 --> t1.rs:2:12
  |
2 |     #[warn(dead_code)]
  |            ^^^^^^^^^

warning: 1 warning emitted

on current nightly; however, compiling with -D warnings gives

error: field is never read: `a`
 --> t1.rs:3:5
  |
3 |     a: i32,
  |     ^^^^^^
  |
  = note: `-D dead-code` implied by `-D warnings`

error: aborting due to previous error

which is obviously an inconsistency, because it pretends that the error is due to -D dead-code being implied by -D warnings, but this is untrue because -D dead-code by itself doesn't cause an error.

I get the same behavior for #![deny(...)], i.e., without any command line arguments, #![deny(unused)] inserted at the beginning of the above code will emit a warning whereas #![deny(warnings)] gives an error.

[RalfJung]

@FabianWolff this sounds like it is related to lint groups, I think I have seen similar behavior in the past: when a lint group is deny'd, just allow'ing a single lint from that group does not overwrite the deny. This should be tracked in a separate issue; could you check if one has already been reported and, if not, report a new one?

[RalfJung]

I think this is tracked here: #41941.

[FabianWolff]

I think this is tracked here: #41941.

I think you're right. Thanks for pointing this out! I had thought that the problem I described might be related to this issue because it looked so similar.

[jyn514]

there's also the opposite problem: -W warnings doesn't override #![deny(warnings)]:

; cat src/main.rs
#![deny(warnings)]
const C: usize = 1;

fn main() {
    core::mem::discriminant(&1);
}
; rustc src/main.rs
; rustc src/main.rs -Wwarnings                
error: constant `C` is never used
 --> src/main.rs:3:7
  |
3 | const C: usize = 1;
  |       ^
  |
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(warnings)]
  |         ^^^^^^^^
  = note: `#[deny(dead_code)]` implied by `#[deny(warnings)]`

error: the return value of `mem::discriminant` is unspecified when called with a non-enum type
 --> src/main.rs:6:5
  |
6 |     core::mem::discriminant(&1);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: the argument to `discriminant` should be a reference to an enum, but it was passed a reference to a `i32`, which is not an enum.
 --> src/main.rs:6:29
  |
6 |     core::mem::discriminant(&1);
  |                             ^^
  = note: `#[deny(enum_intrinsics_non_enums)]` on by default

I'd expect this to warn on dead_code (because -Wwarnings overrides the crate attribute) but error on enum_intrinsics_non_enums (because -Wwarnings shouldn't override the default lint level).

[RalfJung]

I'd expect this to warn on dead_code (because -Wwarnings overrides the crate attribute)

That would be inconsistent and a bug. Consider:

#[warn(warnings)]
mod outer {
  // Here, warnings are warnings.

  #[deny(warnings)]
  mod inner {
    // Here, they are errors.
  }
}

Command-line flags are "even more outer" than crate-level attributes, so your situation (-Wwarnings and #![deny(warnings)]) should behave consistently with my code above. And it does.

rustc is mostly consistent with this view I described. The issue here is about a case where it is not consistent.

If you want to fundamentally change that, you should open a separate issue, and it probably has to be an RFC, since this would be a change in intended behavior.