deny(warnings) doesn't affect all warnings, only those generated through the lint system

dde357c
Opened by Keegan McAllister at 2025-03-01 11:48:01
  1.    -D OPT, --deny OPT
          Set lint denied

    Simonas Kazlauskas at 2015-01-15 20:25:53

  2. The documentation is correct. But the behavior is extremely surprising and is likely to cause major trouble. -D warnings doesn't error on all warnings, just the ones that are nicely documented and commonly encountered. More obscure messages that are hard-wired with span_warn will go un-noticed on a build server until the scenario they're trying to warn about occurs.

    This shouldn't be too hard to fix; we just need to make -D warnings more special than it already is, by communicating that setting directly to the diagnostics printer.

    Keegan McAllister at 2015-01-15 22:33:03

  3. There is code to make -A warnings as set on the command line apply to the warnings rustc emits, but even that only applies to the Session's diagnostics and not to the ParseSess's.

    Perhaps SpanHandler just needs a callback to do arbitrary error transformation that can be hooked into the lint system.

    Brian Anderson at 2015-01-26 20:57:06

  4. Why even have warn and span_warn? There's very few uses of it, and they can probably all go through lints.

    Eduard-Mihai Burtescu at 2015-01-29 18:10:46

  5. That sounds good to me if it can be done.

    Keegan McAllister at 2015-01-30 01:08:06

  6. This is still an issue, although there's still not many uses of warn/span_warn.

    Huon Wilson at 2015-11-18 06:48:12

  7. Hi. I just ran into this issue for dead_code. I tried adding #[deny(warnings)] and when that didn't work, then I tried #[deny(dead_code)] which also has no apparent effect.

    btw, I don't understand what a span_warn is, nor do I have any intuition about which warnings use the lint system or not, so I don't know if dead_code is one of these. I think this is a good argument for fixing this ticket since I doubt other users will be aware of these implementation distinctions.

    neju como at 2015-12-06 16:02:24

  8. The problem still exists.

    Guillaume Gomez at 2016-05-28 14:11:58

  9. There’s a good reason to not support deny(warnings) at all from the stability standpoint. We want to add warnings at will without breaking users’ code and deny(warnings) makes that essentially an error.

    Simonas Kazlauskas at 2016-05-28 14:44:54

  10. @nagisa Didn't we solve that with --cap-lints and cargo setting it to "allow" for all dependencies? We can add error-by-default lints without breaking users of libraries that trigger the lints.

    Eduard-Mihai Burtescu at 2016-05-28 14:52:40

  11. Triage:

    #![deny(warnings)]

fn foo() {
    
}

    at least now properly errors. I'm not sure if the compiler's warning APIs are the same as when this bug was filed, or if this issue persists. Many @Manishearth or someone else from clippy knows?

    Steve Klabnik at 2019-03-11 20:57:43

  12. I'm pretty sure I've seen deny(warnings) apply to non-lint warnings (this broke a rustup for firefox where we weren't able to #[allow()] our way out without allowing all lints), but I need to check

    Manish Goregaokar at 2019-03-11 22:06:17

  13. Nope, this is still the case.

    Check out:

    #![deny(warnings)]


fn main() {
    let _a = "aa"_;
}

    (non-lint warning taken from https://github.com/rust-lang/rust/issues/42326 )

    Manish Goregaokar at 2019-03-11 22:10:07

  14. One problem with this one is that the example from @Manishearth "aa"_ is a lexer error. At that point the allow and deny attributes haven't been parsed. This example should compile fine but that would be hard to track in the lexer.

    Ilija Tovilo at 2019-07-24 22:33:01

  15. Given the insight from @iluuu1994, I don't think this issue should be tagged as easy.

    Tor Hovland at 2021-11-11 16:42:29

  16. This is tricky in general because some warnings exist before the lint system even "exists" (i.e. set-up).

    许杰友 Jieyou Xu (Joe) at 2025-03-01 11:47:51