-
Notifications
You must be signed in to change notification settings - Fork 44
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
C-unwind and Rust 1.71.0 #539
Comments
If we just remove the |
Though actually making |
Yeah this is kind of annoying when I'm trying to make Rust cocoa wrappers that, are Rusty, and, safe. I wonder if there's any way to bridge this incompatibility... |
Given that rust-lang/rust#115285 is FCP, this is now becoming a bit more important. Unfortunately, I can't really raise the MSRV for |
It could, at least in the short term be an opt-in feature, or perhaps enabled only on newer rust versions with a crate such as rustversion, which, well allows conditional compilation based upon whatever version of rustc you're compiling for. It may be worth taking a look at, though, in the short term it may complicate maintainability, and anger some folk due to the additional dependency. A build script may be able to provide similar functionality, though, again with potential issues pertaining to maintainability, as managing a lot of conditional compilation can, really be a pain in the ass. |
Yeah. I think the easier solution might be to allow a bump to Winit's Rust version on macOS only. |
Rust is deciding to let catching foreign unwinding (like Objective-C exceptions) in |
C-unwind was added in Rust 1.71, and allows panicking/unwinding /exceptions across foreign function interfaces. Additionally, Rust decided to let handling of foreign unwinds be implementation defined behavior (instead of undefined), so we can now mark `throw` as safe, see rust-lang/rust#128321. This has a cost in that we now have landing pads on every message send; this is strictly the correct choice, though, so we will have to bear with it. Fixes #539.
C-unwind was added in Rust 1.71, and allows panicking/unwinding /exceptions across foreign function interfaces. Additionally, Rust decided to let handling of foreign unwinds be implementation defined behavior (instead of undefined), so we can now mark `throw` as safe, see rust-lang/rust#128321. This has a cost in that we now have landing pads on every message send; this is strictly the correct choice, though, so we will have to bear with it. Fixes #539.
C-unwind was added in Rust 1.71, and allows panicking/unwinding /exceptions across foreign function interfaces. Additionally, Rust decided to let handling of foreign unwinds be implementation defined behavior (instead of undefined), so we can now mark `throw` as safe, see rust-lang/rust#128321. This has a cost in that we now have landing pads on every message send; this is strictly the correct choice, though, so we will have to bear with it. Fixes #539.
I have bumped MSRV to 1.71, and used |
Rust 1.71.0 stabilizes (at least partially) C-unwinding. However, due to issues with the
feature
attribute's usage on stable, one is unable to utilize C-unwind on Rust 1.71.0+, despite it being available, when on stable.There should be some kind of additional conditional compilation code to handle these versions, while still maintaining the current MSRV of 0.60.0. I'm trying to figure out how myself rn, hence my fork.
The text was updated successfully, but these errors were encountered: