Tracking issue for future-incompatibility lint `unsupported_calling_conventions` #87678

nagisa · 2021-08-01T08:48:35Z

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.

The text was updated successfully, but these errors were encountered:

Mark-Simulacrum · 2021-08-27T15:19:40Z

@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 · 2021-08-27T16:34:06Z

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

dpaoliello · 2022-08-01T20:24:11Z

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 · 2022-08-01T23:37:41Z

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.

…ottom, r=estebank Move lint level source explanation to the bottom So, uhhhhh r? `@estebank` ## User-facing change "note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic: ```diff - = 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 rust-lang#87678 <rust-lang#87678> + = note: `#[warn(unsupported_calling_conventions)]` on by default ``` Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO. ## Developer-facing change `struct_span_lint` and similar methods have a different signature. Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)` After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>` The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion. Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere. ## Subtle problem By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings... I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate. ## P.S. I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢

…estebank Move lint level source explanation to the bottom So, uhhhhh r? `@estebank` ## User-facing change "note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic: ```diff - = 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 #87678 <rust-lang/rust#87678> + = note: `#[warn(unsupported_calling_conventions)]` on by default ``` Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO. ## Developer-facing change `struct_span_lint` and similar methods have a different signature. Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)` After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>` The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion. Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere. ## Subtle problem By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings... I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate. ## P.S. I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢

Check ABI target compatibility for function pointers Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` try-job: aarch64-gnu try-job: aarch64-apple try-job: x86_64-msvc try-job: x86_64-mingw try-job: i686-msvc try-job: i686-mingw try-job: test-various try-job: armhf-gnu

Check ABI target compatibility for function pointers Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Places to check in the tests: * [x] Check if we can use another ABI here ``` tests/debuginfo/type-names.rs 20:// gdb-check:type = type_names::GenericStruct<type_names::Struct1, extern "fastcall" fn(isize) -> usize> 375: let generic_struct2: GenericStruct<Struct1, extern "fastcall" fn(isize) -> usize> = ``` try-job: aarch64-gnu try-job: aarch64-apple try-job: x86_64-msvc try-job: x86_64-mingw try-job: i686-msvc try-job: i686-mingw try-job: test-various try-job: armhf-gnu

Check ABI target compatibility for function pointers Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` try-job: aarch64-gnu try-job: aarch64-apple try-job: x86_64-msvc try-job: i686-msvc try-job: test-various try-job: armhf-gnu

Check ABI target compatibility for function pointers Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Open Questions * [ ] Should this report a future incompatibility warning like rust-lang#87678 ? try-job: aarch64-gnu try-job: aarch64-apple try-job: x86_64-msvc try-job: i686-msvc try-job: test-various try-job: armhf-gnu

Check ABI target compatibility for function pointers Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Open Questions * [ ] Should this report a future incompatibility warning like rust-lang#87678 ? * [ ] Is this the best place to perform the check? try-job: aarch64-gnu try-job: aarch64-apple try-job: x86_64-msvc try-job: i686-msvc try-job: test-various try-job: armhf-gnu

Check ABI target compatibility for function pointers Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Open Questions * [ ] Should this report a future incompatibility warning like rust-lang#87678 ? * [ ] Is this the best place to perform the check?

tmandry · 2024-10-03T21:54:37Z

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 · 2024-10-04T06:39:47Z

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.

…iler-errors Check ABI target compatibility for function pointers Tracking issue: rust-lang#130260 Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Open Questions * [x] Should this report a future incompatibility warning like rust-lang#87678 ? * [ ] Is this the best place to perform the check?

Rollup merge of rust-lang#128784 - tdittr:check-abi-on-fn-ptr, r=compiler-errors Check ABI target compatibility for function pointers Tracking issue: rust-lang#130260 Related tracking issue: rust-lang#87678 Compatibility of an ABI for a target was previously only performed on function definitions and `extern` blocks. This PR adds it also to function pointers to be consistent. This might have broken some of the `tests/ui/` depending on the platform, so a try run seems like a good idea. Also this might break existing code, because we now emit extra errors. Does this require a crater run? # Example ```rust // build with: --target=x86_64-unknown-linux-gnu // These raise E0570 extern "thiscall" fn foo() {} extern "thiscall" { fn bar() } // This did not raise any error fn baz(f: extern "thiscall" fn()) { f() } ``` # Open Questions * [x] Should this report a future incompatibility warning like rust-lang#87678 ? * [ ] Is this the best place to perform the check?

…ntions, r=compiler-errors make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang#86231 (comment)) even when the lint was originally added. This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.) Fixes rust-lang#87678

…ompiler-errors make unsupported_calling_conventions a hard error This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](rust-lang/rust#86231 (comment)) even when the lint was originally added. This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.) Fixes rust-lang/rust#87678

nagisa added regression-from-stable-to-beta Performance or correctness regression from stable to beta. C-bug Category: This is a bug. labels Aug 1, 2021

nagisa self-assigned this Aug 1, 2021

rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Aug 1, 2021

apiraino removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Aug 12, 2021

Mark-Simulacrum added this to the 1.55.0 milestone Aug 27, 2021

nagisa changed the title ~~UNSUPPORTED_CALLING_CONVENTIONS future compat link needs a tracking issue~~ Tracking issue for UNSUPPORTED_CALLING_CONVENTIONS future compatibility lint Aug 27, 2021

rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Aug 27, 2021

nagisa removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Aug 27, 2021

Mark-Simulacrum removed the regression-from-stable-to-beta Performance or correctness regression from stable to beta. label Sep 3, 2021

Mark-Simulacrum removed this from the 1.55.0 milestone Sep 3, 2021

nagisa removed their assignment Sep 13, 2021

dpaoliello mentioned this issue Aug 8, 2022

Add import_name_type parameter to #[link] rust-lang/compiler-team#525

Closed

3 tasks

dpaoliello mentioned this issue Nov 3, 2022

Tracking issue for RFC 2627: #[link(kind="raw-dylib")] #58713

Open

15 tasks

dpaoliello mentioned this issue Apr 19, 2023

Variadic functions don't allow "system" on non-x86 Windows #110505

Closed

tmandry added this to Lang Edition 2024 Nov 3, 2023

github-project-automation bot moved this to Idea in Lang Edition 2024 Nov 3, 2023

github-actions bot mentioned this issue Apr 9, 2024

rust/1.77.2 package update wolfi-dev/os#16567

Merged

tdittr mentioned this issue Aug 7, 2024

Check ABI target compatibility for function pointers #128784

Merged

2 tasks

tdittr mentioned this issue Sep 12, 2024

Tracking issue for future-incompatibility lint unsupported_fn_ptr_calling_conventions #130260

Open

fmease changed the title ~~Tracking issue for UNSUPPORTED_CALLING_CONVENTIONS future compatibility lint~~ Tracking issue for future-incompatibility lint unsupported_calling_conventions Sep 14, 2024

fmease added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-ABI Area: Concerning the application binary interface (ABI) A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. labels Sep 14, 2024

RalfJung mentioned this issue Oct 4, 2024

make unsupported_calling_conventions a hard error #129935

Merged

bors closed this as completed in 1de57a5 Oct 22, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for future-incompatibility lint `unsupported_calling_conventions` #87678

Tracking issue for future-incompatibility lint `unsupported_calling_conventions` #87678

nagisa commented Aug 1, 2021 •

edited by fmease

Loading

Mark-Simulacrum commented Aug 27, 2021

nagisa commented Aug 27, 2021

dpaoliello commented Aug 1, 2022

nagisa commented Aug 1, 2022 •

edited

Loading

tmandry commented Oct 3, 2024

RalfJung commented Oct 4, 2024 •

edited

Loading

Tracking issue for future-incompatibility lint unsupported_calling_conventions #87678

Tracking issue for future-incompatibility lint unsupported_calling_conventions #87678

Comments

nagisa commented Aug 1, 2021 • edited by fmease Loading

What is the warning for?

Example

Recommendations

When will this warning become a hard error?

Mark-Simulacrum commented Aug 27, 2021

nagisa commented Aug 27, 2021

dpaoliello commented Aug 1, 2022

nagisa commented Aug 1, 2022 • edited Loading

tmandry commented Oct 3, 2024

RalfJung commented Oct 4, 2024 • edited Loading

Tracking issue for future-incompatibility lint `unsupported_calling_conventions` #87678

Tracking issue for future-incompatibility lint `unsupported_calling_conventions` #87678

nagisa commented Aug 1, 2021 •

edited by fmease

Loading

nagisa commented Aug 1, 2022 •

edited

Loading

RalfJung commented Oct 4, 2024 •

edited

Loading