rust/compiler/rustc_log, branch stable

Add documentation for init_logger_with_additional_layer

2025-06-12T10:11:15+00:00

Use closure to allow passing custom tracing layers

2025-06-11T08:42:50+00:00

The previous method, where a layer would be passed directly, required to pass a "no-op" layer when no custom layer was needed. This should have in theory worked, however having a no-op layer seems to change the way the tracing lib applies filters internally, leading to some debug!() being printed despite them being out of the minimum level for the filters. Note however that this behavior was very inconsistent, and e.g. some debug!() would get printed and some others wouldn't, for no apparent reason.

Allow initializing logger with additional tracing Layer

2025-06-11T08:41:22+00:00

Allow linking rustc and rustdoc against the same single tracing crate

2025-05-03T17:18:50+00:00

By consecutively initializing `tracing` and `rustc_log`, Rustdoc assumes that these involve 2 different tracing crates. I would like to be able to build rustdoc against the same tracing crate that rustc_log is also built against. Previously this arrangement would crash rustdoc: thread 'main' panicked at rust/compiler/rustc_log/src/lib.rs:142:65: called `Result::unwrap()` on an `Err` value: SetGlobalDefaultError("a global default trace dispatcher has already been set") stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::result::unwrap_failed 3: rustc_log::init_logger 4: rustc_driver_impl::init_logger 5: rustdoc::main note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-rustdoc&template=ice.md note: please make sure that you have updated to the latest nightly query stack during panic: end of query stack

Use `-Wunused_crate_dependencies` for compiler crates.

2025-03-19T21:59:43+00:00

It's very useful. There are some false positives involving integration tests in `rustc_pattern_analysis` and `rustc_serialize`. There is also a false positive involving `rustc_driver_impl`'s `rustc_randomized_layouts` feature. And I removed a `rustc_span` mention in a doc comment in `rustc_log` because it wasn't integral to the comment but caused a dev-dependency.

Revert "Use workspace lints for crates in `compiler/` #138084"

2025-03-10T10:12:47+00:00

Revert to buy time to consider options that avoids breaking downstream usages of cargo on distributed `rustc-src` artifacts, where such cargo invocations fail due to inability to inherit `lints` from workspace root manifest's `workspace.lints` (this is only valid for the source rust-lang/rust workspace, but not really the distributed `rustc-src` artifacts). This breakage was reported in . This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing changes made to c6662879b27f5161e95f39395e3c9513a7b97028.

Specify rust lints for `compiler/` crates via Cargo.

2025-03-07T21:41:09+00:00

By naming them in `[workspace.lints.rust]` in the top-level `Cargo.toml`, and then making all `compiler/` crates inherit them with `[lints] workspace = true`. (I omitted `rustc_codegen_{cranelift,gcc}`, because they're a bit different.) The advantages of this over the current approach: - It uses a standard Cargo feature, rather than special handling in bootstrap. So, easier to understand, and less likely to get accidentally broken in the future. - It works for proc macro crates. It's a shame it doesn't work for rustc-specific lints, as the comments explain.

Upgrade the compiler to edition 2024

2025-02-22T00:01:48+00:00

Avoid naming variables `str`

2025-01-07T12:30:02+00:00

This renames variables named `str` to other names, to make sure `str` always refers to a type. It's confusing to read code where `str` (or another standard type name) is used as an identifier. It also produces misleading syntax highlighting.

Reformat using the new identifier sorting from rustfmt

2024-09-22T23:11:29+00:00