RFC: 'C-unwind' ABI #2945

BatmanAoD · 2020-06-16T15:42:25Z

This RFC was drafted by the FFI Unwind project group.

text/0000-c-unwind-abi.md

Ekleog · 2020-06-16T22:06:13Z

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 · 2020-06-16T23:34:27Z

@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 · 2020-06-22T20:56:16Z

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

nikomatsakis · 2020-07-06T23:47:25Z

@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 · 2020-07-06T23:47:26Z

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.

BatmanAoD · 2020-07-07T22:20:30Z

@RalfJung I have addressed your comments.

text/0000-c-unwind-abi.md

lopopolo · 2022-06-10T15:55:57Z

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 · 2022-06-10T18:07:53Z

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 · 2022-06-10T20:35:45Z

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 · 2022-06-10T23:02:40Z

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 · 2022-06-10T23:50:33Z

@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 · 2022-06-11T05:56:17Z

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 · 2022-06-11T06:03:21Z

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 · 2022-06-11T06:09:12Z

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 · 2022-06-11T15:02:07Z

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

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 · 2022-06-12T22:22:19Z

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

Support for generating bindings with the C-unwind ABI rust-bindgen#2224

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

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.

…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

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 · 2022-10-25T06:42:24Z

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

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

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.

@RalfJung

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

…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

'C unwind' ABI - drafted by FFI Unwind project group

3c2d2ad

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

nikomatsakis added the I-nominated label Jun 16, 2020

petrochenkov reviewed Jun 16, 2020

View reviewed changes

text/0000-c-unwind-abi.md Show resolved Hide resolved

nikomatsakis mentioned this pull request Jun 22, 2020

ffi-unwind rust-lang/lang-team#19

Closed

RalfJung reviewed Jun 24, 2020

View reviewed changes

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved

RalfJung reviewed Jun 24, 2020

View reviewed changes

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved

RalfJung reviewed Jun 24, 2020

View reviewed changes

text/0000-c-unwind-abi.md Show resolved Hide resolved

RalfJung reviewed Jun 24, 2020

View reviewed changes

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved

TODOs for myself

2f2c9b7

daxpedda mentioned this pull request Jun 26, 2020

Release? daxpedda/sentry-contrib-native#7

Closed

nikomatsakis removed the I-nominated label Jun 29, 2020

Changes from review; mention 'system' and other ABIs

23efb0a

nikomatsakis approved these changes Jul 6, 2020

View reviewed changes

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

Comments from RalfJ

49f061f

BatmanAoD mentioned this pull request Jul 9, 2020

RFC missing from FCP list rust-lang/this-week-in-rust#1351

Closed

RalfJung reviewed Jul 12, 2020

View reviewed changes

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved

RalfJung reviewed Jul 12, 2020

View reviewed changes

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved

RalfJung reviewed Jul 12, 2020

View reviewed changes

text/0000-c-unwind-abi.md Outdated Show resolved Hide resolved

Revise limitations section

fdbd98f

madsmtm mentioned this pull request Jun 11, 2022

Unstable: Make calling throw no longer UB by using "C-unwind" madsmtm/objc2#71

Merged

lopopolo mentioned this pull request Jun 12, 2022

Support for generating bindings with the C-unwind ABI rust-lang/rust-bindgen#2224

Closed

lopopolo mentioned this pull request Sep 1, 2022

Add default trait implementations for "c-unwind" ABI function pointers rust-lang/rust#101263

Merged

lopopolo mentioned this pull request Sep 10, 2022

Implement standard traits on C-unwind ABI function pointers rust-lang/libs-team#100

Closed

BatmanAoD mentioned this pull request Aug 27, 2023

c_unwind full stabilization request: change in extern "C" behavior rust-lang/rust#115285

Closed

ssokolow mentioned this pull request Jan 10, 2024

PoC: add Rust submodule as libbasic_rust systemd/systemd#19598

Open

Riatre mentioned this pull request May 7, 2024

Add binding for agent forwarding wez/libssh-rs#24

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: 'C-unwind' ABI #2945

RFC: 'C-unwind' ABI #2945

BatmanAoD commented Jun 16, 2020 •

edited

Loading

Ekleog commented Jun 16, 2020

BatmanAoD commented Jun 16, 2020 •

edited

Loading

nikomatsakis commented Jun 22, 2020

nikomatsakis commented Jul 6, 2020

rfcbot commented Jul 6, 2020 •

edited by scottmcm

Loading

BatmanAoD commented Jul 7, 2020

lopopolo commented Jun 10, 2022

bjorn3 commented Jun 10, 2022

lopopolo commented Jun 10, 2022

bjorn3 commented Jun 10, 2022 •

edited

Loading

BatmanAoD commented Jun 10, 2022

lopopolo commented Jun 11, 2022 •

edited

Loading

lopopolo commented Jun 11, 2022

lopopolo commented Jun 11, 2022

RalfJung commented Jun 11, 2022

lopopolo commented Jun 12, 2022

lopopolo commented Oct 25, 2022

RFC: 'C-unwind' ABI #2945

RFC: 'C-unwind' ABI #2945

Conversation

BatmanAoD commented Jun 16, 2020 • edited Loading

Ekleog commented Jun 16, 2020

BatmanAoD commented Jun 16, 2020 • edited Loading

nikomatsakis commented Jun 22, 2020

nikomatsakis commented Jul 6, 2020

rfcbot commented Jul 6, 2020 • edited by scottmcm Loading

BatmanAoD commented Jul 7, 2020

lopopolo commented Jun 10, 2022

bjorn3 commented Jun 10, 2022

lopopolo commented Jun 10, 2022

bjorn3 commented Jun 10, 2022 • edited Loading

BatmanAoD commented Jun 10, 2022

lopopolo commented Jun 11, 2022 • edited Loading

lopopolo commented Jun 11, 2022

lopopolo commented Jun 11, 2022

RalfJung commented Jun 11, 2022

lopopolo commented Jun 12, 2022

lopopolo commented Oct 25, 2022

BatmanAoD commented Jun 16, 2020 •

edited

Loading

BatmanAoD commented Jun 16, 2020 •

edited

Loading

rfcbot commented Jul 6, 2020 •

edited by scottmcm

Loading

bjorn3 commented Jun 10, 2022 •

edited

Loading

lopopolo commented Jun 11, 2022 •

edited

Loading