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!

[pnkfelix]

(oh I should have removed nominated tag from this)

[davidtwco]

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

env_logger::init();

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 be RUST_LOG and do a grep to find any documentation that needs updated, also the rustc guide would need updated.

[davidtwco]

Closing as this was fixed in #60401.

cc @rust-lang/compiler so that everyone is aware the variable has changed.