Description
This is the summary issue for the unsupported_fn_ptr_calling_conventions future-compatibility warning. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.
What is the warning for?
The unsupported_fn_ptr_calling_conventions lint is output whenever there is a use of a target dependent calling convention on a target that does not support this calling convention on a function pointer.
For example stdcall does not make much sense for a x86_64 or, more apparently, powerpc code, because this calling convention was never specified for those targets.
Example
fn stdcall_ptr(f: extern "stdcall" fn ()) {
f()
}This will produce:
warning: use of calling convention not supported on this target on function pointer
--> $DIR/unsupported.rs:34:15
|
LL | fn stdcall_ptr(f: extern "stdcall" fn()) {
| ^^^^^^^^^^^^^^^^^^^^^^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #130260 <https://github.com/rust-lang/rust/issues/130260>
= note: `#[warn(unsupported_fn_ptr_calling_conventions)]` on by default
Explanation
On most of the targets the behavior of stdcall and similar calling conventions is not defined at all, but was previously accepted due to a bug in the implementation of the compiler.
Recommendations
Use #[cfg(…)] annotations to ensure that the ABI identifiers are only used in combination with targets for which the requested ABI is well specified.
When will this warning become a hard error?
At the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.
Implemented in #128784
See also #87678 for the similar unsupported_calling_conventions lint.