-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking issue for const extern fn
and const unsafe extern fn
#64926
Comments
Could you explain a bit more what this means and what the point is? What does the bare |
@RalfJung: The point is to be able to define an |
…r=Centril Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When rust-lang/rfcs#2345 (rust-lang#51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: rust-lang#64926.
Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When rust-lang/rfcs#2345 (#51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: #64926.
Implemented in #64906 (2019-10-07). |
From #64906 (comment):
@RalfJung: Are you talking about a |
Yes, I meant a |
…Jung Ensure that we error when calling "const extern fn" with wrong convention See rust-lang#64926
@Centril: In #64906 (comment), you said:
Since this PR was merged, rust-lang/libc#1536 was merged, which takes advantage of this feature. Do you still want an RFC prior to stabilization? If so, I'd be happy to start writing one up. |
Some points:
|
All the issues that were blocking this feature from being stablised appear to have been addressed, could this be stablised now? I think any code that would want to use it could just use a non-const extern function which wraps a |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
All other ABIs are left unstable for now. cc rust-lang#64926
… r=pnkfelix Stablize `const_extern_fn` for "Rust" and "C" All other ABIs are left unstable for now. cc rust-lang#64926
… r=pnkfelix Stablize `const_extern_fn` for "Rust" and "C" All other ABIs are left unstable for now. cc rust-lang#64926
… r=pnkfelix Stablize `const_extern_fn` for "Rust" and "C" All other ABIs are left unstable for now. cc rust-lang#64926
… r=pnkfelix Stablize `const_extern_fn` for "Rust" and "C" All other ABIs are left unstable for now. cc rust-lang#64926
… r=pnkfelix Stablize `const_extern_fn` for "Rust" and "C" All other ABIs are left unstable for now. cc rust-lang#64926
… r=pnkfelix Stablize `const_extern_fn` for "Rust" and "C" All other ABIs are left unstable for now. cc rust-lang#64926
It looks like "C" and "Rust" calling conventions were stabilized for the upcoming 1.62 release. Other calling conventions could be stabilized as well; is there a blocker for doing so? |
I am not aware of any calling convention being special here. (Other than variadics, but those are generally unstable, not just for |
stabilize `const_extern_fn` closes rust-lang/rust#64926 tracking issue: rust-lang/rust#64926 reference PR: rust-lang/reference#1596 ## Stabilizaton Report ### Summary Using `const extern "Rust"` and `const extern "C"` was already stabilized (since version 1.62.0, see rust-lang/rust#95346). This PR stabilizes the other calling conventions: it is now possible to write `const unsafe extern "calling-convention" fn` and `const extern "calling-convention" fn` for any supported calling convention: ```rust const extern "C-unwind" fn foo1(val: u8) -> u8 { val + 1} const extern "stdcall" fn foo2(val: u8) -> u8 { val + 1} const unsafe extern "C-unwind" fn bar1(val: bool) -> bool { !val } const unsafe extern "stdcall" fn bar2(val: bool) -> bool { !val } ``` This can be used to const-ify an `extern fn`, or conversely, to make a `const fn` callable from external code. r? T-lang cc `@RalfJung`
This is a tracking issue for implementing and stabilizing defining a
const extern fn
andconst unsafe extern fn
const unsafe? extern fn
#64906 (comment) (added in Ensure that we error when calling "const extern fn" with wrong convention #68370)Stabilizaton Report
Summary
This allows writing
const unsafe extern "calling-convention" fn
andconst extern "calling-convention" fn
:Today Rust and C calling conventions are stable (as of 1.62, see #95346). All other calling conventions are still unstable.
This can be used to const-ify an
extern fn
(or equivalently, to make aconst fn
callable from external code).Test cases
const
context) leads to an error: https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/miri_unleashed/abi-mismatch.rsThe text was updated successfully, but these errors were encountered: