Tracking issue for future-incompatibility lint `unsupported_fn_ptr_calling_conventions`

[tdittr]

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.

[tdittr]

@rustbot label +C-future-compatibility +C-tracking-issue

[Freax13]

~While the primary purpose of the x86-interrupt ABI is to write kernel interrupt handlers with bare-metal targets, LLVM also supports userspace interrupt handlers using the x86-interrupt ABI (notice the uiret instruction instead of iret), so this could be useful for non-bare-metal targets as well. Note that target-cpu has to be set to a CPU that supports user interrupts.~

(Sorry, for some reason I thought x86-interrupt was no longer allowed on non-bare-metal targets, but that's not the case at all, so my comment doesn't apply.)