`Shell::warn` versus `env_logger` `warn!` output is confusingly disjoint.

[nathan-at-least]

Problem

There are two different categories of warnings sent either from Shell::warn or env_logger and it's not clear what the difference is, and controlling either kind is distinct and decoupled.

More Detail on the Problem

While trying to automate cargo, I want to fail an operation by policy if cargo outputs warnings. (This is specifically for cargo publish.) After not finding any commandline feature akin to --deny-warnings (treat warnings as errors) and seeing warnings and other output mixed on my terminal, I thought I would look into using CARGO_LOG environment variable to limit output to only errors and warnings, then consider any such output an error in my automation. This approach seeks to avoid parsing any Cargo output other than to detect its presence.

To my surprise, however, running CARGO_LOG=warn cargo publish --dry-run shows that there are two kinds of warnings: env_logger emitted warnings and the warnings that appear on stdout which I tracked down to the Shell::warn method. These seem completely disjoint, so I cannot rely on CARGO_LOG at all to help detect the other Shell::warn -style warnings which is what I care about.

I could see an argument that this is not a bug and that those are just two different streams, maybe one is for "normal users" and one is for "developer diagnostics". Never-the-less since I was surprised and assumed both things called "warnings" would be the same thing, I thought it worth a bug ticket.

Steps

1. Run a cargo command that produces Shell::warn output while the CARGO_LOG=warn environment variable is set. In my case I was running CARGO_LOG=warn cargo publish --dry-run --locked in a project without a license file.

Possible Solution(s)

A few options:

• Change Shell output to delegate to the logging system, so that all output has a consistent flow from source to destination, then ensure all warnings go through the Shell layer.
• Change only Shell::warn and/or error routines to delegate to the logging system, so the logging system contains a merger of the two different categories of warnings and is always a superset of all warnings.
• Don't make any change and clarify with user docs and dev policy how/why the two warning streams are different.

Notes

Output of cargo version:

cargo 1.44.1 (88ba85757 2020-06-11)

[ehuss]

CARGO_LOG is only intended for debugging and internal development. Since it serves a fundamentally different purpose than Cargo's (admittedly primitive) diagnostic system, I'm going to close this as this is the intended behavior. CARGO_LOG isn't directly documented at all in user docs (somewhat on purpose), so there really isn't any documentation to update here. There are other issues like #8424 (opened by reporter) and #8283 and #7380 for providing more structured output and control of warnings.