-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: