Allow linking rustc and rustdoc against the same single tracing crate #140627
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
|
rustbot has assigned @GuillaumeGomez. Use |
rustbot
added
S-waiting-on-review
|
Do you have a regression test by any chance? |
|
This is not something Cargo can do. But I invited you to https://github.com/dtolnay/buck2-rustc-bootstrap where it's used. |
|
It's mostly that we'd have a regression test to prevent this bug from happening again. Nothing that can be tested with |
|
It can but would require maintaining a non-Cargo build of librustdoc, which is hundreds to thousands of lines of makefile code because of its big dependency graph. I don't think the cost/benefit justifies that. |
|
Even if we move rustdoc's tracing initialization out of librustdoc into a small separate crate and test that together with rustc_log, that still would require a non-Cargo build of all these crates: And reducing the bug any smaller than that ceases to be useful as a regression test. |
GuillaumeGomez
approved these changes
May 4, 2025
|
Indeed. It's a shame but not much we can do sadly... Thanks! @bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 4, 2025
Rollup of 6 pull requests Successful merges: - rust-lang#137280 (stabilize ptr::swap_nonoverlapping in const) - rust-lang#140457 (Use target-cpu=z13 on s390x codegen const vector test) - rust-lang#140619 (Small adjustments to `check_attribute_safety` to make the logic more obvious) - rust-lang#140625 (Suggest `retain_mut` over `retain` as `Vec::extract_if` alternative) - rust-lang#140627 (Allow linking rustc and rustdoc against the same single tracing crate) - rust-lang#140630 (Async drop source info fix for proxy-drop-coroutine) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 5, 2025
Rollup merge of rust-lang#140627 - dtolnay:rustdoctracing, r=GuillaumeGomez Allow linking rustc and rustdoc against the same single tracing crate Alternate title: _Ignore "a global default trace dispatcher has already been set" error in Rustdoc_ 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: ```console 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 ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Alternate title: Ignore "a global default trace dispatcher has already been set" error in Rustdoc
By consecutively initializing
tracingandrustc_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: