This is related to Cargo Issue #6189.
In short, users generally don't expect tools to dump their debug output using the same mechanism their library or application uses to dump its debug output. As a user, when I do:
RUST_LOG=debug cargo run
I very much do not expect to be inundated with parse trees and such from cargo and rustc. This isn't a fabricated issue--I watched this confusion happen to numerous people in independent settings. While this can be mitigated by filtering your RUST_LOG by module, there's no obvious way to say "I want everything from my application and its dependencies, but nothing from the tooling."
I initially proposed fixing this for cargo by using a CARGO_LOG environment variable in Cargo PR #6605, but @alexcrichton rightly pointed out that that's only a partial solution to the problem and that to really get the behavior I want, we'd need to make a similar change at least to rustc, potentially sharing a new variable. (RUST_INTERNAL_LOG? Lots of bikeshedding possibilities here.)
To start determining if this is even feasible, I need to answer a few questions:
- Is the
RUST_LOG environment variable considered part of the stable interface for rustc? Is changing this even a possibility, putting aside whether it's desired?
- If this is possible, is there a strong reason NOT to do this (other than inertia) that I'm not considering?
Thank you in advance for any consideration and input.
This is related to Cargo Issue #6189.
In short, users generally don't expect tools to dump their debug output using the same mechanism their library or application uses to dump its debug output. As a user, when I do:
RUST_LOG=debug cargo runI very much do not expect to be inundated with parse trees and such from
cargoandrustc. This isn't a fabricated issue--I watched this confusion happen to numerous people in independent settings. While this can be mitigated by filtering yourRUST_LOGby module, there's no obvious way to say "I want everything from my application and its dependencies, but nothing from the tooling."I initially proposed fixing this for
cargoby using aCARGO_LOGenvironment variable in Cargo PR #6605, but @alexcrichton rightly pointed out that that's only a partial solution to the problem and that to really get the behavior I want, we'd need to make a similar change at least torustc, potentially sharing a new variable. (RUST_INTERNAL_LOG? Lots of bikeshedding possibilities here.)To start determining if this is even feasible, I need to answer a few questions:
RUST_LOGenvironment variable considered part of the stable interface forrustc? Is changing this even a possibility, putting aside whether it's desired?Thank you in advance for any consideration and input.