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

[kmcallister]

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