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

[kmcallister]

No description provided.

[nagisa]

   -D OPT, --deny OPT
          Set lint denied

[kmcallister]

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.

[brson]

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.

[eddyb]

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

[kmcallister]

That sounds good to me if it can be done.

[huonw]

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

[nejucomo]

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.

[GuillaumeGomez]

The problem still exists.

[nagisa]

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.

[eddyb]

@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.

[steveklabnik]

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?

[Manishearth]

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

[Manishearth]

Nope, this is still the case.

Check out:

#![deny(warnings)]


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

(non-lint warning taken from #42326 )

[iluuu1994]

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.

[torhovland]

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