-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking issue for future-incompatibility lint unsupported_fn_ptr_calling_conventions
#130260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
A-ABI
Area: Concerning the application binary interface (ABI)
A-lints
Area: Lints (warnings about flaws in source code) such as unused_mut.
C-future-incompatibility
Category: Future-incompatibility lints
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
This comment was marked as resolved.
This comment was marked as resolved.
UNSUPPORTED_FN_PTR_CALLING_CONVENTIONS
future compatibility lintUNSUPPORTED_FN_PTR_CALLING_CONVENTIONS
future-incompatibility lint
UNSUPPORTED_FN_PTR_CALLING_CONVENTIONS
future-incompatibility lintunsupported_fn_ptr_calling_conventions
This was referenced Oct 4, 2024
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 12, 2024
…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?
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 12, 2024
…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?
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 13, 2024
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?
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 14, 2024
…age, r=compiler-errors Update lint message for ABI not supported Tracking issue: rust-lang#130260 As requested in rust-lang#128784 (review) I updated the error message. I could also change it to be the same message as if it was a hard error on a normal function: > "`{abi}` is not a supported ABI for the current target" Or would that get confusing when people try to google the error message? r? compiler-errors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 14, 2024
…age, r=compiler-errors Update lint message for ABI not supported Tracking issue: rust-lang#130260 As requested in rust-lang#128784 (review) I updated the error message. I could also change it to be the same message as if it was a hard error on a normal function: > "`{abi}` is not a supported ABI for the current target" Or would that get confusing when people try to google the error message? r? compiler-errors
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this issue
Oct 15, 2024
…age, r=compiler-errors Update lint message for ABI not supported Tracking issue: rust-lang#130260 As requested in rust-lang#128784 (review) I updated the error message. I could also change it to be the same message as if it was a hard error on a normal function: > "`{abi}` is not a supported ABI for the current target" Or would that get confusing when people try to google the error message? r? compiler-errors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Oct 15, 2024
…age, r=compiler-errors Update lint message for ABI not supported Tracking issue: rust-lang#130260 As requested in rust-lang#128784 (review) I updated the error message. I could also change it to be the same message as if it was a hard error on a normal function: > "`{abi}` is not a supported ABI for the current target" Or would that get confusing when people try to google the error message? r? compiler-errors
This comment has been minimized.
This comment has been minimized.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 15, 2024
Rollup merge of rust-lang#131675 - tdittr:update-unsupported-abi-message, r=compiler-errors Update lint message for ABI not supported Tracking issue: rust-lang#130260 As requested in rust-lang#128784 (review) I updated the error message. I could also change it to be the same message as if it was a hard error on a normal function: > "`{abi}` is not a supported ABI for the current target" Or would that get confusing when people try to google the error message? r? compiler-errors
colinmarc
added a commit
to colinmarc/slang-rs
that referenced
this issue
Feb 10, 2025
It's a rustc warning, and will become an error. See: rust-lang/rust#130260
Zalathar
added a commit
to Zalathar/rust
that referenced
this issue
Feb 18, 2025
…in-deps, r=compiler-errors,traviscross Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies Tracking issue: rust-lang#130260 As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies. The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning. r? compiler-errors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Feb 18, 2025
…in-deps, r=compiler-errors,traviscross Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies Tracking issue: rust-lang#130260 As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies. The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning. r? compiler-errors
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Feb 18, 2025
…in-deps, r=compiler-errors,traviscross Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies Tracking issue: rust-lang#130260 As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies. The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning. r? compiler-errors
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Feb 28, 2025
…in-deps, r=compiler-errors Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies Tracking issue: rust-lang#130260 As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies. The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning. r? compiler-errors
jieyouxu
added a commit
to jieyouxu/rust
that referenced
this issue
Feb 28, 2025
…in-deps, r=compiler-errors Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies Tracking issue: rust-lang#130260 As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies. The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning. r? compiler-errors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Mar 3, 2025
…in-deps, r=compiler-errors Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies Tracking issue: rust-lang#130260 As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies. The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning. r? compiler-errors
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 4, 2025
Rollup merge of rust-lang#135767 - tdittr:fn_ptr_calling_conventions-in-deps, r=compiler-errors Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies Tracking issue: rust-lang#130260 As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies. The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning. r? compiler-errors
ElonGaties
added a commit
to ElonGaties/dll-syringe
that referenced
this issue
May 27, 2025
(fixes unsupported_fn_ptr_calling_conventions) rust-lang/rust#130260
rust-bors bot
added a commit
that referenced
this issue
Jun 6, 2025
Reject `extern "{abi}"` when the target does not support it ## What Promote [`unsupported_fn_ptr_calling_conventions`] from a warning to a hard error, making sure edge-cases will not escape. We now emit hard errors for every case we would return `Invalid` from `AbiMap::canonize_abi` during AST to HIR lowering. In particular, these architecture-specific ABIs now only compile on their architectures[^1]: - amdgpu: "gpu-kernel" - arm: "aapcs", "C-cmse-nonsecure-entry" - avr: "avr-interrupt", "avr-non-blocking-interrupt" - msp430: "msp430-interrupt" - nvptx64: "gpu-kernel", "ptx-kernel" - riscv32 and riscv64: "riscv-interrupt-machine", "riscv-interrupt-supervisor" - x86: "thiscall" - x86 and x86_64: "x86-interrupt" - x86_64: "sysv64", "win64" The panoply of ABIs that are logically x86-specific but actually permitted on all Windows targets remain supported on Windows, as they were before. For non-Windows targets they error if the architecture does not match. Moving the check into AST lowering **is itself a breaking change in rare cases**, above and beyond the cases rustc currently warns about. See "Why or Why Not" for details. ## How We modify rustc_ast_lowering to prevent unsupported ABIs from leaking through the HIR without being checked for target support. Previously ad-hoc checking on various HIR items required making sure we check every HIR item which could contain an `extern "{abi}"` string. This is a losing proposition compared to gating the lowering itself. As a consequence, unsupported ABI strings will now hard-error instead of triggering the FCW `unsupported_fn_ptr_calling_conventions`. However, per #86232 this does cause errors for rare usages of `extern "{abi}"` that were theoretically possible to write in Rust source, without previous warning or error. For instance, trait declarations without impls were never checked. These are the exact kinds of leakages that this new approach prevents. This differs from the following PRs: - #141435 is orthogonal, as it adds a new lint for ABIs we have not warned on and are not touched by this PR - #141877 is subsumed by this, in that this simply cuts out bad functionality instead of adding epicycles for stable code ## Why or Why Not We already made the decision to issue the `unsupported_fn_ptr_calling_conventions` future compatibility warning. It has warned in dependencies since #135767, which reached stable with Rust 1.87. That was released on 2025 May 17, and it is now June. As we already had erred on these ABI strings in most other positions, and warn on stable for function pointer types, this breakage has had reasonable foreshadowing. Upgrading the warning to an error addresses a real problem. In some cases the Rust compiler can attempt to actually compute the ABI for calling a function. We could accept this case and compute unsupported ABIs according to some other ABI, silently[^0]. However, this obviously exposes Rust to errors in codegen. We cannot lower directly to the "obvious" ABI and then trust code generators like LLVM to reliably error on these cases, either. Refactoring the compiler so we could defer more ABI computations would be possible, but seems weakly motivated. Even if we succeeded, we would at minimum risk: - exposing the "whack-a-mole" problem but "approaching linking" instead of "leaving AST" - making it harder to reason about functions we *can* lower further - complicating the compiler for no clear benefit A deprecation cycle for the edge-cases could be implemented first, but it is not very useful for such marginal cases, like this trait declaration without a definition: ```rust pub trait UsedToSneakBy { pub extern "gpu-kernel" fn sneaky(); } ``` Upon any impl, even for provided fn within trait declarations, e.g. `pub extern "gpu-kernel" fn sneaky() {}`, different HIR types were used which would, in fact, get checked. Likewise with anything with function pointers. Thus we would be discussing deprecation cycles for code that is impotent or forewarned[^2]. Implementing a deprecation cycle _is_ possible, but it would likely require emitting multiple of a functionally identical warning or error on code that would not have multiple warnings or errors before. It is also not clear to me we would not find **another**, even more marginal edge-case that slipped through, as "things slip through" is the motivation for checking earlier. Additional effort spent on additional warnings should require committing to a hard limit first. r? lang Fixes #86232 Fixes #132430 Fixes #138738 Fixes #142107 [`unsupported_fn_ptr_calling_conventions`]: #130260 [^1]: Some already will not compile, due to reaching ICEs or LLVM errors. [^0]: We already do this for all `AbiStr` we cannot parse, pretending they are `ExternAbi::Rust`, but we also emit an error to prevent reaching too far into codegen. [^2]: It actually did appear in two cases in rustc's test suite because we are a collection of Rust edge-cases by the simple fact that we don't care if the code actually runs. These cases were excised in c1db989.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-ABI
Area: Concerning the application binary interface (ABI)
A-lints
Area: Lints (warnings about flaws in source code) such as unused_mut.
C-future-incompatibility
Category: Future-incompatibility lints
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Uh oh!
There was an error while loading. Please reload this page.
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
This will produce:
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.The text was updated successfully, but these errors were encountered: