clarify must_produce_diag ICE for debugging
#132947
Merged
Conversation
This file contains 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
|
r? @fee1-dead rustbot has assigned @fee1-dead. Use |
rustbot
added
S-waiting-on-review
|
r? compiler |
compiler-errors
approved these changes
Nov 12, 2024
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 12, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#131831 (extend the "if-unchanged" logic for compiler builds) - rust-lang#132541 (Proper support for cross-crate recursive const stability checks) - rust-lang#132657 (AIX: add run-make support) - rust-lang#132901 (Warn about invalid `mir-enable-passes` pass names) - rust-lang#132923 (Triagebot: Consolidate the T-compiler ad hoc assignment groups) - rust-lang#132938 (Make precise capturing suggestion machine-applicable only if it has no APITs) - rust-lang#132947 (clarify `must_produce_diag` ICE for debugging) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 12, 2024
Rollup merge of rust-lang#132947 - lqd:trimmed-ice, r=compiler-errors clarify `must_produce_diag` ICE for debugging We have a sanity check to ensure the expensive `trimmed_def_paths` functions are called only when producing diagnostics, and not e.g. on the happy path. The panic often happens IME during development because of randomly printing stuff, causing an ICE if no diagnostics were also emitted. I have this change locally but figured it could be useful to others, so this PR clarifies the message when this happens during development. The output currently looks like this by default; it's a bit confusing with words missing: ``` thread 'rustc' panicked at compiler/rustc_errors/src/lib.rs:628:17: must_produce_diag: `trimmed_def_paths` called but no diagnostics emitted; `with_no_trimmed_paths` for debugging. called at: disabled backtrace stack backtrace: 0: 0x7ffff79570f6 - std::backtrace_rs::backtrace::libunwind::trace::h33576c57327a3cea at .../library/std/src/../../backtrace/src/backtrace/libunwind.rs:116:5 1: 0x7ffff79570f6 - std::backtrace_rs::backtrace::trace_unsynchronized::h7972a09393b420db at .../library/std/src/../../backtrace/src/backtrace/mod.rs:66:5 2: 0x7ffff79570f6 - std::sys::backtrace::_print_fmt::hae8c5bbfbf7a8322 at .../library/std/src/sys/backtrace.rs:66:9 3: 0x7ffff79570f6 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h1fd6a7a210f5b535 ... ``` The new output mentions how to get more information and locate where the `with_no_trimmed_paths` call needs to be added. 1. By default, backtraces are disabled: ``` thread 'rustc' panicked at compiler/rustc_errors/src/lib.rs:642:17: `trimmed_def_paths` called, diagnostics were expected but none were emitted. Use `with_no_trimmed_paths` for debugging. Backtraces are currently disabled: set `RUST_BACKTRACE=1` and re-run to see where it happened. stack backtrace: 0: 0x7ffff79565f6 - std::backtrace_rs::backtrace::libunwind::trace::h33576c57327a3cea ... ``` 2. With backtraces enabled: ``` thread 'rustc' panicked at compiler/rustc_errors/src/lib.rs:642:17: `trimmed_def_paths` called, diagnostics were expected but none were emitted. Use `with_no_trimmed_paths` for debugging. This happened in the following `must_produce_diag` call's backtrace: 0: <rustc_errors::DiagCtxtHandle>::set_must_produce_diag at .../compiler/rustc_errors/src/lib.rs:1133:58 1: <rustc_session::session::Session>::record_trimmed_def_paths at .../compiler/rustc_session/src/session.rs:327:9 2: rustc_middle::ty::print::pretty::trimmed_def_paths at .../compiler/rustc_middle/src/ty/print/pretty.rs:3351:5 ... ``` A `\n` could be added here or there, but it didn't matter much whenever I hit this case with the new message.
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.
We have a sanity check to ensure the expensive
trimmed_def_pathsfunctions are called only when producing diagnostics, and not e.g. on the happy path. The panic often happens IME during development because of randomly printing stuff, causing an ICE if no diagnostics were also emitted.I have this change locally but figured it could be useful to others, so this PR clarifies the message when this happens during development.
The output currently looks like this by default; it's a bit confusing with words missing:
The new output mentions how to get more information and locate where the
with_no_trimmed_pathscall needs to be added.A
\ncould be added here or there, but it didn't matter much whenever I hit this case with the new message.