-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
std: Rename thread::catch_panic to panic::recover #29937
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
||
//! Panic support in the standard library | ||
|
||
#![unstable(feature = "std_panic", reason = "module recently added", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so, we do this a lot, but random thought: it's been weird to see some long-living feature gates with "recently added" as a reason.
dunno if there should be a better reason or not, just musing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto. Maybe "awaiting feedback"?
With our new issue tracking process, the reason
for unstable
items is less relevant; we could consider nixing it in favor of the issue number.
1865a8f
to
cb4141f
Compare
Are |
impl<'a, T: NoUnsafeCell + ?Sized> PanicSafe for *const T {} | ||
impl<'a, T: NoUnsafeCell + ?Sized> PanicSafe for *mut T {} | ||
impl<'a, T: PanicSafe> PanicSafe for Unique<T> {} | ||
impl<T: ?Sized> PanicSafe for Mutex<T> {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't RwLock
poisoned as well, hence PanicSafe ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
@eefriedman not currently, mainly because you can have |
a1c9ffc
to
db1631c
Compare
impl<'a, T: ?Sized> !PanicSafe for &'a mut T {} | ||
impl<'a, T: NoUnsafeCell + ?Sized> PanicSafe for &'a T {} | ||
impl<'a, T: NoUnsafeCell + ?Sized> PanicSafe for *const T {} | ||
impl<'a, T: NoUnsafeCell + ?Sized> PanicSafe for *mut T {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unsafe pointers are not listed as PanicSafe
in the RFC. Does this say that user-defined types that contain unsafe pointers to panic-safe things are automatically panic-safe? Why is that ok? Unsafe pointers are the only negative impls for the other OIBITS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the point of safety, using Safe
in the name is somewhat confusing/overloaded; if this trait isn't unsafe
, maybe we could name it something else? (I don't personally have any good suggestions, though. :( )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I'm surprised that was missing from the RFC; it was a key part of the earlier discussion. It's important for the FFI case in particular, and since using the pointers requires unsafe code anyway the need for tailored assertions like AssertPanicSafe
is lessened.
Remember that this trait is unlike the other OIBITs, by design, in several respects -- this being one of them. It's also a safe trait to implement. Like the existing approach to mitigating panic safety issues, the trait acts primarily as a "speed bump" when isolation boundaries may be violated.
I continue to believe this design is needlessly complicated by the misguided decision to narrow the meaning of 'unsafe' to 'memory unsafe'. Exception-safety is largely about memory safety, and with this design 'panic safety' actually is only a tiny slice of exception-safety. It's very misleading - it actually doesn't have anything to do with panicking safely, but recovering safely. I'm not going to be the one to approve this. |
use sys_common::unwind; | ||
use thread::Result; | ||
|
||
/// A marker trait which represents "panic safe" types in Rust. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussion on IRC suggested that this might be better called "recover safe". Is it worth trying to land with that naming (avoiding churn), or doing that through the FCP/comment process?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me to go ahead and land, tweaks to naming are pretty easy to do down the road.
The design is part of a long-going RFC process (including the lengthy thread for rust-lang/rfcs#1236) which tackled the issue of what safety covers in Rust (see e.g. my comment there). This PR represents the consensus design balancing between those worried about panic safety problems as well as those primarily concerned with ergonomics. During the RFC process you raised concerns about introducing a new OIBIT, but these concerns were addressed by the RFC text and design at least to the level that the relevant teams made a consensus decision to land the feature experimentally, as in this PR. It's vital that all team members abide by the consensus decisions we reached based on public discussion, even in cases where they personally disagree with the outcome. Consensus-based decision making is a fragile thing, and we all need to be operating openly and in good faith. Keep in mind that as always, there will be ample time to discuss this feature in the light of real-world experience on the tracking issue prior to stabilization. If there is an immediately actionable tweak to the design -- such as the proposed renaming to |
@alexcrichton I've done an initial review pass, and made several small suggestions about documentation, naming, and a couple about impls. Can we use |
1e48118
to
fc1a2bf
Compare
Updated with comments addressed, r? @aturon |
fc1a2bf
to
eb7e365
Compare
☔ The latest upstream changes (presumably #30187) made this pull request unmergeable. Please resolve the merge conflicts. |
r=me after a rebase. |
eb7e365
to
c39af12
Compare
@bors: r=aturon |
📌 Commit c39af12 has been approved by |
This commit is an implementation of [RFC 1236] and [RFC 1323] which rename the `thread::catch_panic` function to `panic::recover` while also replacing the `Send + 'static` bounds with a new `PanicSafe` bound. [RFC 1236]: rust-lang/rfcs#1236 [RFC 1323]: rust-lang/rfcs#1323 cc #27719
💔 Test failed - auto-mac-64-nopt-t |
c39af12
to
19892fd
Compare
@bors: r=aturon 19892fd |
⌛ Testing commit 19892fd with merge e0c4379... |
💔 Test failed - auto-mac-64-nopt-t |
This commit is an implementation of [RFC 1236] and [RFC 1323] which rename the `thread::catch_panic` function to `panic::recover` while also replacing the `Send + 'static` bounds with a new `PanicSafe` bound. [RFC 1236]: rust-lang/rfcs#1236 [RFC 1323]: rust-lang/rfcs#1323 cc rust-lang#27719
19892fd
to
0a13f1a
Compare
@bors: r+ 0a13f1a |
⌛ Testing commit 0a13f1a with merge 6bf8cc5... |
This commit is an implementation of [RFC 1236] and [RFC 1323] which rename the `thread::catch_panic` function to `panic::recover` while also replacing the `Send + 'static` bounds with a new `PanicSafe` bound. [RFC 1236]: rust-lang/rfcs#1236 [RFC 1323]: rust-lang/rfcs#1323 cc #27719
This commit is an implementation of RFC 1236 and RFC 1323 which
rename the
thread::catch_panic
function topanic::recover
while alsoreplacing the
Send + 'static
bounds with a newPanicSafe
bound.cc #27719