Skip to content
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

Tracking Issue for panic_any #78500

Closed
3 tasks done
m-ou-se opened this issue Oct 28, 2020 · 8 comments
Closed
3 tasks done

Tracking Issue for panic_any #78500

m-ou-se opened this issue Oct 28, 2020 · 8 comments
Labels
A-error-handling Area: Error handling A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@m-ou-se
Copy link
Member

m-ou-se commented Oct 28, 2020

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

Unresolved Questions

  • None yet.
@m-ou-se 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 camelid added the A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows label Oct 28, 2020
@KodrAus KodrAus added the Libs-Tracked Libs issues that are tracked on the team's project board. label Nov 6, 2020
@KodrAus KodrAus added the A-error-handling Area: Error handling label Nov 28, 2020
@m-ou-se
Copy link
Member Author

m-ou-se commented Jan 9, 2021

@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
Copy link

rfcbot commented Jan 9, 2021

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.

@rfcbot 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
@sfackler
Copy link
Member

sfackler commented Jan 9, 2021

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

@m-ou-se
Copy link
Member Author

m-ou-se commented Jan 9, 2021

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
Copy link
Member

sfackler commented Jan 9, 2021

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 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
Copy link

rfcbot commented Jan 9, 2021

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

@rfcbot 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
@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Jan 19, 2021
@rfcbot
Copy link

rfcbot commented Jan 19, 2021

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.

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jan 21, 2021
@KodrAus
Copy link
Contributor

KodrAus commented Jan 29, 2021

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!

cratelyn pushed a commit to cratelyn/rust that referenced this issue Mar 3, 2021
 ### 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.
cratelyn pushed a commit to cratelyn/rust that referenced this issue Mar 9, 2021
 ### 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-error-handling Area: Error handling A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants