So @eddyb has argued that we should use RUSTC_LOG to control the log messages for rustc. Basically because if you do RUST_LOG=info cargo run you probably don’t mean to dump the compiler’s internal state. This makes sense to me. But I thought it made sense to float this decision in public before we actually do it.
There are some related questions:
how committed are we to the current log output for stability?
imo, anything less than “we make zero guarantees” is not an option
but I could imagine changing that policy, converting all existing logs to debug, and then adding things back in carefully
is it ok if RUST_LOG=debug ICEs?
i.e., should we consider such an ICE a “regression”?
traditionally it has ICEd in some scenarios, but it’d certainly be nice if it didn’t!
First, rustc is not the only tool in the toolchain. There’s at least cargo, rustup (it doesn’t use RUST_LOG now but I want it to), and rustdoc to consider. If you do a blanket RUST_LOG specification you’re going to get cargo output as well.
Second, it is anti-dogfooding. Rust logging was developed for all Rust crates to use, including rustc. If it is not serving that purpose well, then something is wrong. The log crate has facilities for controlling which things it is outputting, and maybe they are insufficient. Having rustc ditch the standard logging technique is papering over the problem. I doubt we would encourage all programs that find themselves in this situation to define their own logging variable. Are we going to have a CARGO_LOG, a RUSTUP_LOG?
I would also not characterize env_logger as the “standard” technique. It is a thing that was built out over time based on what compiler devs wanted, and only exists as its own crate because we didn’t want to drop it on the floor when cutting up the log crate a couple years ago.
A good point; tbh, I’m not sure that RUST_LOG=info (without giving a crate name) is a good pattern to support anyhow. Maybe we should just remove that workflow altogether. =)
(I guess we can’t easily do this, but we could do it at minimum for rustc.)
This isn't a point really worth arguing about, but log was once a keyword, so it was definitely once the logging system for Rust, though it's certainly been neglected over time.
+1 for doing something about this, I’ve been bitten by compiler ICEs recently when trying to enable debug logging in something I was developing.
Even being able to limit the logging by crate might not be ideal, if there’s a foundational crate used by all of rustup, cargo, rustc and the executable under development you could still get log lines from all of them if you try running via cargo run (unlikely, but possible).
As @brson says, many other tools will dump their logs on you if you do such a thing. You can either RUST_LOG=info ./target/debug/foo, or RUST_LOG=foo=info cargo run to get results you likely desire.
One thought for rustc and potentially cargo (mainly since they are common tools to be run with this environment unintentionally) is that the first log line could be “You’ve enabled debug/info logging for rustc/cargo. This may have been unintentional, [directions on how to disable].”
That would probably help alleviate at least some of the current confusion that exists when setting it, though it’s likely it’ll be missed by most users since the output fills up so quickly.
