Tracking Issue for `panic_any` #78500

m-ou-se · 2020-10-28T20:22:46Z

Feature gate: #![feature(panic_any)]

This is a tracking issue for std::panic::panic_any, a function to allow panicking with any value.

Context

Right now, it is possible to panic (that is, std::panic!) on any value: panic!(123). This will be disallowed in Rust 2021, when panic!(..) will always take a format string just like println!(..). At that point, this function will be the only way to panic without a (format) string. (See #80162 and rust-lang/rfcs#3007.)

Public API

mod std::panic {

    /// Panic the current thread with the given message as the panic payload.
    ///
    /// The message can be of any (`Any + Send`) type, not just strings.
    ///
    /// The message is wrapped in a `Box<'static + Any + Send>`, which can be
    /// accessed later using [`PanicInfo::payload`].
    ///
    /// See the [`panic!`] macro for more information about panicking.
    pub fn panic_any<M: Any + Send>(msg: M) -> !;

}

Steps / History

Implementation: Add std::panic::panic_any. #74622
Final commenting period (FCP)
Stabilization PR: Stabilize std::panic::panic_any. #81194

Unresolved Questions

None yet.

The text was updated successfully, but these errors were encountered:

m-ou-se · 2021-01-09T12:45:33Z

@rfcbot merge

Once this is stable, we can add a lint about using this function instead of panic!(x) for non-strings, as part of RFC 3007 (see #80162).

rfcbot · 2021-01-09T12:45:34Z

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

sfackler · 2021-01-09T13:12:53Z

It seems like the function signature is missing a 'static bound?

m-ou-se · 2021-01-09T13:27:04Z

It seems like the function signature is missing a 'static bound?

Any: 'static already requires that. I can add it in the stabilization PR to make it explicit.

sfackler · 2021-01-09T14:07:38Z

Oh right, I think I asked this same question when this function was added! Yeah, might be best to add the duplicate bound in.

rfcbot · 2021-01-09T20:24:50Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2021-01-19T20:26:58Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

KodrAus · 2021-01-29T12:48:15Z

Now that this is stable I'll go ahead and close this tracking issue. Please feel free to re-open if we'd like to keep it around until 1.51.0 actually ships!

### Integration Tests This commit introduces some new fixtures to the `run-make-fulldeps` test suite. * c-unwind-abi-catch-panic: Exercise unwinding a panic. This catches a panic across an FFI boundary and downcasts it into an integer. * c-unwind-abi-catch-lib-panic: This is similar to the previous `*catch-panic` test, however in this case the Rust code that panics resides in a separate crate. ### Add `rust_eh_personality` to `#[no_std]` alloc tests This commit addresses some test failures that now occur in the following two tests: * no_std-alloc-error-handler-custom.rs * no_std-alloc-error-handler-default.rs Each test now defines a `rust_eh_personality` extern function, in the same manner as shown in the "Writing an executable without stdlib" section of the `lang_items` documentation here: https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib Without this change, these tests would fail to compile due to a linking error explaining that there was an "undefined reference to `rust_eh_personality'." ### Updated hash * update 32-bit hash in `impl1` test ### Panics This commit uses `panic!` macro invocations that return a string, rather than using an integer as a panic payload. Doing so avoids the following warnings that were observed during rollup for the `*-msvc-1` targets: ``` warning: panic message is not a string literal --> panic.rs:10:16 | 10 | panic!(x); // That is too big! | ^ | = note: `#[warn(non_fmt_panic)]` on by default = note: this is no longer accepted in Rust 2021 help: add a "{}" format string to Display the message | 10 | panic!("{}", x); // That is too big! | ^^^^^ help: or use std::panic::panic_any instead | 10 | std::panic::panic_any(x); // That is too big! | ^^^^^^^^^^^^^^^^^^^^^ warning: 1 warning emitted ``` See: https://github.com/rust-lang-ci/rust/runs/1992118428 As these errors imply, panicking without a format string will be disallowed in Rust 2021, per rust-lang#78500.

m-ou-se added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Oct 28, 2020

camelid added the A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows label Oct 28, 2020

camelid mentioned this issue Oct 28, 2020

Add std::panic::panic_any. #74622

Merged

KodrAus added the Libs-Tracked Libs issues that are tracked on the team's project board. label Nov 6, 2020

KodrAus added the A-error-handling Area: Error handling label Nov 28, 2020

m-ou-se mentioned this issue Jan 9, 2021

Tracking Issue for RFC 3007: Making core and std's panic identical in Rust 2021 #80162

Closed

16 tasks

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jan 9, 2021

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Jan 9, 2021

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jan 9, 2021

m-ou-se mentioned this issue Jan 19, 2021

Stabilize std::panic::panic_any. #81194

Merged

apiraino removed the to-announce Announce this issue on triage meeting label Jan 21, 2021

KodrAus closed this as completed Jan 29, 2021

jedisct1 mentioned this issue Feb 22, 2021

Don't use non-constant string as panic!()'s first argument bytecodealliance/lucet#636

Closed

leighmcculloch mentioned this issue Jul 13, 2022

Add host function for aborting current subtransaction with details / a status code stellar/rs-soroban-env#146

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for `panic_any` #78500

Tracking Issue for `panic_any` #78500

m-ou-se commented Oct 28, 2020 •

edited

Loading

m-ou-se commented Jan 9, 2021 •

edited

Loading

rfcbot commented Jan 9, 2021 •

edited by KodrAus

Loading

sfackler commented Jan 9, 2021

m-ou-se commented Jan 9, 2021

sfackler commented Jan 9, 2021

rfcbot commented Jan 9, 2021

rfcbot commented Jan 19, 2021

KodrAus commented Jan 29, 2021

Tracking Issue for panic_any #78500

Tracking Issue for panic_any #78500

Comments

m-ou-se commented Oct 28, 2020 • edited Loading

Context

Public API

Steps / History

Unresolved Questions

m-ou-se commented Jan 9, 2021 • edited Loading

rfcbot commented Jan 9, 2021 • edited by KodrAus Loading

sfackler commented Jan 9, 2021

m-ou-se commented Jan 9, 2021

sfackler commented Jan 9, 2021

rfcbot commented Jan 9, 2021

rfcbot commented Jan 19, 2021

KodrAus commented Jan 29, 2021

Tracking Issue for `panic_any` #78500

Tracking Issue for `panic_any` #78500

m-ou-se commented Oct 28, 2020 •

edited

Loading

m-ou-se commented Jan 9, 2021 •

edited

Loading

rfcbot commented Jan 9, 2021 •

edited by KodrAus

Loading