Future incompatibility warning unsupported_fn_ptr_calling_conventions: Also warn in dependencies by tdittr · Pull Request #135767 · rust-lang/rust (original) (raw)

@tdittr

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Jan 20, 2025

@compiler-errors compiler-errors added T-lang

Relevant to the language team

S-waiting-on-team

DEPRECATED: Use the team-based variants `S-waiting-on-t-lang`, `S-waiting-on-t-compiler`, ...

and removed T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Jan 23, 2025

@jieyouxu jieyouxu added the S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

label

Mar 1, 2025

@tdittr

This was left to only warn in the current crate to give users a chance to update their code. Now for 1.86 we also warn users depending on those crates.

@tdittr

@tdittr

Otherwise this test will include a future incompatibility warning on some targets but not others.

@tdittr

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Mar 3, 2025

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Mar 3, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request

Mar 4, 2025

@bors

…iaskrgr

Rollup of 12 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Mar 4, 2025

@rust-timer

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 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

github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request

Mar 14, 2025

@bors

…iaskrgr

Rollup of 12 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

flip1995 pushed a commit to flip1995/rust that referenced this pull request

Mar 20, 2025

@bors

…iaskrgr

Rollup of 12 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

GuillaumeGomez pushed a commit to GuillaumeGomez/rust that referenced this pull request

Apr 18, 2025

@bors

…iaskrgr

Rollup of 12 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request

May 19, 2025

@tmeijn

This MR contains the following updates:

Package Update Change
rust minor 1.86.0 -> 1.87.0

MR created with the help of el-capitano/tools/renovate-bot.

Proposed changes to behavior should be submitted there as MRs.

Release Notes

rust-lang/rust (rust)

v1.87.0

Compare Source

==========================

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

This MR has been generated by Renovate Bot.

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

May 20, 2025

@he32

Pkgsrc changes:

Upstream changes relative to 1.86.0:

Version 1.87.0 (2025-05-15)

Language

Compiler

Platform Support

Refer to Rust's platform support page for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These previously stable APIs are now stable in const contexts:

Cargo

Compatibility Notes

Internal Changes

These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools.

rust-bors bot added a commit that referenced this pull request

Jun 6, 2025

@rust-bors

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]:

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:

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:

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:

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

[^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.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Jun 23, 2025

@workingjubilee

…abi, r=jdonszelmann,RalfJung

Reject unsupported extern "{abi}"s consistently in all positions

Modify the handling of extern "{abi}" in the compiler so that it has consistent errors without regard to the position in the grammar.

What

Implement the following breakages:

In particular, these architecture-specific ABIs now only compile on their architectures[^4]:

ABIs that are logically x86-specific but actually permitted on all Windows targets remain permitted on Windows, as before. For non-Windows targets, they error if we had previously done so in other positions.

How

We modify rustc_ast_lowering to prevent unsupported ABIs from leaking through the HIR without being checked for target support. They now emit hard errors for every case where we would return Invalid from AbiMap::canonize_abi. 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 error instead of triggering the warning unsupported_fn_ptr_calling_conventions. The code is also simpler compared to alternative implementations that might e.g. split on unstable vs. stable, only suffering some unavoidable complication to support the newly-revived unsupported_calling_conventions lint.[^5]

However, per rust-lang#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:

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 rust-lang#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 with an unsupported ABI. We could accept this case and compute unsupported ABIs according to some other ABI, silently[^6]. However, this obviously exposes Rust to errors in codegen. We cannot lower directly to the "obvious", target-incorrect ABI and then trust code generators like LLVM to reliably error on these cases, either.

Other considerations include:

pub trait UsedToSneakBy {
    pub extern "gpu-kernel" fn sneaky();
}

r? lang

Fixes rust-lang#86232 Fixes rust-lang#132430 Fixes rust-lang#138738 Fixes rust-lang#142107

[crater run]: rust-lang#142134 (comment) [^9]: 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 for anything with function pointers. Thus we would be discussing deprecation cycles for code that is impotent or forewarned[^7]. [^4]: Some already will not compile, due to reaching ICEs or LLVM errors. [^5]: That lint cannot be moved in a similar way yet because lints operate on HIR, so you cannot emit lints when the HIR has not been completely formed. [^6]: 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. [^7]: 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 are being excised in 643a9d2

rust-timer added a commit that referenced this pull request

Jun 24, 2025

@rust-timer

Rollup merge of #142134 - workingjubilee:reject-unsupported-abi, r=jdonszelmann,RalfJung

Reject unsupported extern "{abi}"s consistently in all positions

Modify the handling of extern "{abi}" in the compiler so that it has consistent errors without regard to the position in the grammar.

What

Implement the following breakages:

In particular, these architecture-specific ABIs now only compile on their architectures[^4]:

ABIs that are logically x86-specific but actually permitted on all Windows targets remain permitted on Windows, as before. For non-Windows targets, they error if we had previously done so in other positions.

How

We modify rustc_ast_lowering to prevent unsupported ABIs from leaking through the HIR without being checked for target support. They now emit hard errors for every case where we would return Invalid from AbiMap::canonize_abi. 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 error instead of triggering the warning unsupported_fn_ptr_calling_conventions. The code is also simpler compared to alternative implementations that might e.g. split on unstable vs. stable, only suffering some unavoidable complication to support the newly-revived unsupported_calling_conventions lint.[^5]

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:

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 with an unsupported ABI. We could accept this case and compute unsupported ABIs according to some other ABI, silently[^6]. However, this obviously exposes Rust to errors in codegen. We cannot lower directly to the "obvious", target-incorrect ABI and then trust code generators like LLVM to reliably error on these cases, either.

Other considerations include:

pub trait UsedToSneakBy {
    pub extern "gpu-kernel" fn sneaky();
}

r? lang

Fixes #86232 Fixes #132430 Fixes #138738 Fixes #142107

[crater run]: #142134 (comment) [^9]: 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 for anything with function pointers. Thus we would be discussing deprecation cycles for code that is impotent or forewarned[^7]. [^4]: Some already will not compile, due to reaching ICEs or LLVM errors. [^5]: That lint cannot be moved in a similar way yet because lints operate on HIR, so you cannot emit lints when the HIR has not been completely formed. [^6]: 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. [^7]: 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 are being excised in 643a9d2