Rustc should use a variable other than RUST_LOG for env_logger.

[zachlute]

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:

1. 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?
2. 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.

[pnkfelix]

Does cargo build && RUST_LOG=debug cargo run not suffice here?

[zachlute]

Does cargo build && RUST_LOG=debug cargo run not suffice here?

Yes and no. It solves part of the problem in that it would remove the rustc output if you remembered or even knew to do that. It obviously doesn't help with all of the cargo output, but my cargo PR 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.

[pnkfelix]

nominating for discussion at future T-compiler meeting (probably post all-hands, i.e. not for another two weeks).

[oli-obk]

I think we could rename it to RUSTC_LOG (similarly to how other internal compiler env vars are named)

[zachlute]

Yeah, that makes sense to me. It probably makes sense for cargo to use CARGO_LOG and rustc to use RUSTC_LOG.

[pnkfelix]

triage: P-medium, E-needs-mentor. Leaving nomination tag to try to ensure we discuss at T-compiler meeting in near future.

[pnkfelix]

discussed at T-compiler meeting. no one present objected to the idea of each tool using its own specialized MYTOOL_LOG environment 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.

[zachlute]

Awesome, I'll look into doing a PR for this shortly, then. Thanks!