Move UnwindSafe, RefUnwindSafe, AssertUnwindSafe to core

[dtolnay]

They were previously only available in std::panic, not core::panic.

• https://doc.rust-lang.org/1.51.0/std/panic/trait.UnwindSafe.html
• https://doc.rust-lang.org/1.51.0/std/panic/trait.RefUnwindSafe.html
• https://doc.rust-lang.org/1.51.0/std/panic/struct.AssertUnwindSafe.html

Where this is relevant: trait objects! Inside a #![no_std] library it's otherwise impossible to have a struct holding a trait object, and at the same time can be used from downstream std crates in a way that doesn't interfere with catch_unwind.

// common library

#![no_std]

pub struct Thing {
    pub(crate) x: &'static (dyn SomeTrait + Send + Sync),
}

pub(crate) trait SomeTrait {...}

// downstream application

fn main() {
    let thing: library::Thing = ...;
    let _ = std::panic::catch_unwind(|| { let _ = thing; });  // does not work :(
}

See https://github.com/dtolnay/colorous/blob/a4131708e2f05d2377964981896ff62dbc9b027b/src/gradient.rs#L7-L15 for a real life example of needing to work around this problem. In particular that workaround would not even be viable if implementors of the trait were provided externally by a caller, as the feature = "std" would become non-additive in that case.

What happens without the UnwindSafe constraints:

fn main() {
    let gradient = colorous::VIRIDIS;
    let _ = std::panic::catch_unwind(|| { let _ = gradient; });
}

error[E0277]: the type `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
   --> src/main.rs:3:13
    |
3   |     let _ = std::panic::catch_unwind(|| { let _ = gradient; });
    |             ^^^^^^^^^^^^^^^^^^^^^^^^ `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)` may contain interior mutability and a reference may not be safely transferrable across a catch_unwind boundary
    | 
   ::: .rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:430:40
    |
430 | pub fn catch_unwind<F: FnOnce() -> R + UnwindSafe, R>(f: F) -> Result<R> {
    |                                        ---------- required by this bound in `catch_unwind`
    |
    = help: within `Gradient`, the trait `RefUnwindSafe` is not implemented for `(dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `&'static (dyn colorous::gradient::EvalGradient + Send + Sync + 'static)`
    = note: required because it appears within the type `Gradient`
    = note: required because of the requirements on the impl of `UnwindSafe` for `&Gradient`
    = note: required because it appears within the type `[closure@src/main.rs:3:38: 3:62]`

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #84730) made this pull request unmergeable. Please resolve the merge conflicts.

[dtolnay]

• Rebased to resolve conflict with Add auto traits and clone trait migrations for RFC2229 #84730 in library/std/src/panic.rs.

[dtolnay]

We discussed this change briefly in a meeting of the libs team. One concern was that there is a sense we may want to deprecate UnwindSafe and RefUnwindSafe and remove them as a bound from the catch_unwind argument. (Probably this would require an RFC, to get better visibility from people who may currently be finding the bound valuable. There is no way to add it back later!)

From following up with @Amanieu, whenever that deprecation were to happen it seems fine to deprecate simultaneously in both places (core::panic and std::panic). In the meantime I think I'd still like to have the traits available for using in trait objects in no_std crates.

Gonna try this to get an impression from folks who weren't in that meeting too:
@rfcbot fcp merge
@rust-lang/libs

[rfcbot]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @sfackler
• @yaahc

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.

[joshtriplett]

I would like to see them deprecated as well, but I don't see a good reason to delay making them available from core in the interim.

[rfcbot]

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

[rfcbot]

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.

[bors]

☔ The latest upstream changes (presumably #86603) made this pull request unmergeable. Please resolve the merge conflicts.

[dtolnay]

• Rebase to resolve conflict with Update to new bootstrap compiler #86603. @joshtriplett

[Amanieu]

@bors r+

[bors]

📌 Commit 96ecaa1 has been approved by Amanieu

[bors]

⌛ Testing commit 96ecaa1 with merge d2ee2ddf869eb476be3ec0f3f9250f3efdbf3aab...

[bors]

💔 Test failed - checks-actions

[dtolnay]

@bors r=Amanieu

[bors]

📌 Commit d1586fc has been approved by Amanieu

[bors]

⌛ Testing commit d1586fc with merge f381e77...

[bors]

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing f381e77 to master...