Add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
#141435
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
These commits modify compiler targets. |
rustbot
added
S-waiting-on-review
RalfJung
force-pushed
the
unsupported_calling_conventions
branch
3 times, most recently
from
f4146aa to
b8f4367
Compare
|
@rust-lang/lang following positive vibes expressed here, I'd like to land this PR as a first step to implement the plan from that issue. Can we get this FCPd? :) The one potential open question here is whether this should be a regular FCW first or whether it can immediately become an FCW that shows up in dependencies. I assume stdcall and fastcall are sufficiently rare that we can go for report-in-deps immediately (since they already get rejected on non-x86-32 non-Windows targets). "cdecl" might be more widely used though so it may be worth ramping up the lint more slowly. |
RalfJung
added
the
I-lang-nominated
traviscross
added
P-lang-drag-1
|
Searching across GitHub, there are 506 Rust file hits on Regarding whether to fire the FCW in deps immediately, I lean toward it probably being OK. Given that this may show up in |
|
Oh that's the syntax for doing such a search... I tried and failed to get a similar result out of github search.^^ |
traviscross
changed the title
unsupported_calling_conventions lint to reject more invalid calling conventions
|
Let's propose to do it. @rfcbot fcp merge |
|
Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rfcbot
added
proposed-final-comment-period
|
@rfcbot reviewed |
|
@rfcbot reviewed I think, in the case of
|
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
traviscross
added
I-lang-radar
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 334ba81 (parent) -> b6685d7 (this PR) Test differencesShow 170 test diffsStage 1
Stage 2
Additionally, 81 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard b6685d748fe4668571c05ba338f61520db6dacc9 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
This was referenced Jun 9, 2025
|
Finished benchmarking commit (b6685d7): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -2.0%, secondary 3.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -6.7%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 755.214s -> 753.257s (-0.26%) |
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
bors
added a commit
that referenced
this pull request
Jun 12, 2025
…r-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss #142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in #141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 12, 2025
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
bors
added a commit
that referenced
this pull request
Jun 13, 2025
…r-abis, r=ChrisDenton,RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss #142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in #141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
github-actions bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Jun 16, 2025
…r-abis, r=ChrisDenton,RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang/rust#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang/rust#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Jun 23, 2025
…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:
- Promote [`unsupported_fn_ptr_calling_conventions`] from a warning to a hard error
- Guarantee future edge-cases like trait declarations will not escape so that *ABIs that have already been unusable in most positions* will now be unusable in **all positions**. See "How" and "Why or Why Not" for more details.
In particular, these architecture-specific ABIs now only compile on their architectures[^4]:
- amdgpu: "gpu-kernel"
- arm: "aapcs", "C-cmse-nonsecure-entry", "C-cmse-nonsecure-call"
- avr: "avr-interrupt", "avr-non-blocking-interrupt"
- msp430: "msp430-interrupt"
- nvptx64: "gpu-kernel", "ptx-kernel"
- riscv32 and riscv64: "riscv-interrupt-m", "riscv-interrupt-s"
- x86: "thiscall"
- x86 and x86_64: "x86-interrupt"
- x86_64: "sysv64", "win64"
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:
- rust-lang#141435 is orthogonal, as it adds a new lint for ABIs we have not warned on and are not touched by this PR
- rust-lang#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 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:
- We could refactor the compiler to defer ABI computations, but that seems like it would suffer the "whack-a-mole" problem close to linking instead of after parsing and expansion.
- We could run a deprecation cycle for the edge cases, but we would be warning highly marginal cases, like this trait declaration without a definition that cannot be implemented without error[^9].
```rust
pub trait UsedToSneakBy {
pub extern "gpu-kernel" fn sneaky();
}
```
- The [crater run] on this PR's draft form suggests the primary issue is with implementations on function pointers, which has already been warned on, so it does not seem like we would be benefiting any real code.
- Converting this to a hard error now, in the same cycle that we ship the reanimation of the `unsupported_calling_conventions` lint, means people who would otherwise have to deal with two lints only have to update their code in one batch. Of course, one of them is as breakage.
r? lang
Fixes rust-lang#86232
Fixes rust-lang#132430
Fixes rust-lang#138738
Fixes rust-lang#142107
[`unsupported_fn_ptr_calling_conventions`]: rust-lang#130260
[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
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: - Promote [`unsupported_fn_ptr_calling_conventions`] from a warning to a hard error - Guarantee future edge-cases like trait declarations will not escape so that *ABIs that have already been unusable in most positions* will now be unusable in **all positions**. See "How" and "Why or Why Not" for more details. In particular, these architecture-specific ABIs now only compile on their architectures[^4]: - amdgpu: "gpu-kernel" - arm: "aapcs", "C-cmse-nonsecure-entry", "C-cmse-nonsecure-call" - avr: "avr-interrupt", "avr-non-blocking-interrupt" - msp430: "msp430-interrupt" - nvptx64: "gpu-kernel", "ptx-kernel" - riscv32 and riscv64: "riscv-interrupt-m", "riscv-interrupt-s" - x86: "thiscall" - x86 and x86_64: "x86-interrupt" - x86_64: "sysv64", "win64" 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: - #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 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: - We could refactor the compiler to defer ABI computations, but that seems like it would suffer the "whack-a-mole" problem close to linking instead of after parsing and expansion. - We could run a deprecation cycle for the edge cases, but we would be warning highly marginal cases, like this trait declaration without a definition that cannot be implemented without error[^9]. ```rust pub trait UsedToSneakBy { pub extern "gpu-kernel" fn sneaky(); } ``` - The [crater run] on this PR's draft form suggests the primary issue is with implementations on function pointers, which has already been warned on, so it does not seem like we would be benefiting any real code. - Converting this to a hard error now, in the same cycle that we ship the reanimation of the `unsupported_calling_conventions` lint, means people who would otherwise have to deal with two lints only have to update their code in one batch. Of course, one of them is as breakage. r? lang Fixes #86232 Fixes #132430 Fixes #138738 Fixes #142107 [`unsupported_fn_ptr_calling_conventions`]: #130260 [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
wip-sync
pushed a commit
to NetBSD/pkgsrc-wip
that referenced
this pull request
Aug 11, 2025
Pkgsrc changes: * Adjust patches to adapt to upstream changes and new versions. * assosicated checksums Upstream changes relative to 1.88.0: Version 1.89.0 (2025-08-07) ========================== Language -------- - [Stabilize explicitly inferred const arguments (`feature(generic_arg_infer)`)] (rust-lang/rust#141610) - [Add a warn-by-default `mismatched_lifetime_syntaxes` lint.] (rust-lang/rust#138677) This lint detects when the same lifetime is referred to by different syntax categories between function arguments and return values, which can be confusing to read, especially in unsafe code. This lint supersedes the warn-by-default `elided_named_lifetimes` lint. - [Expand `unpredictable_function_pointer_comparisons` to also lint on function pointer comparisons in external macros] (rust-lang/rust#134536) - [Make the `dangerous_implicit_autorefs` lint deny-by-default] (rust-lang/rust#141661) - [Stabilize the avx512 target features] (rust-lang/rust#138940) - [Stabilize `kl` and `widekl` target features for x86] (rust-lang/rust#140766) - [Stabilize `sha512`, `sm3` and `sm4` target features for x86] (rust-lang/rust#140767) - [Stabilize LoongArch target features `f`, `d`, `frecipe`, `lasx`, `lbt`, `lsx`, and `lvz`] (rust-lang/rust#135015) - [Remove `i128` and `u128` from `improper_ctypes_definitions`] (rust-lang/rust#137306) - [Stabilize `repr128` (`#[repr(u128)]`, `#[repr(i128)]`)] (rust-lang/rust#138285) - [Allow `#![doc(test(attr(..)))]` everywhere] (rust-lang/rust#140560) - [Extend temporary lifetime extension to also go through tuple struct and tuple variant constructors] (rust-lang/rust#140593) Compiler -------- - [Default to non-leaf frame pointers on aarch64-linux] (rust-lang/rust#140832) - [Enable non-leaf frame pointers for Arm64EC Windows] (rust-lang/rust#140862) - [Set Apple frame pointers by architecture] (rust-lang/rust#141797) Platform Support ---------------- - [Add new Tier-3 targets `loongarch32-unknown-none` and `loongarch32-unknown-none-softfloat`] (rust-lang/rust#142053) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html Libraries --------- - [Specify the base path for `file!`] (rust-lang/rust#134442) - [Allow storing `format_args!()` in a variable] (rust-lang/rust#140748) - [Add `#[must_use]` to `[T; N]::map`] (rust-lang/rust#140957) - [Implement `DerefMut` for `Lazy{Cell,Lock}`] (rust-lang/rust#129334) - [Implement `Default` for `array::IntoIter`] (rust-lang/rust#141574) - [Implement `Clone` for `slice::ChunkBy`] (rust-lang/rust#138016) - [Implement `io::Seek` for `io::Take`] (rust-lang/rust#138023) Stabilized APIs --------------- - [`NonZero<char>`] (https://doc.rust-lang.org/stable/std/num/struct.NonZero.html) - Many intrinsics for x86, not enumerated here - [AVX512 intrinsics](rust-lang/rust#111137) - [`SHA512`, `SM3` and `SM4` intrinsics] (rust-lang/rust#126624) - [`File::lock`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock) - [`File::lock_shared`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock_shared) - [`File::try_lock`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock) - [`File::try_lock_shared`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock_shared) - [`File::unlock`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.unlock) - [`NonNull::from_ref`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_ref) - [`NonNull::from_mut`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_mut) - [`NonNull::without_provenance`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.without_provenance) - [`NonNull::with_exposed_provenance`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.with_exposed_provenance) - [`NonNull::expose_provenance`] (https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.expose_provenance) - [`OsString::leak`] (https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.leak) - [`PathBuf::leak`] (https://doc.rust-lang.org/stable/std/path/struct.PathBuf.html#method.leak) - [`Result::flatten`] (https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.flatten) - [`std::os::linux::net::TcpStreamExt::quickack`] (https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.quickack) - [`std::os::linux::net::TcpStreamExt::set_quickack`] (https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.set_quickack) These previously stable APIs are now stable in const contexts: - [`<[T; N]>::as_mut_slice`] (https://doc.rust-lang.org/stable/std/primitive.array.html#method.as_mut_slice) - [`<[u8]>::eq_ignore_ascii_case`] (https://doc.rust-lang.org/stable/std/primitive.slice.html#impl-%5Bu8%5D/method.eq_ignore_ascii_case) - [`str::eq_ignore_ascii_case`] (https://doc.rust-lang.org/stable/std/primitive.str.html#impl-str/method.eq_ignore_ascii_case) Cargo ----- - [`cargo fix` and `cargo clippy --fix` now default to the same Cargo target selection as other build commands.] (rust-lang/cargo#15192) Previously it would apply to all targets (like binaries, examples, tests, etc.). The `--edition` flag still applies to all targets. - [Stabilize doctest-xcompile.] (rust-lang/cargo#15462) Doctests are now tested when cross-compiling. Just like other tests, it will use the [`runner` setting] (https://doc.rust-lang.org/cargo/reference/config.html#targettriplerunner) to run the tests. If you need to disable tests for a target, you can use the [ignore doctest attribute] (https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html#ignoring-targets) to specify the targets to ignore. Rustdoc ----- - [On mobile, make the sidebar full width and linewrap] (rust-lang/rust#139831). This makes long section and item names much easier to deal with on mobile. Compatibility Notes ------------------- - [Make `missing_fragment_specifier` an unconditional error] (rust-lang/rust#128425) - [Enabling the `neon` target feature on `aarch64-unknown-none-softfloat` causes a warning] (rust-lang/rust#135160) because mixing code with and without that target feature is not properly supported by LLVM - [Sized Hierarchy: Part I](rust-lang/rust#137944) - Introduces a small breaking change affecting `?Sized` bounds on impls on recursive types which contain associated type projections. It is not expected to affect any existing published crates. Can be fixed by refactoring the involved types or opting into the `sized_hierarchy` unstable feature. See the [FCP report] (rust-lang/rust#137944 (comment)) for a code example. - The warn-by-default `elided_named_lifetimes` lint is [superseded by the warn-by-default `mismatched_lifetime_syntaxes` lint.] (rust-lang/rust#138677) - [Error on recursive opaque types earlier in the type checker] (rust-lang/rust#139419) - [Type inference side effects from requiring element types of array repeat expressions are `Copy` are now only available at the end of type checking] (rust-lang/rust#139635) - [The deprecated accidentally-stable `std::intrinsics::{copy,copy_nonoverlapping,write_bytes}` are now proper intrinsics] (rust-lang/rust#139916). There are no debug assertions guarding against UB, and they cannot be coerced to function pointers. - [Remove long-deprecated `std::intrinsics::drop_in_place`] (rust-lang/rust#140151) - [Make well-formedness predicates no longer coinductive] (rust-lang/rust#140208) - [Remove hack when checking impl method compatibility] (rust-lang/rust#140557) - [Remove unnecessary type inference due to built-in trait object impls] (rust-lang/rust#141352) - [Lint against "stdcall", "fastcall", and "cdecl" on non-x86-32 targets] (rust-lang/rust#141435) - [Future incompatibility warnings relating to the never type (`!`) are now reported in dependencies] (rust-lang/rust#141937) - [Ensure `std::ptr::copy_*` intrinsics also perform the static self-init checks] (rust-lang/rust#142575) 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. - [Correctly un-remap compiler sources paths with the `rustc-dev` component] (rust-lang/rust#142377)
tmeijn
pushed a commit
to tmeijn/dotfiles
that referenced
this pull request
Aug 12, 2025
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.88.0` -> `1.89.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>rust-lang/rust (rust)</summary> ### [`v1.89.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1890-2025-08-07) [Compare Source](rust-lang/rust@1.88.0...1.89.0) \========================== <a id="1.89.0-Language"></a> ## Language - [Stabilize explicitly inferred const arguments (`feature(generic_arg_infer)`)](rust-lang/rust#141610) - [Add a warn-by-default `mismatched_lifetime_syntaxes` lint.](rust-lang/rust#138677) This lint detects when the same lifetime is referred to by different syntax categories between function arguments and return values, which can be confusing to read, especially in unsafe code. This lint supersedes the warn-by-default `elided_named_lifetimes` lint. - [Expand `unpredictable_function_pointer_comparisons` to also lint on function pointer comparisons in external macros](rust-lang/rust#134536) - [Make the `dangerous_implicit_autorefs` lint deny-by-default](rust-lang/rust#141661) - [Stabilize the avx512 target features](rust-lang/rust#138940) - [Stabilize `kl` and `widekl` target features for x86](rust-lang/rust#140766) - [Stabilize `sha512`, `sm3` and `sm4` target features for x86](rust-lang/rust#140767) - [Stabilize LoongArch target features `f`, `d`, `frecipe`, `lasx`, `lbt`, `lsx`, and `lvz`](rust-lang/rust#135015) - [Remove `i128` and `u128` from `improper_ctypes_definitions`](rust-lang/rust#137306) - [Stabilize `repr128` (`#[repr(u128)]`, `#[repr(i128)]`)](rust-lang/rust#138285) - [Allow `#![doc(test(attr(..)))]` everywhere](rust-lang/rust#140560) - [Extend temporary lifetime extension to also go through tuple struct and tuple variant constructors](rust-lang/rust#140593) - [`extern "C"` functions on the `wasm32-unknown-unknown` target now have a standards compliant ABI](https://blog.rust-lang.org/2025/04/04/c-abi-changes-for-wasm32-unknown-unknown/) <a id="1.89.0-Compiler"></a> ## Compiler - [Default to non-leaf frame pointers on aarch64-linux](rust-lang/rust#140832) - [Enable non-leaf frame pointers for Arm64EC Windows](rust-lang/rust#140862) - [Set Apple frame pointers by architecture](rust-lang/rust#141797) <a id="1.89.0-Platform-Support"></a> ## Platform Support - [Add new Tier-3 targets `loongarch32-unknown-none` and `loongarch32-unknown-none-softfloat`](rust-lang/rust#142053) - [`x86_64-apple-darwin` is in the process of being demoted to Tier 2 with host tools](rust-lang/rfcs#3841) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html <a id="1.89.0-Libraries"></a> ## Libraries - [Specify the base path for `file!`](rust-lang/rust#134442) - [Allow storing `format_args!()` in a variable](rust-lang/rust#140748) - [Add `#[must_use]` to `[T; N]::map`](rust-lang/rust#140957) - [Implement `DerefMut` for `Lazy{Cell,Lock}`](rust-lang/rust#129334) - [Implement `Default` for `array::IntoIter`](rust-lang/rust#141574) - [Implement `Clone` for `slice::ChunkBy`](rust-lang/rust#138016) - [Implement `io::Seek` for `io::Take`](rust-lang/rust#138023) <a id="1.89.0-Stabilized-APIs"></a> ## Stabilized APIs - [`NonZero<char>`](https://doc.rust-lang.org/stable/std/num/struct.NonZero.html) - Many intrinsics for x86, not enumerated here - [AVX512 intrinsics](rust-lang/rust#111137) - [`SHA512`, `SM3` and `SM4` intrinsics](rust-lang/rust#126624) - [`File::lock`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock) - [`File::lock_shared`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.lock_shared) - [`File::try_lock`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock) - [`File::try_lock_shared`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.try_lock_shared) - [`File::unlock`](https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.unlock) - [`NonNull::from_ref`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_ref) - [`NonNull::from_mut`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.from_mut) - [`NonNull::without_provenance`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.without_provenance) - [`NonNull::with_exposed_provenance`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.with_exposed_provenance) - [`NonNull::expose_provenance`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.expose_provenance) - [`OsString::leak`](https://doc.rust-lang.org/stable/std/ffi/struct.OsString.html#method.leak) - [`PathBuf::leak`](https://doc.rust-lang.org/stable/std/path/struct.PathBuf.html#method.leak) - [`Result::flatten`](https://doc.rust-lang.org/stable/std/result/enum.Result.html#method.flatten) - [`std::os::linux::net::TcpStreamExt::quickack`](https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.quickack) - [`std::os::linux::net::TcpStreamExt::set_quickack`](https://doc.rust-lang.org/stable/std/os/linux/net/trait.TcpStreamExt.html#tymethod.set_quickack) These previously stable APIs are now stable in const contexts: - [`<[T; N]>::as_mut_slice`](https://doc.rust-lang.org/stable/std/primitive.array.html#method.as_mut_slice) - [`<[u8]>::eq_ignore_ascii_case`](https://doc.rust-lang.org/stable/std/primitive.slice.html#impl-%5Bu8%5D/method.eq_ignore_ascii_case) - [`str::eq_ignore_ascii_case`](https://doc.rust-lang.org/stable/std/primitive.str.html#impl-str/method.eq_ignore_ascii_case) <a id="1.89.0-Cargo"></a> ## Cargo - [`cargo fix` and `cargo clippy --fix` now default to the same Cargo target selection as other build commands.](rust-lang/cargo#15192) Previously it would apply to all targets (like binaries, examples, tests, etc.). The `--edition` flag still applies to all targets. - [Stabilize doctest-xcompile.](rust-lang/cargo#15462) Doctests are now tested when cross-compiling. Just like other tests, it will use the [`runner` setting](https://doc.rust-lang.org/cargo/reference/config.html#targettriplerunner) to run the tests. If you need to disable tests for a target, you can use the [ignore doctest attribute](https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html#ignoring-targets) to specify the targets to ignore. <a id="1.89.0-Rustdoc"></a> ## Rustdoc - [On mobile, make the sidebar full width and linewrap](rust-lang/rust#139831). This makes long section and item names much easier to deal with on mobile. <a id="1.89.0-Compatibility-Notes"></a> ## Compatibility Notes - [Make `missing_fragment_specifier` an unconditional error](rust-lang/rust#128425) - [Enabling the `neon` target feature on `aarch64-unknown-none-softfloat` causes a warning](rust-lang/rust#135160) because mixing code with and without that target feature is not properly supported by LLVM - [Sized Hierarchy: Part I](rust-lang/rust#137944) - Introduces a small breaking change affecting `?Sized` bounds on impls on recursive types which contain associated type projections. It is not expected to affect any existing published crates. Can be fixed by refactoring the involved types or opting into the `sized_hierarchy` unstable feature. See the [FCP report](rust-lang/rust#137944 (comment)) for a code example. - The warn-by-default `elided_named_lifetimes` lint is [superseded by the warn-by-default `mismatched_lifetime_syntaxes` lint.](rust-lang/rust#138677) - [Error on recursive opaque types earlier in the type checker](rust-lang/rust#139419) - [Type inference side effects from requiring element types of array repeat expressions are `Copy` are now only available at the end of type checking](rust-lang/rust#139635) - [The deprecated accidentally-stable `std::intrinsics::{copy,copy_nonoverlapping,write_bytes}` are now proper intrinsics](rust-lang/rust#139916). There are no debug assertions guarding against UB, and they cannot be coerced to function pointers. - [Remove long-deprecated `std::intrinsics::drop_in_place`](rust-lang/rust#140151) - [Make well-formedness predicates no longer coinductive](rust-lang/rust#140208) - [Remove hack when checking impl method compatibility](rust-lang/rust#140557) - [Remove unnecessary type inference due to built-in trait object impls](rust-lang/rust#141352) - [Lint against "stdcall", "fastcall", and "cdecl" on non-x86-32 targets](rust-lang/rust#141435) - [Future incompatibility warnings relating to the never type (`!`) are now reported in dependencies](rust-lang/rust#141937) - [Ensure `std::ptr::copy_*` intrinsics also perform the static self-init checks](rust-lang/rust#142575) - [`extern "C"` functions on the `wasm32-unknown-unknown` target now have a standards compliant ABI](https://blog.rust-lang.org/2025/04/04/c-abi-changes-for-wasm32-unknown-unknown/) <a id="1.89.0-Internal-Changes"></a> ## 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. - [Correctly un-remap compiler sources paths with the `rustc-dev` component](rust-lang/rust#142377) </details> --- ### 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. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS41NS4yIiwidXBkYXRlZEluVmVyIjoiNDEuNTUuMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90Il19-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds back the
unsupported_calling_conventionslint that was removed in #129935, in order to start the process of dealing with #137018. Specifically, we are going for the plan laid out here:The difference to the status quo is that:
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the
unsupported_calling_conventionsforward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various