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

std: Rename thread::catch_panic to panic::recover #29937

Merged
merged 1 commit into from
Dec 9, 2015

Conversation

alexcrichton
Copy link
Member

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.

cc #27719

@rust-highfive
Copy link
Collaborator

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

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

Copy link
Member

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.

@alexcrichton alexcrichton force-pushed the panic-recover branch 2 times, most recently from 1865a8f to cb4141f Compare November 19, 2015 22:44
@eefriedman
Copy link
Contributor

Are Arc<i32> and &Arc<i32> supposed to be PanicSafe?

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> {}
Copy link
Contributor

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 ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!

@alexcrichton
Copy link
Member Author

@eefriedman not currently, mainly because you can have Arc<RefCell<T>> which isn't panic safe.

@alexcrichton alexcrichton force-pushed the panic-recover branch 2 times, most recently from a1c9ffc to db1631c Compare November 20, 2015 17:11
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 {}
Copy link
Contributor

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.

Copy link
Member

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. :( )

Copy link
Member

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.

@brson
Copy link
Contributor

brson commented Nov 24, 2015

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.

@brson brson removed their assignment Nov 24, 2015
use sys_common::unwind;
use thread::Result;

/// A marker trait which represents "panic safe" types in Rust.
Copy link
Member

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?

Copy link
Member Author

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.

@aturon
Copy link
Member

aturon commented Nov 24, 2015

@brson

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 RecoverSafe -- it's worth considering trying to land a tweaked version directly. The concerns you are raising here seem to be at least twofold -- the scope of "safety" in Rust and the "narrowing" of panic safety. The scoping issue I already mentioned (with relevant comment thread). The narrowing issue, I don't yet understand, but at this point discussion of the (de)merits of the feature in general (as opposed to minor design tweaks) should take place on the tracking issue.

@aturon
Copy link
Member

aturon commented Nov 24, 2015

@alexcrichton I've done an initial review pass, and made several small suggestions about documentation, naming, and a couple about impls. Can we use NoUnsafeCell to make Arc<i32> panic safe but Arc<RefCell<T>> not?

@alexcrichton alexcrichton force-pushed the panic-recover branch 2 times, most recently from 1e48118 to fc1a2bf Compare December 5, 2015 00:34
@alexcrichton
Copy link
Member Author

Updated with comments addressed,

r? @aturon

@bors
Copy link
Contributor

bors commented Dec 6, 2015

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

@aturon
Copy link
Member

aturon commented Dec 6, 2015

r=me after a rebase.

@alexcrichton
Copy link
Member Author

@bors: r=aturon

@bors
Copy link
Contributor

bors commented Dec 8, 2015

📌 Commit c39af12 has been approved by aturon

bors added a commit that referenced this pull request Dec 8, 2015
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
@bors
Copy link
Contributor

bors commented Dec 8, 2015

💔 Test failed - auto-mac-64-nopt-t

@alexcrichton
Copy link
Member Author

@bors: r=aturon 19892fd

@bors
Copy link
Contributor

bors commented Dec 8, 2015

⌛ Testing commit 19892fd with merge e0c4379...

@bors
Copy link
Contributor

bors commented Dec 9, 2015

💔 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
@alexcrichton
Copy link
Member Author

@bors: r+ 0a13f1a

@bors
Copy link
Contributor

bors commented Dec 9, 2015

⌛ Testing commit 0a13f1a with merge 6bf8cc5...

bors added a commit that referenced this pull request Dec 9, 2015
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
@bors bors merged commit 0a13f1a into rust-lang:master Dec 9, 2015
@alexcrichton alexcrichton deleted the panic-recover branch December 10, 2015 23:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants