Tracking issue for future-incompatibility lint unsupported_calling_conventions

[nagisa]

This is the summary issue for the unsupported_calling_conventions future-incompatibility warning and other related errors. 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_calling_conventions lint is output whenever there is an use of the stdcall, fastcall, thiscall, vectorcall calling conventions (or their unwind variants) on targets that cannot meaningfully be supported for the requested target.

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.

Historically MSVC toolchains have fallen back to the regular C calling convention for targets other than x86, but Rust doesn't really see a similar need to introduce a similar hack across many more targets.

Example

extern "stdcall" fn stdcall() {}

This will produce:

warning: use of calling convention not supported on this target
  --> $DIR/unsupported.rs:39:1
   |
LL | extern "stdcall" fn stdcall() {}
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(unsupported_calling_conventions)]` on by default
   = 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 ...

On most of the targets the behaviour 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.

[Mark-Simulacrum]

@nagisa do you think you'll get a chance to fix this before the next release? We have approximately one week before ideally all backports are in.

[nagisa]

Yeah, thanks for the reminder. #88397 is the PR.

[dpaoliello]

Use #[cfg(…)] annotations to ensure that the ABI identifiers are only used in combination with targets for which the requested ABI is well specified.

Can you please provide samples of this? I'm not sure how'd you write this without having to duplicate the entire function or extern block...

[nagisa]

Macros are a traditional solution to duplication woes. Something like this, perhaps:

macro_rules! extern_item {
    ($($toks: tt)+) => {
        extern "C" $($toks)+
    };
}

// Use `sysv64` on x86_64 targets instead of C
#[cfg(target_arch = "x86_64")]
macro_rules! extern_item {
    ($($toks: tt)+) => {
        extern "sysv64" $($toks)+
    };
}

extern_item! { {
    fn extern_declaration();
} }

extern_item! { fn definition() { ... } }

Otherwise, yes, the expectation is that the function definitions and extern declarations are duplicated in well-formed code.

[tmandry]

Cross posting from #128784, a couple of T-lang members thought we might want to support this for uncalled functions since adding a cfg everywhere could be quite annoying.

But we would need to ensure that the function never gets codegenned, if we want to avoid uncomfortable questions like "what the heck is the backend supposed to do with this".

[RalfJung]

Note that this here is about defining functions with unsupported calling conventions / ABIs. In #129935 I am suggesting to make this a hard error. It is already a hard error in most cases, but a few were forgotten, and IMO we should make this consistent.

#128784 (tracked at #130260) is about using function pointer types with unsupported ABIs.