Get the default panic hook for ICEs, from std::panic::set_hook
.
#732
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.
Tested by adding
-Ztreat-err-as-bug
totest_rustc_flags
intests/src/main.rs
and observing that the output does include the panic information printed by the default panic hook (i.e.std
's).Background: since the rustup in #716, we've had broken ICEs - they would show this message, and the lines after that, but none of the panic information that is supposed to precede it (and
RUST_BACKTRACE=1
did nothing):That's because of an interaction between rust-lang/rust#85640 and our own use of
report_ice
- thankfully, @bjorn3 provided a solution that doesn't require upstream changes, in the form of an aspect ofstd::panic::take_hook()
I missed: you can keep calling it and it will returnstd
's default panic hook, as opposed to crashing and/or returning some kind of noop closure.This is documented on
std::panic::take_hook
as such:Knowing that, it's easy to see why you can just call it more than once to both clear any existing panic hooks and get
std
's default panic hook - but I went a bit farther to try and guard against strange mishaps.