Repository navigation
Rustc should use a variable other than RUST_LOG for env_logger. #57985
Description
Activity
Does
cargo build && RUST_LOG=debug cargo runnot suffice here?Does
cargo build && RUST_LOG=debug cargo runnot suffice here?Yes and no. It solves part of the problem in that it would remove the
rustcoutput if you remembered or even knew to do that. It obviously doesn't help with all of thecargooutput, but mycargoPR would take care of that in either case.At the end of the day, this issue is mostly about expectations. As mentioned, there are hoops you can already jump through to mitigate this somewhat by specifying module restrictions. There's just an unfortunate conflation of application interface and tooling interface here that leads to surprising results, so that's what I was hoping to mitigate if possible.
Reacted by Kornelnominating for discussion at future T-compiler meeting (probably post all-hands, i.e. not for another two weeks).
Reacted by Zach LuteI think we could rename it to
RUSTC_LOG(similarly to how other internal compiler env vars are named)Yeah, that makes sense to me. It probably makes sense for
cargoto useCARGO_LOGandrustcto useRUSTC_LOG.triage: P-medium, E-needs-mentor. Leaving nomination tag to try to ensure we discuss at T-compiler meeting in near future.
discussed at T-compiler meeting. no one present objected to the idea of each tool using its own specialized
MYTOOL_LOGenvironment variable.so we (informally at least) approve of this change and invite someone to post a PR for it. we do not believe this requires an RFC.
Awesome, I'll look into doing a PR for this shortly, then. Thanks!
(oh I should have removed nominated tag from this)
For anyone who's interested in doing this issue, you'd just need to change this line:
rust/src/librustc_driver/lib.rs
Line 1166 in 258e3b3
to instead call
init_from_env("RUSTC_LOG"). After that, I'd run all the tests and check that there's no other code that expects the variable to beRUST_LOGand do a grep to find any documentation that needs updated, also the rustc guide would need updated.
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.