1611990 - Firefox omits Rust log messages of less than WARN level unless compiled in debug mode

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P2)

Description

[Andy Grover [:grover]]

Firefox !debug should still contain log messages from all levels, even below WARN

To reproduce:

1. Run nightly from the command line (on Linux) prefixed with "RUST_LOG=trace", to enable logging via env_logger.

Current behavior:
A single WARN-level message is emitted.

Expected behavior:
A flood of log messages from Firefox's many Rust components

This prevents outside collaborators easily generating debug logs for the component we're working on (neqo) without compiling Firefox themselves. This seems odd, since that C++ components seem to have all levels of log messages enablable in Nightly releases.

Comment 1

[Josh Matthews [:jdm]]

This looks intentional given the use of the release_max_level_info and release_max_level_warn features in https://searchfox.org/mozilla-central/source/build/workspace-hack/Cargo.toml#19 and https://searchfox.org/mozilla-central/source/servo/ports/geckolib/Cargo.toml#22.

Comment 2

[Andy Grover [:grover]]

(aside: why are both of those features currently given? Just release_max_level_warn appears like it would be enough)

Comment says: "This is based on the "rustc-workspace-hack" used by the rustc build system"

Chris, can you comment on the intentionality of this: on purpose, or is it a perhaps carried over from rustc usage?

Comment 3

[:Gijs (he/him)]

bug 1533838 was in xpcom; not 100% sure if this belongs there too, but if not it should probably go in a build system component or the one for the respective toml files (the other one in comment #1 has metadata pointing to Core :: CSS Parsing & Computation).

Comment 4

[Chris Manchester (limited bugmail, email directly)]

The workspace hack isn't intended to change the behavior of what we build, if it does that should be fixed. In this case it looks like that entry is out of date, and release_max_level_info is what's being specified by the downstream crates.

Comment 5

[Andy Grover [:grover]]

Attachment: Bug 1611990 - Firefox omits Rust log messages of less than WARN level unless compiled in debug mode r=chmanchester

Comment 6

[Andy Grover [:grover]]

With this change I'm now getting expected behavior in non-debug builds.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4277d047f5b7
Firefox omits Rust log messages of less than WARN level unless compiled in debug mode r=chmanchester

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/4277d047f5b7

Comment 9

[Emilio Cobos Álvarez [:emilio]]

I'm not sure I want all the code for trace! and debug! macros on the style system to be compiled on release binaries...

Why was this not expected behavior? I expect debug logging to only appear on well, debug builds. If you want release logging you have info! and warn! and error!...

I guess I can go put my debug logging behind #[cfg] or such, but...

Comment 10

[Chris Manchester (limited bugmail, email directly)]

I'm sorry, I don't have much of substance to add to the decision behind what logs are displayed. The purpose of the workspace hack is to unify features between crates compiled for js and those compiled for firefox so that cargo is able to treat the dependencies as shared. There shouldn't be any semantic changes. As I understood this patch it removed an entry that was no longer necessary, as I didn't see any release_max_level_warn left in the tree.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

But then the patch shouldn't have removed release_max_log_level_info, right? https://searchfox.org/mozilla-central/source/servo/ports/geckolib/Cargo.toml#22 still contains that feature.

Which makes me pretty unclear how this can be producing the expected results.

Comment 12

[Chris Manchester (limited bugmail, email directly)]

Yes, that's my mistake in reviewing. Sorry about that. I will fix that in a follow up and re-open this for the substantive discussion of what logs are appropriate to display in debug builds.

Comment 13

[Valentin Gosu [:valentin] (he/him)]

Taking this. Maybe we can manage to just not strip the neqo logs.

Comment 14

[Valentin Gosu [:valentin] (he/him)]

I fixed this in the neqo crate - we now use a log! replacement that ignores STATIC_MAX_LEVEL in the log crate.

https://github.com/mozilla/neqo/pull/645