rust-lang · BatmanAoD · Aug 29, 2019 · Aug 29, 2019 · Aug 29, 2019 · Aug 29, 2019
diff --git a/text/0000-simple_unwind_annotation.md b/text/0000-simple_unwind_annotation.md
@@ -0,0 +1,78 @@
+- Feature Name: `simple_unwind_attribute`
+- Start Date: 2019-08-29
+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)
+
+# Summary
+[summary]: #summary
+
+Provides an annotation to permit functions with explicit ABI specifications
+(such as `extern "C"`) to unwind
+
+# Motivation
+[motivation]: #motivation
+
+TODO
+
+- soundness & optimization
+- libjpeg/mozjpeg
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+The `#[unwind(allowed)]` attribute permits functions with non-Rust ABIs (e.g. `extern "C" fn`) to unwind rather than terminating the process.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+By default, Rust assumes that an external function imported with `extern "C" {
+... }` (or another ABI other than `"Rust"`) cannot unwind, and Rust will abort if a panic would propagate out of a
+Rust function with a non-"Rust" ABI ("`extern "ABI" fn`") specification. If you specify
+the `#[unwind(allowed)]` attribute on a function with a non-"Rust" ABI, Rust
+will instead allow an unwind (such as a panic) to proceed through that function
+boundary using Rust's normal unwind mechanism. This may potentially allow Rust
+code to call non-Rust code that calls back into Rust code, and then allow a
+panic to propagate from Rust to Rust across the non-Rust code.
+
+The Rust unwind mechanism is intentionally not specified here. Catching a Rust
+panic in Rust code compiled with a different Rust toolchain or options is not
+specified. Catching a Rust panic in another language or vice versa is not
+specified. The Rust unwind may or may not run non-Rust destructors as it
+unwinds. Propagating a Rust panic through non-Rust code is unspecified;
+implementations that define the behavior may require target-specific options
+for the non-Rust code, or this feature may not be supported at all.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+- Only works as long as Rust uses the same unwinding mechanism as C++.
- Only works as long as Rust uses the same unwinding mechanism as C++.
+- If the unwinding ABI of the FFI code does not match Rust's the behavior is undefined.
+- If the FFI code makes incorrect assumptions about the layout of a Rust panic (e.g. that the payload is a `String`, and this changes), the behavior is undefined (e.g. if the Rust panic goes through a `catch` statement in the FFI code, if the FFI code double panics and tries to print the Rust panic, etc.).
+- If `#[unwind]` C declarations unwind with anything that isn't a Rust panic produced by the exact same toolchain as the Rust code they live in, the behavior is undefined (e.g. if C++ throws a C++ exception and that ends up in Rust via an `extern "C"` declaration).
+- We haven't been able to fix a soundness bug in the language for a whole year because one single crate was relying on undefined behavior related to this issue. If we turn this undefined behavior into unspecified behavior, we might never be able to improve the Rust unwinding ABI in any way, because doing so would not only break people relying on undefined behavior, but it would also break people relying on `#[unwind]` unspecified details.
- Only works as long as Rust uses the same unwinding mechanism as C++.
+- If the unwinding ABI of the FFI code does not match Rust's the behavior is undefined.
+- If the FFI code makes incorrect assumptions about the layout of a Rust panic (e.g. that the payload is a `String`, and this changes), the behavior is undefined (e.g. if the Rust panic goes through a `catch` statement in the FFI code, if the FFI code double panics and tries to print the Rust panic, etc.).
+- If `#[unwind]` C declarations unwind with anything that isn't a Rust panic produced by the exact same toolchain as the Rust code they live in, the behavior is undefined (e.g. if C++ throws a C++ exception and that ends up in Rust via an `extern "C"` declaration).
+- We haven't been able to fix a soundness bug in the language for a whole year because one single crate was relying on undefined behavior related to this issue. If we turn this undefined behavior into unspecified behavior, we might never be able to improve the Rust unwinding ABI in any way, because doing so would not only break people relying on undefined behavior, but it would also break people relying on `#[unwind]` unspecified details.
+- Does not allow external library bindings to specify whether callbacks they accept are expected to unwind.
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+The goal is to enable the current use-cases for unwinding panics through foreign code while providing safer behaviour towards bindings not expecting that, with minimal changes to the language.
+
+We should try not to prevent the RFC 2699 or other later RFC from resolving the above disadvantages on top of this one.
+
+- https://github.com/rust-lang/rfcs/pull/2699
+
+# Prior art
+[prior-art]: #prior-art
+
+TODO
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+TODO
-TODO
+- Since this simple approach does not allow bindings to specify whether they expect callbacks they accept to unwind, we may want to restrict `#[unwind]` to `unsafe` functions. This restriction can be lifted when unwind is made part of the type.
-TODO
+- Since this simple approach does not allow bindings to specify whether they expect callbacks they accept to unwind, we may want to restrict `#[unwind]` to `unsafe` functions. This restriction can be lifted when unwind is made part of the type.
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+TODO
+
+- https://github.com/rust-lang/rfcs/pull/2699
+
+- `unwind(abort)`
+- non-"C" ABIs