std: Stabilize the catch_panic feature

[alexcrichton]

This function has remained in std for quite some time now without modifications,
and it's a core building block for robust FFI, so this commit stabilizes the
signature as-is.

It is possible to relax the Send or 'static bounds in the future
additionally.

Closes #25662

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Although not currently done, I'd like to update the release notes if we decide to merge this, and I'd also be fine backporting this to 1.2, but I don't feel a great sense of urgency to do so.

[Gankra]

Are there any known problems or drawbacks to this design?
On Jun 21, 2015 9:11 PM, "Alex Crichton" notifications@github.com wrote:

Although not currently done, I'd like to update the release notes if we
decide to merge this, and I'd also be fine backporting this to 1.2, but I
don't feel a great sense of urgency to do so.

—
Reply to this email directly or view it on GitHub
#26492 (comment).

[alexcrichton]

Are there any known problems or drawbacks to this design?

#25662 points out that TLS can be used to subvert the Send and 'static bounds here, and those two bounds are also somewhat arbitrary and can perhaps be too restrictive. Apart from that, though, I'm unaware of any known issues with the current API.

[dgrunwald]

If a panic occurs while a mutable borrow exists, currently only Drop implementations have to worry about seeing an inconsistent state ("panic safety").

The combination of catch_panic + TLS + RefCell allows using an object even after a panic occurred in a mutating operation.
Does this mean all other Rust code now has to worry about panic safety, too? Or do we require that types like RefCell use poisoning?

In the latter case, the 'static bound is still necessary to prevent mutating objects that remain accessible after the panic was caught. The Send bound seems unnecessary in both cases.

From the point of view of FFI callbacks (the primary consumer of this API): the 'static bound is harmless as the FFI interface is dealing with raw pointers. But the Send bound is annoying, given that raw pointers don't directly implement Send. The easiest fix would be to create my high-level wrapper type around the raw pointer before using catch_panic, but that means I get undefined behavior if the constructor function of the wrapper type panics...

Also, rt::unwind is still documented as "This is not safe to call in a nested fashion.". Is that just outdated documentation, or is it undefined behavior to nest catch_panic calls?

[sfackler]

@dgrunwald I believe the discussion in #25662 covers that question.

[alexcrichton]

After some more discussion at the work week I think we're going to want to make some more changes here, so I'm going to close this in favor of an upcoming RFC.