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

RFC: 'C-unwind' ABI #2945

Merged
merged 12 commits into from
Jul 31, 2020
Merged

Conversation

BatmanAoD
Copy link
Member

@BatmanAoD BatmanAoD commented Jun 16, 2020

This RFC was drafted by the FFI Unwind project group.

Rendered

@BatmanAoD BatmanAoD added A-ffi FFI related proposals. A-panic Panics related proposals & ideas T-lang Relevant to the language team, which will review and decide on the RFC. labels Jun 16, 2020
@Ekleog
Copy link

Ekleog commented Jun 16, 2020

Assuming here that there is a need for only one type of unwinding, which may be wrong seeing @petrochenkov's comment.

Would it make sense to have the “handle unwinding” behavior be the extern "C" behavior, and to add an extern "C nounwind"? This way the “safe” version would be the default one, and the optimized but less likely to be safe option would require additional work.

@BatmanAoD
Copy link
Member Author

BatmanAoD commented Jun 16, 2020

@Ekleog That was discussed quite a bit among the project group. There is a summary with links to relevant Zulip discussions here. However, I don't believe we ever re-visited this topic after drafting the full specification in the current RFC.

From the summary:

Kyle: Let's proceed w/ extern "C unwind"; nothing prevents us from landing
extern "C unwind" and then later making extern "C" behave the same way,
unless we make the abort-on-unwind behavior "well defined" (and therefore
stable forever, at least until the next edition)

This RFC does in fact specify that under -Cpanic=unwind, a foreign exception will cause the process to abort. So it technically would be a breaking change to change this behavior once it is stabilized.

@nikomatsakis
Copy link
Contributor

We discussed the question of how to accommodate the "system" ABI in today's @rust-lang/lang meeting today, and there has also been some discussion on Zulip. Our meeting consensus was to go ahead with adding "unwind" variants to whatever ABIs need them and for which it is appropriate (e.g., "stdcall unwind" and so forth).

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved
text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved
text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved
@nikomatsakis
Copy link
Contributor

@rfcbot fcp merge

Dear @rust-lang/lang -- I propose to merge this "ffi unwind" RFC. The major change that came out of the conversation on the RFC thread was extending the "C unwind" ABI explicitly to other ABIs, such as "C unwind", "system unwind" and so forth.

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 6, 2020

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Jul 6, 2020
@BatmanAoD
Copy link
Member Author

@RalfJung I have addressed your comments.

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved
text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved
text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved
@lopopolo
Copy link

I'm not trying to call them as extern "C" from Rust code. I'm trying to pass the function pointers into C code which has no concept of Rust's C-unwind ABI.

@bjorn3
Copy link
Member

bjorn3 commented Jun 10, 2022

C code compiled without the -fexceptions flag uses the equivalent to the extern "C" abi in rust. C code compiled with the -fexceptions flag uses the equivalent to the extern "C-unwind" abi in rust.

In other words if you turn an extern "C-unwind" function into an extern "C" function and then call it from C it is UB for said extern "C-unwind" function to panic.

@lopopolo
Copy link

Thanks @bjorn3 that's good to know that the defining Rust function with the C-unwind ABI requires changes to compiler flags used with the cc crate in order to have Rust panics properly interact with foreign code.

Are there changes coming to the nomicon related to the unwind ABIs and how they interact with -fexceptions? I looked in these places and didn't see any documentation on how I should properly use the C-unwind ABI:

It looks like in order accomplish my goal of replacing a setjmp/longjmp unwinding implementation with a Rust catch_unwind/panic! unwinding implementation I'll need to do the following bits:

  • Reimplement the throw and catch APIs in the library I'm oxidizing with C-unwind ABI functions that use std::panic::resume_unwind and std::panic::catch_unwind.
  • Change the ABI on all of the existing Rust unsafe extern "C" fn APIs that can unwind to instead use unsafe extern "C-unwind fn` signatures.
  • Find some way to get bindgen to generate bindings for the C library I'm interacting with to use the C-unwind ABI for functions and function pointers.
  • Adjust my usage of cc crate to compile C dependencies with -fexceptions.

Does this seem right? I'm not the most familiar with low-level unwinding; thank you for being patient with me and explaining the nuances here. I would find it useful to have these nuances documented in the nomicon.

What is the best way to propagate this information over to the rust-lang/bindgen issue tracker to ensure bindgen is able to support this new language feature?

@bjorn3
Copy link
Member

bjorn3 commented Jun 10, 2022

You may be able to catch_unwind at the boundary with the C code, longjmp over the C code and then resume_unwind once you are back in rust code. I believe setjmp/longjmp can currently only be called from C code though as rust doesn't support the attribute necessary to tell LLVM thag setjmp can return twice.

@BatmanAoD
Copy link
Member Author

@lopopolo Some changes have already landed in the Nomicon repo, but they're not published yet (I'm not sure why). Here's the PR: rust-lang/nomicon#365

It doesn't address the -fexceptions subtlety; I'm not sure exactly what needs to be said about that, though, since, from the perspective of Rust, -fexceptions is a C compiler implementation detail. I think a note would be appropriate, though; I'll think about what it should say. Essentially, panic (and any other unwinding mechanism) is always UB if it goes through stack frames compiled with the assumption that unwinding is impossible, and without -fexceptions, that's how C code is compiled (except on MSVC, because...reasons).

@lopopolo
Copy link

lopopolo commented Jun 11, 2022

I've hacked C-unwind support into my bindgen-generated bindings with sed 👻 and am down to one last blocker. unsafe extern "C-unwind" fn does not implement Debug. This program fails to compile:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=1cbafbf99c59d234c23ac1bcfe93cf6a

#![feature(c_unwind)]

unsafe extern "C" fn boom() {}

unsafe extern "C-unwind" fn bang() {}

#[derive(Default, Debug)]
struct X {
    inner: Option<unsafe extern "C" fn()>,
}

#[derive(Default, Debug)]
struct Y {
    inner: Option<unsafe extern "C-unwind" fn()>,
}

fn main() {
    println!("x: {:?}", X::default());
    println!("x: {:?}", X { inner: Some(boom) });
    println!("y: {:?}", Y::default());
    println!("y: {:?}", Y { inner: Some(bang) });
}

emits this compilation error on nightly:

Compiling playground v0.0.1 (/playground)
error[[E0277]](https://doc.rust-lang.org/nightly/error-index.html#E0277): `unsafe extern "C-unwind" fn()` doesn't implement `Debug`
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug)]
   |                   ----- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `unsafe extern "C-unwind" fn()` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |
   = help: the trait `Debug` is not implemented for `unsafe extern "C-unwind" fn()`
   = help: the following other types implement trait `Debug`:
             extern "C" fn() -> Ret
             extern "C" fn(A) -> Ret
             extern "C" fn(A, ...) -> Ret
             extern "C" fn(A, B) -> Ret
             extern "C" fn(A, B, ...) -> Ret
             extern "C" fn(A, B, C) -> Ret
             extern "C" fn(A, B, C, ...) -> Ret
             extern "C" fn(A, B, C, D) -> Ret
           and 68 others
   = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` due to previous error

@lopopolo
Copy link

Essentially, panic (and any other unwinding mechanism) is always UB if it goes through stack frames compiled with the assumption that unwinding is impossible, and without -fexceptions, that's how C code is compiled (except on MSVC, because...reasons).

@BatmanAoD this bit of context is something I did not know before. I think something close to this for your note would be great to add. Maybe with a hint that clang and gcc enable unwinding in C code with the -fexceptions flag.

@lopopolo
Copy link

My curiosity led me to try this compilation failure with all the standard derivable traits and it looks like none of them are implemented except for Clone and Copy:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=1fde482560c5342dbc9ce885e2a1a706

#![feature(c_unwind)]

unsafe extern "C" fn boom() {}

unsafe extern "C-unwind" fn bang() {}

#[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
struct X {
    inner: Option<unsafe extern "C" fn()>,
}

#[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
struct Y {
    inner: Option<unsafe extern "C-unwind" fn()>,
}

fn main() {
    println!("x: {:?}", X::default());
    println!("x: {:?}", X { inner: Some(boom) });
    println!("y: {:?}", Y::default());
    println!("y: {:?}", Y { inner: Some(bang) });
}
Compiling playground v0.0.1 (/playground)
error[[E0277]](https://doc.rust-lang.org/nightly/error-index.html#E0277): `unsafe extern "C-unwind" fn()` doesn't implement `Debug`
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
   |                   ----- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `unsafe extern "C-unwind" fn()` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |
   = help: the trait `Debug` is not implemented for `unsafe extern "C-unwind" fn()`
   = help: the following other types implement trait `Debug`:
             extern "C" fn() -> Ret
             extern "C" fn(A) -> Ret
             extern "C" fn(A, ...) -> Ret
             extern "C" fn(A, B) -> Ret
             extern "C" fn(A, B, ...) -> Ret
             extern "C" fn(A, B, C) -> Ret
             extern "C" fn(A, B, C, ...) -> Ret
             extern "C" fn(A, B, C, D) -> Ret
           and 68 others
   = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)

error[[E0277]](https://doc.rust-lang.org/nightly/error-index.html#E0277): the trait bound `unsafe extern "C-unwind" fn(): Hash` is not satisfied
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
   |                                       ---- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Hash` is not implemented for `unsafe extern "C-unwind" fn()`
   |
   = help: the following other types implement trait `Hash`:
             extern "C" fn() -> Ret
             extern "C" fn(A) -> Ret
             extern "C" fn(A, ...) -> Ret
             extern "C" fn(A, B) -> Ret
             extern "C" fn(A, B, ...) -> Ret
             extern "C" fn(A, B, C) -> Ret
             extern "C" fn(A, B, C, ...) -> Ret
             extern "C" fn(A, B, C, D) -> Ret
           and 68 others
   = note: required because of the requirements on the impl of `Hash` for `Option<unsafe extern "C-unwind" fn()>`
   = note: this error originates in the derive macro `Hash` (in Nightly builds, run with -Z macro-backtrace for more info)

error[[E0369]](https://doc.rust-lang.org/nightly/error-index.html#E0369): binary operation `==` cannot be applied to type `Option<unsafe extern "C-unwind" fn()>`
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
   |                                             --------- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the derive macro `PartialEq` (in Nightly builds, run with -Z macro-backtrace for more info)

error[[E0369]](https://doc.rust-lang.org/nightly/error-index.html#E0369): binary operation `!=` cannot be applied to type `Option<unsafe extern "C-unwind" fn()>`
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
   |                                             --------- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the derive macro `PartialEq` (in Nightly builds, run with -Z macro-backtrace for more info)

error[[E0277]](https://doc.rust-lang.org/nightly/error-index.html#E0277): the trait bound `unsafe extern "C-unwind" fn(): Eq` is not satisfied
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
   |                                                        -- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Eq` is not implemented for `unsafe extern "C-unwind" fn()`
   |
   = help: the following other types implement trait `Eq`:
             extern "C" fn() -> Ret
             extern "C" fn(A) -> Ret
             extern "C" fn(A, ...) -> Ret
             extern "C" fn(A, B) -> Ret
             extern "C" fn(A, B, ...) -> Ret
             extern "C" fn(A, B, C) -> Ret
             extern "C" fn(A, B, C, ...) -> Ret
             extern "C" fn(A, B, C, D) -> Ret
           and 68 others
   = note: required because of the requirements on the impl of `Eq` for `Option<unsafe extern "C-unwind" fn()>`
note: required by a bound in `AssertParamIsEq`
   = note: this error originates in the derive macro `Eq` (in Nightly builds, run with -Z macro-backtrace for more info)

error[[E0277]](https://doc.rust-lang.org/nightly/error-index.html#E0277): can't compare `unsafe extern "C-unwind" fn()` with `unsafe extern "C-unwind" fn()`
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
   |                                                            ---------- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no implementation for `unsafe extern "C-unwind" fn() < unsafe extern "C-unwind" fn()` and `unsafe extern "C-unwind" fn() > unsafe extern "C-unwind" fn()`
   |
   = help: the trait `PartialOrd` is not implemented for `unsafe extern "C-unwind" fn()`
   = help: the following other types implement trait `PartialOrd<Rhs>`:
             extern "C" fn() -> Ret
             extern "C" fn(A) -> Ret
             extern "C" fn(A, ...) -> Ret
             extern "C" fn(A, B) -> Ret
             extern "C" fn(A, B, ...) -> Ret
             extern "C" fn(A, B, C) -> Ret
             extern "C" fn(A, B, C, ...) -> Ret
             extern "C" fn(A, B, C, D) -> Ret
           and 68 others
   = note: required because of the requirements on the impl of `PartialOrd` for `Option<unsafe extern "C-unwind" fn()>`
   = note: this error originates in the derive macro `PartialOrd` (in Nightly builds, run with -Z macro-backtrace for more info)

error[[E0277]](https://doc.rust-lang.org/nightly/error-index.html#E0277): the trait bound `unsafe extern "C-unwind" fn(): Ord` is not satisfied
  --> src/main.rs:14:5
   |
12 | #[derive(Default, Debug, Clone, Copy, Hash, PartialEq, Eq, PartialOrd, Ord)]
   |                                                                        --- in this derive macro expansion
13 | struct Y {
14 |     inner: Option<unsafe extern "C-unwind" fn()>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Ord` is not implemented for `unsafe extern "C-unwind" fn()`
   |
   = help: the following other types implement trait `Ord`:
             extern "C" fn() -> Ret
             extern "C" fn(A) -> Ret
             extern "C" fn(A, ...) -> Ret
             extern "C" fn(A, B) -> Ret
             extern "C" fn(A, B, ...) -> Ret
             extern "C" fn(A, B, C) -> Ret
             extern "C" fn(A, B, C, ...) -> Ret
             extern "C" fn(A, B, C, D) -> Ret
           and 68 others
   = note: required because of the requirements on the impl of `Ord` for `Option<unsafe extern "C-unwind" fn()>`
   = note: this error originates in the derive macro `Ord` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0277, E0369.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `playground` due to 7 previous errors

@RalfJung
Copy link
Member

For the missing Debug impls, see rust-lang/rust#92964.

lopopolo added a commit to artichoke/artichoke that referenced this pull request Jun 12, 2022
The Rust team has put out a call for testing on the `c_unwind` feature
and associated `C-unwind` ABI:

- rust-lang/rfcs#2945 (comment)

I intend to implement mruby's exception unwinding using Rust's panic
infrastructure:

- #35

This commit changes the Rust toolchain to nightly for this test. Merging
this experiment will be blocked on the `C-unwind` ABI making it to
stable.
@lopopolo
Copy link

I filed a ticket to add ABI customization for generated bindings to bindgen:

The ticket is pretty barebones. I'm not sure if there's any additional context that should be included in the ticket.

lopopolo added a commit to artichoke/artichoke that referenced this pull request Jun 28, 2022
The Rust team has put out a call for testing on the `c_unwind` feature
and associated `C-unwind` ABI:

- rust-lang/rfcs#2945 (comment)

I intend to implement mruby's exception unwinding using Rust's panic
infrastructure:

- #35

This commit changes the Rust toolchain to nightly for this test. Merging
this experiment will be blocked on the `C-unwind` ABI making it to
stable.
lopopolo added a commit to artichoke/artichoke that referenced this pull request Jul 24, 2022
The Rust team has put out a call for testing on the `c_unwind` feature
and associated `C-unwind` ABI:

- rust-lang/rfcs#2945 (comment)

I intend to implement mruby's exception unwinding using Rust's panic
infrastructure:

- #35

This commit changes the Rust toolchain to nightly for this test. Merging
this experiment will be blocked on the `C-unwind` ABI making it to
stable.
lopopolo added a commit to artichoke/artichoke that referenced this pull request Jul 24, 2022
The Rust team has put out a call for testing on the `c_unwind` feature
and associated `C-unwind` ABI:

- rust-lang/rfcs#2945 (comment)

I intend to implement mruby's exception unwinding using Rust's panic
infrastructure:

- #35

This commit changes the Rust toolchain to nightly for this test. Merging
this experiment will be blocked on the `C-unwind` ABI making it to
stable.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 21, 2022
…pls, r=thomcc

Add default trait implementations for "c-unwind" ABI function pointers

Following up on rust-lang#92964, only add default trait implementations for the `c-unwind` family of function pointers. The previous attempt in rust-lang#92964 added trait implementations for many more ABIs and ran into concerns regarding the increase in size of the libcore rlib.

An attempt to abstract away function pointer types behind a unified trait to reduce the duplication of trait impls is being discussed in rust-lang#99531 but this change looks to be blocked on a lang MCP.

Following `@RalfJung's` suggestion in rust-lang#99531 (comment), this commit is another cut at rust-lang#92964 but it _only_ adds the impls for `extern "C-unwind" fn` and `unsafe extern "C-unwind" fn`.

I am interested in landing this patch to unblock the stabilization of the `c_unwind` feature.

RFC: rust-lang/rfcs#2945
Tracking Issue: rust-lang#74990
lopopolo added a commit to artichoke/artichoke that referenced this pull request Oct 24, 2022
The Rust team has put out a call for testing on the `c_unwind` feature
and associated `C-unwind` ABI:

- rust-lang/rfcs#2945 (comment)

I intend to implement mruby's exception unwinding using Rust's panic
infrastructure:

- #35

This commit changes the Rust toolchain to nightly for this test. Merging
this experiment will be blocked on the `C-unwind` ABI making it to
stable.
@lopopolo
Copy link

The previous conversation on missing traits has been resolved with this PR:

lopopolo added a commit to artichoke/artichoke that referenced this pull request Nov 8, 2022
The Rust team has put out a call for testing on the `c_unwind` feature
and associated `C-unwind` ABI:

- rust-lang/rfcs#2945 (comment)

I intend to implement mruby's exception unwinding using Rust's panic
infrastructure:

- #35

This commit changes the Rust toolchain to nightly for this test. Merging
this experiment will be blocked on the `C-unwind` ABI making it to
stable.
lopopolo added a commit to artichoke/artichoke that referenced this pull request Nov 8, 2022
The Rust team has put out a call for testing on the `c_unwind` feature
and associated `C-unwind` ABI:

- rust-lang/rfcs#2945 (comment)

I intend to implement mruby's exception unwinding using Rust's panic
infrastructure:

- #35

This commit changes the Rust toolchain to nightly for this test. Merging
this experiment will be blocked on the `C-unwind` ABI making it to
stable.
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
Following up on #92964, only add default trait implementations for the
`c-unwind` family of function pointers. The previous attempt in #92964
added trait implementations for many more ABIs and ran into concerns
regarding the increase in size of the libcore rlib.

An attempt to abstract away function pointer types behind a unified
trait to reduce the duplication of trait impls is being discussed in #99531
but this change looks to be blocked on a lang MCP.

Following @RalfJung's suggestion in
rust-lang/rust#99531 (comment),
this commit is another cut at #92964 but it _only_ adds the impls for
`extern "C-unwind" fn` and `unsafe extern "C-unwind" fn`.

I am interested in landing this patch to unblock the stabilization of
the `c_unwind` feature.

RFC: rust-lang/rfcs#2945
Tracking Issue: rust-lang/rust#74990
thomcc pushed a commit to tcdi/postgrestd that referenced this pull request Feb 10, 2023
…omcc

Add default trait implementations for "c-unwind" ABI function pointers

Following up on #92964, only add default trait implementations for the `c-unwind` family of function pointers. The previous attempt in #92964 added trait implementations for many more ABIs and ran into concerns regarding the increase in size of the libcore rlib.

An attempt to abstract away function pointer types behind a unified trait to reduce the duplication of trait impls is being discussed in #99531 but this change looks to be blocked on a lang MCP.

Following `@RalfJung's` suggestion in rust-lang/rust#99531 (comment), this commit is another cut at #92964 but it _only_ adds the impls for `extern "C-unwind" fn` and `unsafe extern "C-unwind" fn`.

I am interested in landing this patch to unblock the stabilization of the `c_unwind` feature.

RFC: rust-lang/rfcs#2945
Tracking Issue: rust-lang/rust#74990
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ffi FFI related proposals. A-panic Panics related proposals & ideas disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.