Consider enabling debug logging by default for contributors

[jyn514]

There was a lot of discussion in #76588 about enabling logging and it was almost a 10% perf hit on some benchmarks. So as it stands, the tradeoff is probably not worth it, especially since most of the time you aren't looking at debug! logging.

However, having debug! completely compiled out is extremely confusing the first time you go to add a debug!. While rustc-dev-guide can work on making this more discoverable, ideally this would always be on so you don't have to worry about it. I would love to get the perf impact low enough that this can be on by default (or even always on).

One possible way to work towards this is by moving the more verbose logging to trace! and compiling out trace instead. This allows keeping the (truly stupendous) amount of logging currently, but still making debug! work by default. Since trace! is rarely used, I expect this to be much less confusing for new contributors.

Originally posted by @jyn514 in #76588 (comment)

[Mark-Simulacrum]

I'm not sure how feasible it is to implement, but I think a message printed at startup along the lines of "you enabled debug logging in a filter, but it's been statically disabled, consider toggling debug-logging" would be a great partial fix here.

[RalfJung]

here was a lot of discussion in #76588 about enabling logging and it was almost a 10% perf hit on some benchmarks.

So that was 10% just from logging being enabled, without also enabling debug assertions or actually printing anything? That seems a lot.

I recall @eddyb hypothesizing that the perf hit is mostly caused by debug assertions.

[Mark-Simulacrum]

@hawkw, do you know if tracing upstream supports the "warn on statically disabled logging?" I mention here: #76608 (comment)?

I see https://docs.rs/tracing/0.1.19/tracing/subscriber/trait.Subscriber.html#method.max_level_hint, which looks promising, but I don't see a good way of detecting whether the environment variable filter parses to something that is more verbose than the current static (compile-time) levels.

[jyn514]

do you know if tracing upstream supports the "warn on statically disabled logging?" I mention here: #76608 (comment)?

This wouldn't need changes from tracing I don't think - we could add a cfg(feature = "max_level_info") to rustc_driver and print out a message on initialization if RUSTC_LOG was set to some value that includes debugging.

[Mark-Simulacrum]

Hm, by just seeing if it includes debug or trace levels? I guess we could, but it seems like maybe tracing upstream would be interested in printing a warning when this situation is detected. I would love to have this more universally true, rather than specific to rustc.

[hawkw]

Hm, by just seeing if it includes debug or trace levels? I guess we could, but it seems like maybe tracing upstream would be interested in printing a warning when this situation is detected. I would love to have this more universally true, rather than specific to rustc.

👋 This is something that we'd love to be able to do, but we don't currently support. It would be great to get a tracing feature request describing the particular use-case so we could see about implementing something upstream.

With that said, I imagine it would definitely be possible to write a simple implementation in rustc as a stop-gap until we land something upstream.

[jyn514]

Opened tokio-rs/tracing#975 for this.

[jyn514]

There was a lot of discussion in #76588 about enabling logging and it was almost a 10% perf hit on some benchmarks.

So that was 10% just from logging being enabled, without also enabling debug assertions or actually printing anything? That seems a lot.

It's now around 4.5%: #111924 (comment)