-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
format panic message only once #110721
format panic message only once #110721
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
This has the unfortunate limitation of forcing an allocation in the panic path even when one isn't necessary (e.g. when using |
@bors r+ |
format panic message only once For `panic!` and friends, the `std` panic runtime will always set the `.payload()` of `PanicInfo` to the formatted string. The linked issues show that formatting the message twice can cause problems, so we simply print the already formatted message instead of formatting it again. We can't remove the preformatted payload, because it can be observed by custom panic hooks. fixes rust-lang#110717 fixes rust-itertools/itertools#694 cc `@Amanieu` who broke this in rust-lang#109507
format panic message only once For `panic!` and friends, the `std` panic runtime will always set the `.payload()` of `PanicInfo` to the formatted string. The linked issues show that formatting the message twice can cause problems, so we simply print the already formatted message instead of formatting it again. We can't remove the preformatted payload, because it can be observed by custom panic hooks. fixes rust-lang#110717 fixes rust-itertools/itertools#694 cc ``@Amanieu`` who broke this in rust-lang#109507
format panic message only once For `panic!` and friends, the `std` panic runtime will always set the `.payload()` of `PanicInfo` to the formatted string. The linked issues show that formatting the message twice can cause problems, so we simply print the already formatted message instead of formatting it again. We can't remove the preformatted payload, because it can be observed by custom panic hooks. fixes rust-lang#110717 fixes rust-itertools/itertools#694 cc ```@Amanieu``` who broke this in rust-lang#109507
☔ The latest upstream changes (presumably #110789) made this pull request unmergeable. Please resolve the merge conflicts. |
The panic changes have been reverted, but it's still good to have this test. @bors r+ |
⌛ Testing commit cd398a6 with merge c61a497df072444f1e66487f5d409d142728bdc0... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Failure seems unrelated. @bors retry |
⌛ Testing commit cd398a6 with merge 1938114e1de4ff6bb282ed61c1005776b9645202... |
💔 Test failed - checks-actions |
looks spurious again: "failed to get successful HTTP response from https://crates.io/api/v1/crates/strsim/0.10.0/download, got 503" |
@bors retry |
Rollup of 7 pull requests Successful merges: - rust-lang#109702 (configure --set support list as arguments) - rust-lang#110620 (Document `const {}` syntax for `std::thread_local`.) - rust-lang#110721 (format panic message only once) - rust-lang#110881 (refactor(docs): remove macro resolution fallback) - rust-lang#110893 (remove inline const deadcode in typeck) - rust-lang#110898 (Remove unused std::sys_common::thread_local_key::Key) - rust-lang#110909 (Skip `rustc` version detection on macOS) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Formatting the panic message multiple times can cause problems for some real-world crates, so here's a test to ensure that we don't do that.
This was regressed in #109507 and reverted in #110782.
fixes #110717
fixes rust-itertools/itertools#694