Tracking issue for `recover` stabilization #27719

Closed
aturon opened this Issue Aug 12, 2015 · 96 comments

Comments

Projects
None yet
@aturon
Member

aturon commented Aug 12, 2015

The recover function is able, on a single thread, to recover from a panic. There are numerous controversies around this API, including the bounds it applies to its closure, its safety, and its location within std. An open RFC seeks to settle these issues and open the door to stabilization.

cc @alexcrichton

alexcrichton added a commit to alexcrichton/rust that referenced this issue Aug 31, 2015

std: Rename thread::catch_panic to panic::recover
This commit is an implementation of [RFC 1236][rfc] which renames the
`thread::catch_panic` function to `panic::recover` while also removing the
`Send` bound (but leaving the `'static` bound).

[rfc]: rust-lang/rfcs#1236

cc #27719

alexcrichton added a commit to alexcrichton/rust that referenced this issue Aug 31, 2015

std: Rename thread::catch_panic to panic::recover
This commit is an implementation of [RFC 1236][rfc] which renames the
`thread::catch_panic` function to `panic::recover` while also removing the
`Send` bound (but leaving the `'static` bound).

[rfc]: rust-lang/rfcs#1236

cc #27719
@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 16, 2015

Contributor

I’m playing with making Python bindings for a Rust library, and I got some segfaults when a Rust panic tried to unwind into the Python interpreter’s call stack. I understand that using catch_panic at the FFI boundary is the right thing to do, but what should I do with an Err result? I can establish conventions so that the other side triggers a Python exception, but I’d like to have some more helpful information in it than "Something bad happened somewhere". At least (a string representation of) the message that was given to panic!, ideally also a back trace of the unwinded stack frames.

catch_panic returns Result<T, Box<Any + Send + 'static>>, but Any is not very helpful here. It implements Debug, but that impl only prints "Any" (literally), which isn’t that helpful.

@wycats, how do you deal with panics in Rust-inside-Ruby?

Contributor

SimonSapin commented Sep 16, 2015

I’m playing with making Python bindings for a Rust library, and I got some segfaults when a Rust panic tried to unwind into the Python interpreter’s call stack. I understand that using catch_panic at the FFI boundary is the right thing to do, but what should I do with an Err result? I can establish conventions so that the other side triggers a Python exception, but I’d like to have some more helpful information in it than "Something bad happened somewhere". At least (a string representation of) the message that was given to panic!, ideally also a back trace of the unwinded stack frames.

catch_panic returns Result<T, Box<Any + Send + 'static>>, but Any is not very helpful here. It implements Debug, but that impl only prints "Any" (literally), which isn’t that helpful.

@wycats, how do you deal with panics in Rust-inside-Ruby?

@abonander

This comment has been minimized.

Show comment
Hide comment
@abonander

abonander Oct 3, 2015

Contributor

@SimonSapin Looking at the guts of unwinding, Box<Any + Send + 'static> is always going to either be String (if panic!() had formatting arguments) or &'static str (if panic!() was invoked with just a string literal), so you basically downcast it to one, and if that fails you can probably assume it's the other.

I agree, though, the type could be a lot more informative here.

Contributor

abonander commented Oct 3, 2015

@SimonSapin Looking at the guts of unwinding, Box<Any + Send + 'static> is always going to either be String (if panic!() had formatting arguments) or &'static str (if panic!() was invoked with just a string literal), so you basically downcast it to one, and if that fails you can probably assume it's the other.

I agree, though, the type could be a lot more informative here.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Oct 3, 2015

Contributor

Yeah, I ended up finding this code: https://github.com/rust-lang/rust/blob/d2047bc97d/src/libstd/panicking.rs#L33-L39 , but it’s not very discoverable. And though String and &'static str are the most common cases, panic!() with a single argument can take any type:

SimonSapin: panic!(4)
playbot: thread '<main>' panicked at 'Box<Any>', <anon>:9
playbot: playpen: application terminated with error code 101

So I wanted to propose changing from this (in std::thread):

type Result<T> = Result<T, Box<Any + Send + 'static>>;

to this:

type Result<T> = Result<T, PanicValue>;
struct PanicValue(Box<Any + Send + 'static>);
impl PanicValue {
    fn as_str(&self) -> Option<&str> {
        match self.0.downcast_ref::<&'static str>() {
            Some(s) => Some(*s),
            None => match self.0.downcast_ref::<String>() {
                Some(s) => Some(&s[..]),
                None => None,
            }
        }
    }
}

… but std::thread::Result is already stable :(

Contributor

SimonSapin commented Oct 3, 2015

Yeah, I ended up finding this code: https://github.com/rust-lang/rust/blob/d2047bc97d/src/libstd/panicking.rs#L33-L39 , but it’s not very discoverable. And though String and &'static str are the most common cases, panic!() with a single argument can take any type:

SimonSapin: panic!(4)
playbot: thread '<main>' panicked at 'Box<Any>', <anon>:9
playbot: playpen: application terminated with error code 101

So I wanted to propose changing from this (in std::thread):

type Result<T> = Result<T, Box<Any + Send + 'static>>;

to this:

type Result<T> = Result<T, PanicValue>;
struct PanicValue(Box<Any + Send + 'static>);
impl PanicValue {
    fn as_str(&self) -> Option<&str> {
        match self.0.downcast_ref::<&'static str>() {
            Some(s) => Some(*s),
            None => match self.0.downcast_ref::<String>() {
                Some(s) => Some(&s[..]),
                None => None,
            }
        }
    }
}

… but std::thread::Result is already stable :(

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Oct 3, 2015

Contributor

Would this as_str belong as a default method on the Any trait?

Contributor

SimonSapin commented Oct 3, 2015

Would this as_str belong as a default method on the Any trait?

@abonander

This comment has been minimized.

Show comment
Hide comment
@abonander

abonander Oct 3, 2015

Contributor

Why not have impl Debug for Any (+ Send) test for the value being String or &'static str before printing "Any"? It would add negligible overhead, and I don't think anyone should be relying on the exact value it prints. Right now, it's pretty much useless anyways.

In fact, why not cover all the primitives (except obviously &[T], *const T, *mut T, etc)?

Contributor

abonander commented Oct 3, 2015

Why not have impl Debug for Any (+ Send) test for the value being String or &'static str before printing "Any"? It would add negligible overhead, and I don't think anyone should be relying on the exact value it prints. Right now, it's pretty much useless anyways.

In fact, why not cover all the primitives (except obviously &[T], *const T, *mut T, etc)?

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 19, 2015

std: Rename thread::catch_panic to panic::recover
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 19, 2015

std: Rename thread::catch_panic to panic::recover
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 19, 2015

std: Rename thread::catch_panic to panic::recover
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 20, 2015

std: Rename thread::catch_panic to panic::recover
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Nov 20, 2015

std: Rename thread::catch_panic to panic::recover
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
@alexchandel

This comment has been minimized.

Show comment
Hide comment
@alexchandel

alexchandel Dec 2, 2015

Why are we making it easier to use and abuse panics, instead of removing inappropriate ones from the standard library?

Why are we making it easier to use and abuse panics, instead of removing inappropriate ones from the standard library?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Dec 2, 2015

Contributor

@alexchandel Even if you don’t choose to use panics, it’s very hard to be 100% sure that a non-trivial program will not panic ever. (Similar to being 100% sure that it doesn’t have any bug.) And since unwinding through an FFI boundary can be undefined behavior, something like catch_panic is necessary at least to protect against that.

Contributor

SimonSapin commented Dec 2, 2015

@alexchandel Even if you don’t choose to use panics, it’s very hard to be 100% sure that a non-trivial program will not panic ever. (Similar to being 100% sure that it doesn’t have any bug.) And since unwinding through an FFI boundary can be undefined behavior, something like catch_panic is necessary at least to protect against that.

@steveklabnik

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Dec 2, 2015

Member

Why are we making it easier to use and abuse panics,

There is a whole "Motivations" section of the related RFC which describes this https://github.com/alexcrichton/rfcs/blob/stabilize-catch-panic/text/0000-stabilize-catch-panic.md#motivation

Member

steveklabnik commented Dec 2, 2015

Why are we making it easier to use and abuse panics,

There is a whole "Motivations" section of the related RFC which describes this https://github.com/alexcrichton/rfcs/blob/stabilize-catch-panic/text/0000-stabilize-catch-panic.md#motivation

alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 5, 2015

std: Rename thread::catch_panic to panic::recover
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 5, 2015

std: Rename thread::catch_panic to panic::recover
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 5, 2015

std: Rename thread::catch_panic to panic::recover
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 8, 2015

std: Rename thread::catch_panic to panic::recover
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 added a commit that referenced this issue Dec 8, 2015

Auto merge of #29937 - alexcrichton:panic-recover, r=aturon
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 8, 2015

std: Rename thread::catch_panic to panic::recover
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 added a commit that referenced this issue Dec 8, 2015

Auto merge of #29937 - alexcrichton:panic-recover, r=aturon
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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 9, 2015

std: Rename thread::catch_panic to panic::recover
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 added a commit that referenced this issue Dec 9, 2015

Auto merge of #29937 - alexcrichton:panic-recover, r=alexcrichton
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

michaelwoerister added a commit to michaelwoerister/rust that referenced this issue Dec 10, 2015

std: Rename thread::catch_panic to panic::recover
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
@e-oz

This comment has been minimized.

Show comment
Hide comment
@e-oz

e-oz Jan 2, 2016

About panic::recover: need of Mutexes is limiting usage of this new feature very much. Or you can share resources between threads (without making whole program single-threaded by Mutex), or you can use panic::recover.

e-oz commented Jan 2, 2016

About panic::recover: need of Mutexes is limiting usage of this new feature very much. Or you can share resources between threads (without making whole program single-threaded by Mutex), or you can use panic::recover.

@abonander

This comment has been minimized.

Show comment
Hide comment
@abonander

abonander Jan 2, 2016

Contributor

@e-oz Why would you need a Mutex? You can use any cell type if you know the interior data won't be corrupted by a caught panic. The AssertRecoverSafe wrapper was designed for exactly that.

Contributor

abonander commented Jan 2, 2016

@e-oz Why would you need a Mutex? You can use any cell type if you know the interior data won't be corrupted by a caught panic. The AssertRecoverSafe wrapper was designed for exactly that.

@e-oz

This comment has been minimized.

Show comment
Hide comment
@abonander

This comment has been minimized.

Show comment
Hide comment
@abonander

abonander Jan 2, 2016

Contributor

@e-oz That merely explains the difference between RefCell and Mutex when talking about recover-safety. RefCell wasn't designed with poisoning because it's usually not possible to access it after a panic, and it'd be a breaking change to add it now. Those same docs mention AssertRecoverSafe in a later paragraph for use when you either don't care about recover-safety or can guarantee it yourself.

Contributor

abonander commented Jan 2, 2016

@e-oz That merely explains the difference between RefCell and Mutex when talking about recover-safety. RefCell wasn't designed with poisoning because it's usually not possible to access it after a panic, and it'd be a breaking change to add it now. Those same docs mention AssertRecoverSafe in a later paragraph for use when you either don't care about recover-safety or can guarantee it yourself.

@e-oz

This comment has been minimized.

Show comment
Hide comment
@e-oz

e-oz Jan 2, 2016

@CyberGeek marker trait will just disallow to use without Mutexes.

e-oz commented Jan 2, 2016

@CyberGeek marker trait will just disallow to use without Mutexes.

@abonander

This comment has been minimized.

Show comment
Hide comment
@abonander

abonander Jan 2, 2016

Contributor

@e-oz You can wrap your type in AssertRecoverSafe or manually implement RecoverSafe and RefRecoverSafe for it if it uses some RefCell internally but won't have logic problems if it sees a panic and continues being used.

You can also put an &mut reference in an AssertRecoverSafe if you want to mutate your type within the closure, as mutable references aren't generally recover-safe.

These new marker traits aren't enforced like Copy is, where you can't manually implement it unless your contained types are Copy, nor are they unsafe like Send or Sync. Bypassing them won't (or shouldn't) create the risk of undefined-behavior; they're just to help prevent users from unknowingly introducing really frustrating bugs in their code.

Contributor

abonander commented Jan 2, 2016

@e-oz You can wrap your type in AssertRecoverSafe or manually implement RecoverSafe and RefRecoverSafe for it if it uses some RefCell internally but won't have logic problems if it sees a panic and continues being used.

You can also put an &mut reference in an AssertRecoverSafe if you want to mutate your type within the closure, as mutable references aren't generally recover-safe.

These new marker traits aren't enforced like Copy is, where you can't manually implement it unless your contained types are Copy, nor are they unsafe like Send or Sync. Bypassing them won't (or shouldn't) create the risk of undefined-behavior; they're just to help prevent users from unknowingly introducing really frustrating bugs in their code.

@e-oz

This comment has been minimized.

Show comment
Hide comment
@e-oz

e-oz Jan 2, 2016

@cybergeek94

These new marker traits aren't enforced like Copy is, where you can't manually implement it unless your contained types are Copy

After reading docs (in comments) I think it's indeed enforced:

a struct is recover safe if all of its components are recover safe

michaelwoerister@f899ea9#diff-f0a475ebd45e8b84e91e006a89b8c321R70

And I really hope I just don't understand something and you are right and we will be able to use panic::recover AND shared resources (with multithreading).

e-oz commented Jan 2, 2016

@cybergeek94

These new marker traits aren't enforced like Copy is, where you can't manually implement it unless your contained types are Copy

After reading docs (in comments) I think it's indeed enforced:

a struct is recover safe if all of its components are recover safe

michaelwoerister@f899ea9#diff-f0a475ebd45e8b84e91e006a89b8c321R70

And I really hope I just don't understand something and you are right and we will be able to use panic::recover AND shared resources (with multithreading).

bors added a commit that referenced this issue Mar 10, 2016

Auto merge of #32102 - alexcrichton:assert-safe-closures, r=aturon
std: Add impl of FnOnce to AssertRecoverSafe

This was originally intended, but forgot to land by accident!

cc #27719

bors added a commit that referenced this issue Mar 11, 2016

Auto merge of #32102 - alexcrichton:assert-safe-closures, r=aturon
std: Add impl of FnOnce to AssertRecoverSafe

This was originally intended, but forgot to land by accident!

cc #27719
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Mar 11, 2016

Member

🔔 This issue is now entering its cycle-long final comment period for stabilization in 1.9 🔔

With the recent addition of FnOnce to AssertRecoverSafe there's consensus among the libs team that the ergonomics here are good enough that we're willing to stabilize this. It may still be the case that we can remove these bounds one day, but that's an API-wise backwards-compatible change that can be made (and isn't currently planned).

This cycle we'd like to stabilize both the bounds and the function at hand. There wasn't complete consensus about the name "recover", but it was pointed out that with the bounds remaining we likely don't need the syntactic salt of a long function name. Overall we didn't quite reach a conclusion for a recommendation for the name, but we figured that FCP could duke it out!

Member

alexcrichton commented Mar 11, 2016

🔔 This issue is now entering its cycle-long final comment period for stabilization in 1.9 🔔

With the recent addition of FnOnce to AssertRecoverSafe there's consensus among the libs team that the ergonomics here are good enough that we're willing to stabilize this. It may still be the case that we can remove these bounds one day, but that's an API-wise backwards-compatible change that can be made (and isn't currently planned).

This cycle we'd like to stabilize both the bounds and the function at hand. There wasn't complete consensus about the name "recover", but it was pointed out that with the bounds remaining we likely don't need the syntactic salt of a long function name. Overall we didn't quite reach a conclusion for a recommendation for the name, but we figured that FCP could duke it out!

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Mar 11, 2016

Member

A bit more detail from the lengthy discussion we had:

  • With the new FnOnce impl, the API here is very much like a kind of custom unsafe marker -- you always have the option of simply wrapping the whole closure with AssertRecoverSafe. Thus, we have a clear but ergonomic audit marker, with a very clear separation from unsafe (and the hard guarantees connected with that).
  • Naming-wise, with the advent of abort-on-panic, the panic mechanism is now wholly about dealing with contract violations/assertion failures, and not intrinsically tied to unwinding. This API (as well as propagate), however, is intrinsically tied to unwinding. Therefore, we'd like unwinding to play some role in the naming, either directly in the function name, or perhaps by introducing an unwind submodule in std::panic to clarify the relationship.
Member

aturon commented Mar 11, 2016

A bit more detail from the lengthy discussion we had:

  • With the new FnOnce impl, the API here is very much like a kind of custom unsafe marker -- you always have the option of simply wrapping the whole closure with AssertRecoverSafe. Thus, we have a clear but ergonomic audit marker, with a very clear separation from unsafe (and the hard guarantees connected with that).
  • Naming-wise, with the advent of abort-on-panic, the panic mechanism is now wholly about dealing with contract violations/assertion failures, and not intrinsically tied to unwinding. This API (as well as propagate), however, is intrinsically tied to unwinding. Therefore, we'd like unwinding to play some role in the naming, either directly in the function name, or perhaps by introducing an unwind submodule in std::panic to clarify the relationship.
@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Mar 12, 2016

Contributor

On Fri, Mar 11, 2016 at 10:16:55AM -0800, Alex Crichton wrote:

This cycle we'd like to stabilize both the bounds and the function at hand. There wasn't complete consensus about the name "recover", but it was pointed out that with the bounds remaining we likely don't need the syntactic salt of a long function name. Overall we didn't quite reach a conclusion for a recommendation for the name, but we figured that FCP could duke it out!

I feel like there are two things arguably wrong with the name 'recover':

  • it doesn't indicate unwinding;
  • many (if not most) callers are not "recovering" but rather "propagating".

I wonder if halt_unwinding would be a better name? It certainly
tells you just what it does.

Contributor

nikomatsakis commented Mar 12, 2016

On Fri, Mar 11, 2016 at 10:16:55AM -0800, Alex Crichton wrote:

This cycle we'd like to stabilize both the bounds and the function at hand. There wasn't complete consensus about the name "recover", but it was pointed out that with the bounds remaining we likely don't need the syntactic salt of a long function name. Overall we didn't quite reach a conclusion for a recommendation for the name, but we figured that FCP could duke it out!

I feel like there are two things arguably wrong with the name 'recover':

  • it doesn't indicate unwinding;
  • many (if not most) callers are not "recovering" but rather "propagating".

I wonder if halt_unwinding would be a better name? It certainly
tells you just what it does.

@glaebhoerl

This comment has been minimized.

Show comment
Hide comment
@glaebhoerl

glaebhoerl Mar 12, 2016

Contributor

Would AssertRecoverSafe then also be called AssertHaltUnwindingSafe?

Contributor

glaebhoerl commented Mar 12, 2016

Would AssertRecoverSafe then also be called AssertHaltUnwindingSafe?

@Amanieu

This comment has been minimized.

Show comment
Hide comment
@Amanieu

Amanieu Mar 12, 2016

Contributor

I think catch_unwind and AssertUnwindSafe would make the most sense. The fundamental operation here is halting unwinding and every other language calls it "catch". I don't think we should invent a new term for such a well known operation.

Contributor

Amanieu commented Mar 12, 2016

I think catch_unwind and AssertUnwindSafe would make the most sense. The fundamental operation here is halting unwinding and every other language calls it "catch". I don't think we should invent a new term for such a well known operation.

@wthrowe

This comment has been minimized.

Show comment
Hide comment
@wthrowe

wthrowe Mar 12, 2016

Contributor

My concern with the current bounds is still less with anything about the API itself than with the fact that this changes the rather strange nature of rustc's OIBIT handling (#27554) from something that was probably rarely encountered in practice to something exposed in a stable API in the standard library. This is going to make changing the OIBIT semantics without breaking the world really hard, and I don't think enough thought has been put into the current form to make locking the language into it desirable.

Contributor

wthrowe commented Mar 12, 2016

My concern with the current bounds is still less with anything about the API itself than with the fact that this changes the rather strange nature of rustc's OIBIT handling (#27554) from something that was probably rarely encountered in practice to something exposed in a stable API in the standard library. This is going to make changing the OIBIT semantics without breaking the world really hard, and I don't think enough thought has been put into the current form to make locking the language into it desirable.

@diwic

This comment has been minimized.

Show comment
Hide comment
@diwic

diwic Mar 13, 2016

Contributor

Naming

I would refrain from using "unwind": It's not currently exposed in the stdlib, and also, it could mean "to relax", which is the opposite of panicking, really :-) And if "catch" is undesirable (I don't remember exactly why) then maybe std::panic::capture could be an option? And std::panic::release to re-throw the panic. E g, consider a herd of panicking animals, which you capture in a cage, move them safely over some boundary, and then release them so they panic wildly again. RecoverSafe then becomes either std::panic::CaptureSafe or possibly just std::panic::Safe.

PanicInfo

The panic handlers added the PanicInfo struct, and recover/propagate has been some kind of parallel process. It would be nice if this API could be a little more consistent, so that recover would actually return a panicinfo somehow, and propagate allowed to take one as a parameter. I'm not exactly sure if this means redesigning PanicInfo, so I'm just going to leave that as a thought for now.

Landing pads for extern fn

I was wondering if we need an abort-on-panic landing pad on extern fns. Even with this interface stablized, the code is going to end up like:

extern fn callback_from_c( /* ... */ ) -> /* ... */ {
    let r = std::panic::capture(|| /* some complicated handling */ );
    if r.is_err() { /* convert to some sort of error */ }
}

...it's going to be hard to guarantee to 100% that the "convert to some sort of error" part is never going to panic. Since we don't want UB, maybe we need to insert an abort-on-panic landing pad as part of all extern fn?

Contributor

diwic commented Mar 13, 2016

Naming

I would refrain from using "unwind": It's not currently exposed in the stdlib, and also, it could mean "to relax", which is the opposite of panicking, really :-) And if "catch" is undesirable (I don't remember exactly why) then maybe std::panic::capture could be an option? And std::panic::release to re-throw the panic. E g, consider a herd of panicking animals, which you capture in a cage, move them safely over some boundary, and then release them so they panic wildly again. RecoverSafe then becomes either std::panic::CaptureSafe or possibly just std::panic::Safe.

PanicInfo

The panic handlers added the PanicInfo struct, and recover/propagate has been some kind of parallel process. It would be nice if this API could be a little more consistent, so that recover would actually return a panicinfo somehow, and propagate allowed to take one as a parameter. I'm not exactly sure if this means redesigning PanicInfo, so I'm just going to leave that as a thought for now.

Landing pads for extern fn

I was wondering if we need an abort-on-panic landing pad on extern fns. Even with this interface stablized, the code is going to end up like:

extern fn callback_from_c( /* ... */ ) -> /* ... */ {
    let r = std::panic::capture(|| /* some complicated handling */ );
    if r.is_err() { /* convert to some sort of error */ }
}

...it's going to be hard to guarantee to 100% that the "convert to some sort of error" part is never going to panic. Since we don't want UB, maybe we need to insert an abort-on-panic landing pad as part of all extern fn?

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Mar 14, 2016

Contributor

On Sat, Mar 12, 2016 at 12:13:56PM -0800, wthrowe wrote:

My concern with the current bounds is still less with anything about the API itself than with the fact that this changes the rather strange nature of rustc's OIBIT handling (#27554) from something that was probably rarely encountered in practice to something exposed in a stable API in the standard library.

I think the most prominent use of auto traits (aka OIBIT) is Send
and Sync, not this relatively obscure function.

This is going to make changing the OIBIT semantics without breaking the world really hard, and I don't think enough thought has been put into the current form to make locking the language into it desirable.

I am not sure what changes you are describing (there are none in the
works that I am aware of, just clarifications -- most of which in fact
behave the same as the current implementation), but as I said, I would
expect the real problem for compatibility with any change is going to
be Send and Sync!

Contributor

nikomatsakis commented Mar 14, 2016

On Sat, Mar 12, 2016 at 12:13:56PM -0800, wthrowe wrote:

My concern with the current bounds is still less with anything about the API itself than with the fact that this changes the rather strange nature of rustc's OIBIT handling (#27554) from something that was probably rarely encountered in practice to something exposed in a stable API in the standard library.

I think the most prominent use of auto traits (aka OIBIT) is Send
and Sync, not this relatively obscure function.

This is going to make changing the OIBIT semantics without breaking the world really hard, and I don't think enough thought has been put into the current form to make locking the language into it desirable.

I am not sure what changes you are describing (there are none in the
works that I am aware of, just clarifications -- most of which in fact
behave the same as the current implementation), but as I said, I would
expect the real problem for compatibility with any change is going to
be Send and Sync!

@bstrie

This comment has been minimized.

Show comment
Hide comment
@bstrie

bstrie Mar 21, 2016

Contributor

I'm happy to see the progress here, and just as happy that we've managed to smooth over the ergonomics without throwing out the bounds entirely.

Unsurprisingly, I'm +1 to a more descriptive name than "recover". This topic comes up so much in the wild that we're going to be perpetually fielding responses to questions like "why does Rust now have exceptions?" and having self-explanatory naming would make that so much less tedious.

To reiterate:

  1. "recover" isn't good because recovery isn't really what's happening here, and we especially don't want people to think that we intend recovery to be what this is used for.
  2. "catch" is even worse because of the conflation with exceptions mentioned above. This mechanism is not intended for the same task as an exception handler is, and we overwhelmingly resist the notion that it should be used that way. This isn't as catastrophically bad of a name as it used to be now that the bounds are remaining, but it's still going to make my job much harder (and that includes variants like catch_unwind).
  3. Name should contain "unwind" because that's presumably the accepted terminology that we'll be using in manual and guides referring to this feature, as well as in documents that discuss panics in general.

I like @nikomatsakis 's halt_unwind and @alexcrichton 's prevent_unwind out of the options presented so far, and @Amanieu 's AssertUnwindSafe.

Contributor

bstrie commented Mar 21, 2016

I'm happy to see the progress here, and just as happy that we've managed to smooth over the ergonomics without throwing out the bounds entirely.

Unsurprisingly, I'm +1 to a more descriptive name than "recover". This topic comes up so much in the wild that we're going to be perpetually fielding responses to questions like "why does Rust now have exceptions?" and having self-explanatory naming would make that so much less tedious.

To reiterate:

  1. "recover" isn't good because recovery isn't really what's happening here, and we especially don't want people to think that we intend recovery to be what this is used for.
  2. "catch" is even worse because of the conflation with exceptions mentioned above. This mechanism is not intended for the same task as an exception handler is, and we overwhelmingly resist the notion that it should be used that way. This isn't as catastrophically bad of a name as it used to be now that the bounds are remaining, but it's still going to make my job much harder (and that includes variants like catch_unwind).
  3. Name should contain "unwind" because that's presumably the accepted terminology that we'll be using in manual and guides referring to this feature, as well as in documents that discuss panics in general.

I like @nikomatsakis 's halt_unwind and @alexcrichton 's prevent_unwind out of the options presented so far, and @Amanieu 's AssertUnwindSafe.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Mar 24, 2016

Member

@pnkfelix semi-jokingly proposes recoil :)

Member

aturon commented Mar 24, 2016

@pnkfelix semi-jokingly proposes recoil :)

@glaebhoerl

This comment has been minimized.

Show comment
Hide comment
@glaebhoerl

glaebhoerl Mar 25, 2016

Contributor

what about "intercept"?

Contributor

glaebhoerl commented Mar 25, 2016

what about "intercept"?

twittner added a commit to wireapp/cryptobox-c that referenced this issue Mar 29, 2016

Replace `catch_panic` with `recover`.
`catch_panic` is no longer available in rust nightly. Instead `recover`
has been proposed [1] and is available behind a feature gate in nightly,
beta and stable [2]. This commit transitions from `catch_panic` to `panic`.

---
[1] rust-lang/rust#27719
[2] http://doc.rust-lang.org/std/panic/fn.recover.html

@twittner twittner referenced this issue in wireapp/cryptobox-c Mar 29, 2016

Merged

Replace `catch_panic` with `recover`. #3

@abonander

This comment has been minimized.

Show comment
Hide comment
@abonander

abonander Apr 5, 2016

Contributor

Looks like the discussion is still open for a name so I'll throw out a few ideas. This thread's a little long and these are somewhat generic so it's a little too tedious this late at night to Ctrl-F to see if any of them have already been mentioned, so bear with me.

recover->

  • guard (like guard_from_unwinding but not intentionally unwieldy)
  • barrier (panic::barrier is pretty descriptive, methinks)
  • contain (like containing a panicked crowd or herd of animals)
  • sequester (if you're feeling pretentious)

propagate->

  • Keep it? It's pretty self-explanatory.
  • release (I know this one's already been mentioned but it parallels well with contain)
  • resume (heavily implies continuation of a previously caught panic, which I think is generally desired)

I kind of agree with the abort landing pads in extern fn, though it should be trivial to disable them so the people who do their homework and use recover (or what-have-you) properly don't have pay for them. I'm thinking a function attribute, like #[recover_safe] so that it's right next to documentation explaining how panics are handled properly. Or maybe, like integer overflow traps, they should only be emitted in debug builds. It could also be a lint that warns whenever possibly fallible operations are undertaken, namely calling into non-extern functions and methods, but only once per extern fn.

Contributor

abonander commented Apr 5, 2016

Looks like the discussion is still open for a name so I'll throw out a few ideas. This thread's a little long and these are somewhat generic so it's a little too tedious this late at night to Ctrl-F to see if any of them have already been mentioned, so bear with me.

recover->

  • guard (like guard_from_unwinding but not intentionally unwieldy)
  • barrier (panic::barrier is pretty descriptive, methinks)
  • contain (like containing a panicked crowd or herd of animals)
  • sequester (if you're feeling pretentious)

propagate->

  • Keep it? It's pretty self-explanatory.
  • release (I know this one's already been mentioned but it parallels well with contain)
  • resume (heavily implies continuation of a previously caught panic, which I think is generally desired)

I kind of agree with the abort landing pads in extern fn, though it should be trivial to disable them so the people who do their homework and use recover (or what-have-you) properly don't have pay for them. I'm thinking a function attribute, like #[recover_safe] so that it's right next to documentation explaining how panics are handled properly. Or maybe, like integer overflow traps, they should only be emitted in debug builds. It could also be a lint that warns whenever possibly fallible operations are undertaken, namely calling into non-extern functions and methods, but only once per extern fn.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 5, 2016

Member

So far the front-runner in terms of naming to me is catch_unwind as it invokes both the idea that something is being caught but only unwinds as it won't catch panics-as-aborts. The verb "catch" seems interchangeable to me, so something like guard_unwind also seems fine.

For the propagation function, I'd expect something similar like continue_unwind or resume_unwind which clearly indicates that it's only intended for unwinding and isn't useful in a panics-as-aborts world.

Member

alexcrichton commented Apr 5, 2016

So far the front-runner in terms of naming to me is catch_unwind as it invokes both the idea that something is being caught but only unwinds as it won't catch panics-as-aborts. The verb "catch" seems interchangeable to me, so something like guard_unwind also seems fine.

For the propagation function, I'd expect something similar like continue_unwind or resume_unwind which clearly indicates that it's only intended for unwinding and isn't useful in a panics-as-aborts world.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Apr 5, 2016

Member

I like catch_unwind and resume_unwind unwind personally.

It is worth noting, though, that resume_unwind can still be called in an panic-as-aborts context, it'll just abort without running the panic hook. I don't really think that's too big of a deal though.

Member

sfackler commented Apr 5, 2016

I like catch_unwind and resume_unwind unwind personally.

It is worth noting, though, that resume_unwind can still be called in an panic-as-aborts context, it'll just abort without running the panic hook. I don't really think that's too big of a deal though.

@huonw

This comment has been minimized.

Show comment
Hide comment
@huonw

huonw Apr 6, 2016

Member

When considering names, the module path is relevant because functions are typically called via it. Things like panic::catch_unwind seem awkward to me: it's three verbs in a row.

Returning #27719 (comment), particularly its suggestion of introducing a submodule to std::panic, unwind::catch_unwind is bad, but maybe unwind::catch is OK? (Modulo the negative connotations of the catch word, of course, and the possibility that catch will become a keyword.)

Member

huonw commented Apr 6, 2016

When considering names, the module path is relevant because functions are typically called via it. Things like panic::catch_unwind seem awkward to me: it's three verbs in a row.

Returning #27719 (comment), particularly its suggestion of introducing a submodule to std::panic, unwind::catch_unwind is bad, but maybe unwind::catch is OK? (Modulo the negative connotations of the catch word, of course, and the possibility that catch will become a keyword.)

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Apr 6, 2016

Member

Like @sfackler, I prefer catch_unwind and resume_unwind, scoped directly in the panic module, rather than introducing a new submodule.

Member

aturon commented Apr 6, 2016

Like @sfackler, I prefer catch_unwind and resume_unwind, scoped directly in the panic module, rather than introducing a new submodule.

@BurntSushi

This comment has been minimized.

Show comment
Hide comment
@BurntSushi

BurntSushi Apr 6, 2016

Member

I think I'm happy as long as unwind is in the name.

Member

BurntSushi commented Apr 6, 2016

I think I'm happy as long as unwind is in the name.

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Apr 6, 2016

Member

I thought the barrier suggestion from @cybergeek94 was good. Especially if we put it into an unwind submodule, yielding unwind::barrier

To me barrier carries the notion that the unwinding will stop here, but there's the hint that you should perhaps trying to "restart it", to keep it going across the boundary introduced by the barrier, if possible, or at least signal that it occurred.


Update: unwind::guard seems okay too, but for some reason I prefer unwind::barrier; not sure why.

Member

pnkfelix commented Apr 6, 2016

I thought the barrier suggestion from @cybergeek94 was good. Especially if we put it into an unwind submodule, yielding unwind::barrier

To me barrier carries the notion that the unwinding will stop here, but there's the hint that you should perhaps trying to "restart it", to keep it going across the boundary introduced by the barrier, if possible, or at least signal that it occurred.


Update: unwind::guard seems okay too, but for some reason I prefer unwind::barrier; not sure why.

@e-oz

This comment has been minimized.

Show comment
Hide comment
@e-oz

e-oz Apr 6, 2016

My vote against "barrier", sounds too non-related to execution flow.

On Wed, 6 Apr 2016 at 22:32, Felix S Klock II notifications@github.com
wrote:

I thought the barrier suggestion from @cybergeek94
https://github.com/cybergeek94 was good. Especially if we put it into
an unwind submodule, yielding unwind::barrier

To me barrier carries the notion that the unwinding will stop here, but
there's the hint that you should perhaps trying to "restart it", to keep it
going across the boundary introduced by the barrier, if possible, or at
least signal that it occurred.


You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#27719 (comment)

e-oz commented Apr 6, 2016

My vote against "barrier", sounds too non-related to execution flow.

On Wed, 6 Apr 2016 at 22:32, Felix S Klock II notifications@github.com
wrote:

I thought the barrier suggestion from @cybergeek94
https://github.com/cybergeek94 was good. Especially if we put it into
an unwind submodule, yielding unwind::barrier

To me barrier carries the notion that the unwinding will stop here, but
there's the hint that you should perhaps trying to "restart it", to keep it
going across the boundary introduced by the barrier, if possible, or at
least signal that it occurred.


You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#27719 (comment)

@tomaka

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka Apr 6, 2016

Contributor

In system programming, barrier usually means "memory barrier", which has nothing to do with unwinding.

Contributor

tomaka commented Apr 6, 2016

In system programming, barrier usually means "memory barrier", which has nothing to do with unwinding.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Apr 7, 2016

Member

The libs team discussed this during triage yesterday and the decision was to stabilize with the following names:

  • recover -> catch_unwind
  • propagate -> resume_unwind
  • AssertRecoverSafe -> AssertUnwindSafe

Thanks again for all the discussion everyone!

Member

alexcrichton commented Apr 7, 2016

The libs team discussed this during triage yesterday and the decision was to stabilize with the following names:

  • recover -> catch_unwind
  • propagate -> resume_unwind
  • AssertRecoverSafe -> AssertUnwindSafe

Thanks again for all the discussion everyone!

@ubsan

This comment has been minimized.

Show comment
Hide comment
@ubsan

ubsan Apr 7, 2016

Contributor

yay :)

Contributor

ubsan commented Apr 7, 2016

yay :)

alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 7, 2016

std: Stabilize APIs for the 1.9 release
This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long "final comment period" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 7, 2016

std: Stabilize APIs for the 1.9 release
This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long "final comment period" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

Manishearth added a commit to Manishearth/rust that referenced this issue Apr 8, 2016

Rollup merge of #32804 - alexcrichton:stabilize-1.9, r=brson
 This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long \"final comment period\" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 8, 2016

std: Stabilize APIs for the 1.9 release
This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long "final comment period" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

bors added a commit that referenced this issue Apr 9, 2016

Auto merge of #32804 - alexcrichton:stabilize-1.9, r=brson
std: Stabilize APIs for the 1.9 release

This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long "final comment period" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 11, 2016

std: Stabilize APIs for the 1.9 release
This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long "final comment period" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

bors added a commit that referenced this issue Apr 12, 2016

Auto merge of #32804 - alexcrichton:stabilize-1.9, r=brson
std: Stabilize APIs for the 1.9 release

This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long "final comment period" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

@bors bors closed this in #32804 Apr 12, 2016

alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 12, 2016

std: Stabilize APIs for the 1.9 release
This commit applies all stabilizations, renamings, and deprecations that the
library team has decided on for the upcoming 1.9 release. All tracking issues
have gone through a cycle-long "final comment period" and the specific APIs
stabilized/deprecated are:

Stable

* `std::panic`
* `std::panic::catch_unwind` (renamed from `recover`)
* `std::panic::resume_unwind` (renamed from `propagate`)
* `std::panic::AssertUnwindSafe` (renamed from `AssertRecoverSafe`)
* `std::panic::UnwindSafe` (renamed from `RecoverSafe`)
* `str::is_char_boundary`
* `<*const T>::as_ref`
* `<*mut T>::as_ref`
* `<*mut T>::as_mut`
* `AsciiExt::make_ascii_uppercase`
* `AsciiExt::make_ascii_lowercase`
* `char::decode_utf16`
* `char::DecodeUtf16`
* `char::DecodeUtf16Error`
* `char::DecodeUtf16Error::unpaired_surrogate`
* `BTreeSet::take`
* `BTreeSet::replace`
* `BTreeSet::get`
* `HashSet::take`
* `HashSet::replace`
* `HashSet::get`
* `OsString::with_capacity`
* `OsString::clear`
* `OsString::capacity`
* `OsString::reserve`
* `OsString::reserve_exact`
* `OsStr::is_empty`
* `OsStr::len`
* `std::os::unix::thread`
* `RawPthread`
* `JoinHandleExt`
* `JoinHandleExt::as_pthread_t`
* `JoinHandleExt::into_pthread_t`
* `HashSet::hasher`
* `HashMap::hasher`
* `CommandExt::exec`
* `File::try_clone`
* `SocketAddr::set_ip`
* `SocketAddr::set_port`
* `SocketAddrV4::set_ip`
* `SocketAddrV4::set_port`
* `SocketAddrV6::set_ip`
* `SocketAddrV6::set_port`
* `SocketAddrV6::set_flowinfo`
* `SocketAddrV6::set_scope_id`
* `<[T]>::copy_from_slice`
* `ptr::read_volatile`
* `ptr::write_volatile`
* The `#[deprecated]` attribute
* `OpenOptions::create_new`

Deprecated

* `std::raw::Slice` - use raw parts of `slice` module instead
* `std::raw::Repr` - use raw parts of `slice` module instead
* `str::char_range_at` - use slicing plus `chars()` plus `len_utf8`
* `str::char_range_at_reverse` - use slicing plus `chars().rev()` plus `len_utf8`
* `str::char_at` - use slicing plus `chars()`
* `str::char_at_reverse` - use slicing plus `chars().rev()`
* `str::slice_shift_char` - use `chars()` plus `Chars::as_str`
* `CommandExt::session_leader` - use `before_exec` instead.

Closes #27719
cc #27751 (deprecating the `Slice` bits)
Closes #27754
Closes #27780
Closes #27809
Closes #27811
Closes #27830
Closes #28050
Closes #29453
Closes #29791
Closes #29935
Closes #30014
Closes #30752
Closes #31262
cc #31398 (still need to deal with `before_exec`)
Closes #31405
Closes #31572
Closes #31755
Closes #31756

@est31 est31 referenced this issue in rust-lang/rfcs Sep 10, 2016

Closed

Longer question marks RFC #1737

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment