Apply the Cortex-A53 843419 CC mitigation to aarch64 targets by adamgemmell · Pull Request #164752 · rust-lang/rust

adamgemmell · 2026-10-22T15:02:37Z

This PR sets out a strategy for more consistently applying the mitigation for Cortex A53 Errata 843419 to aarch64 targets. See #118095 for more detailed background information on the mitigation itself.

In the last stable release #155453 applied the linker flag for this mitigation (--fix-cortex-a53-843419) to aarch64 linux gnu & musl targets, but this raised two bugs:

Aarch64 broken with gcc not supporting --fix-cortex-a53-843419 linker flag #161486 - old versions of LD (before 2.26 in 2016 I believe) do not support the mitigation and this form of the flag cannot be disabled. The LD version requirement was not detailed in the release notes.
1.98 Build speed regression - GNU ld on arm #164275 - large build time regression. When LD is patched to allow disabling the mitigation, having the mitigation enabled results in a large regression in link time. This is particularly bad for large Rust projects (+327% debug build time for deno) as Rust defaults to -Zfunction-sections=yes for most targets, while Clang defaults to -fno-function-sections. Again, the mitigation cannot be disabled.

This PR does a few things to fix those:

Apply the mitigation by default for all aarch64 targets when using a CC linker driver
Applying the linker driver variant of the flag -mfix-cortex-a53-843419, which can be overridden with -mno-fix-cortex-a53-843419
Attempt an automatic linking retry without the mitigation when the linker or linker driver reports that it isn't aware of the flag. This is particularly an issue with Clang which only added the mitigation control flag in v21.

If a target wishes it can force the mitigation enabled with the linker version of the flag, as fuchsia, nuttx and the bare-metal target do, though this limits the versions of LD that can be used.

As mentioned above in the reproduction guide in #164275 this mitigation results in a large build time regression for rustc crates with more than 128MiB. I haven't reproduced the findings, but the repo does contain a setup for running all the benchmarks detailed. For many users this change won't have an effect as the mitigation is forced on anyway by unpatched versions of LD, or builds of GCC which enable the mitigation (Debian's GCC does this). For users this PR does affect, switching the target to LLD I expect would significantly reduce this compile time regression.

An interesting footnote, Clang does not enable this mitigation by default at all for Linux targets, but does for Android.

r? @lqd

rustbot · 2026-10-22T15:02:41Z

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

These commits modify compiler targets.
(See the Target Tier Policy.)

rustbot · 2026-10-22T15:02:46Z

lqd is not on the review rotation at the moment.
They may take a while to respond.

bjorn3 · 2026-10-22T15:25:35Z


+        let cpu = crate::llvm_util::target_cpu(sess);
+        let apply_a53_mitigation =
+            sess.target.arch == Arch::AArch64 && matches!(cpu, "cortex-a53" | "generic");


Why not put this logic in link_natively directly? You have access to both the architecture (through sess) and target_cpu (through crate_info) there.

View changes since the review

It's because as I understand it the values of target-cpu are backend-specific. For example, the GCC backend passes the value of -Ctarget-cpu through as -march so I think the form of those would be very different

For LLVM crate_info.target_cpu is set to the result of crate::{gcc,llvm}_util::target_cpu() in cg_gcc and cg_llvm. In both cases this is equivalent to the -Ctarget-cpu value (with a fallback to the target cpu in the target spec) unless -Ctarget-cpu=native is used, in which case it would be expanded to whatever value of -Ctarget-cpu would match the native CPU. And for cg_clif the same is done except that it currently doesn't expand -Ctarget-cpu=native. Feel free to change -Ctarget-cpu=native to expand to -Ctarget-cpu=generic on arm64 for cg_clif.

After discussing with @lqd we decided it would be simpler to not check values for target-cpu for now, as this is the only place we would treat them non-transparently. The improvement can still be made in the future if we like once we know more about the impact of the mitigation after migrating to lld

lqd · 2026-10-23T07:58:48Z

In my mind, we fix #161486 and workaround #164275 (users need to opt-out manually) using CC flags, and we can fix #164275 switching the targets to use rust-lld, and avoid gnu ld issues when the mitigations aren't necessary.

Do we need to look at target-cpu, what do we gain from it apart not applying the mitigations when we don't technically need it? We could avoid backend-specific changes here I think and still fix both issues.

rustbot · 2026-10-23T11:40:53Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

lqd · 2026-10-26T08:50:50Z

Looks good. I'm not sure how much testing we should do.

Let's take this as an opportunity to also test bots and aarch64 rustc-perf.

@bors try @rust-timer queue

Apply the Cortex-A53 843419 CC mitigation to aarch64 targets

rust-bors · 2026-10-26T09:54:04Z

☀️ Try build successful (CI)
Build commit: 887a9a5 (887a9a5c1d4a1871517aedcc7bf87e548787bdcd)
Base parent: aaf324d (aaf324d50a7dcb17aae7f2a37e15ff143d980c6e)

adamgemmell · 2026-10-26T10:06:13Z

cc @jonathanpallant who may be familiar with more aarch64 targets than us

rust-timer · 2026-10-26T10:43:25Z

Finished benchmarking commit (887a9a5): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@bors rollup=iffy rustc-perf
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.3%	[-0.5%, -0.0%]	12
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 0.4%, secondary 1.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.4%, 0.8%]	7
Regressions ❌ (secondary)	1.7%	[1.2%, 2.2%]	2
Improvements ✅ (primary)	-0.4%	[-0.5%, -0.4%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-0.5%, 0.8%]	9

Cycles

Results (primary 0.6%, secondary 3.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.9%	[0.4%, 5.0%]	6
Regressions ❌ (secondary)	3.1%	[0.7%, 5.6%]	2
Improvements ✅ (primary)	-0.7%	[-1.2%, -0.4%]	10
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[-1.2%, 5.0%]	16

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.2%]	67
Regressions ❌ (secondary)	0.1%	[0.0%, 0.3%]	56
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.2%]	67

Bootstrap: 488.092s -> 487.754s (-0.07%)
Artifact size: 405.81 MiB -> 406.15 MiB (0.08%)

bjorn3 · 2026-10-26T10:52:34Z

+        && matches!(flavor, LinkerFlavor::Gnu(Cc::Yes, ..))
+    {
+        cmd.cc_arg("-mfix-cortex-a53-843419");
+    }


Shouldn't this be after -Zpre-link-arg?
Edit: I guess not given that the pre_link_args field of the target spec is also before it.

View changes since the review

I think it makes sense for both the target specs and user pre-link-args to be able to override this

lqd · 2026-10-26T11:23:06Z

As expected, there were no surprises in the aarch64 perf results either. (And evidently all the bots and infra for perf runs work perfectly there)

Let's wait a bit for JP's feedback just in case, but then we can land this if nothing new comes up.
Once that happens, you can use r=lqd,bjorn3 to add the PR to the merge queue.

@bors delegate+

rust-bors · 2026-10-26T11:23:10Z

✌️ @adamgemmell, you can now approve this pull request!

If @lqd told you to "r=me" after making some further change, then please make that change and post @bors r=lqd.

View changes since this delegation.

jonathanpallant · 2026-11-02T10:24:24Z

ack (was on vacation last week)

I will discuss with @japaric and the Ferrocene team and get back to you shortly

jonathanpallant · 2026-11-04T07:47:26Z

We don't see this as a problem. Thanks for the ping!

lqd · 2026-11-04T09:55:39Z

Thanks Jonathan and Ferrous.

@bors r=lqd,bjorn3

rust-bors · 2026-11-04T09:55:42Z

📌 Commit 8274e7a has been approved by lqd,bjorn3

It is now in the queue for this repository.

rust-bors · 2026-11-04T10:15:26Z

⌛ Testing commit 8274e7a with merge 98b11ac...

Workflow: https://github.com/rust-lang/rust/actions/runs/41812965116

@lqd

…d,bjorn3 Apply the Cortex-A53 843419 CC mitigation to aarch64 targets This PR sets out a strategy for more consistently applying the mitigation for Cortex A53 Errata 843419 to aarch64 targets. See #118095 for more detailed background information on the mitigation itself. In the last stable release #155453 applied the linker flag for this mitigation (`--fix-cortex-a53-843419`) to aarch64 linux gnu & musl targets, but this raised two bugs: - #161486 - old versions of LD (before 2.26 in 2016 I believe) do not support the mitigation and this form of the flag cannot be disabled. The LD version requirement was not detailed in the release notes. - #164275 - large build time regression. When LD [is patched](https://inbox.sourceware.org/binutils/20260806054354.27168-1-ktkachov@nvidia.com/) to allow disabling the mitigation, having the mitigation enabled results in a large regression in link time. This is particularly bad for large Rust projects (+327% debug build time for deno) as Rust defaults to `-Zfunction-sections=yes` for most targets, while Clang defaults to -`fno-function-sections`. Again, the mitigation cannot be disabled. This PR does a few things to fix those: - Apply the mitigation by default for all aarch64 targets when using a CC linker driver - Applying the linker driver variant of the flag `-mfix-cortex-a53-843419`, which can be overridden with `-mno-fix-cortex-a53-843419` - Attempt an automatic linking retry without the mitigation when the linker or linker driver reports that it isn't aware of the flag. This is particularly an issue with Clang which only [added the mitigation control flag](llvm/llvm-project#143915) in v21. If a target wishes it can force the mitigation enabled with the linker version of the flag, as [fuchsia](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_fuchsia.rs#L24), [nuttx](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_nuttx.rs#L21) and the [bare-metal target](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs#L21) do, though this limits the versions of LD that can be used. As mentioned above in the reproduction guide in #164275 this mitigation results in a large build time regression for rustc crates with more than 128MiB. I haven't reproduced the findings, but the repo does contain a setup for running all the benchmarks detailed. For many users this change won't have an effect as the mitigation is forced on anyway by unpatched versions of LD, or builds of GCC which enable the mitigation (Debian's GCC does this). For users this PR does affect, switching the target to LLD I expect would significantly reduce this compile time regression. An interesting footnote, Clang does not enable this mitigation by default at all for Linux targets, but does for Android. r? @lqd

JonathanBrouwer · 2026-11-04T10:22:23Z

@bors yield

rust-bors · 2026-11-04T10:22:27Z

Auto build was cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/41812965116

The next pull request likely to be tested is #165446.

@lqd

…ation, r=lqd,bjorn3 Apply the Cortex-A53 843419 CC mitigation to aarch64 targets This PR sets out a strategy for more consistently applying the mitigation for Cortex A53 Errata 843419 to aarch64 targets. See rust-lang#118095 for more detailed background information on the mitigation itself. In the last stable release rust-lang#155453 applied the linker flag for this mitigation (`--fix-cortex-a53-843419`) to aarch64 linux gnu & musl targets, but this raised two bugs: - rust-lang#161486 - old versions of LD (before 2.26 in 2016 I believe) do not support the mitigation and this form of the flag cannot be disabled. The LD version requirement was not detailed in the release notes. - rust-lang#164275 - large build time regression. When LD [is patched](https://inbox.sourceware.org/binutils/20260806054354.27168-1-ktkachov@nvidia.com/) to allow disabling the mitigation, having the mitigation enabled results in a large regression in link time. This is particularly bad for large Rust projects (+327% debug build time for deno) as Rust defaults to `-Zfunction-sections=yes` for most targets, while Clang defaults to -`fno-function-sections`. Again, the mitigation cannot be disabled. This PR does a few things to fix those: - Apply the mitigation by default for all aarch64 targets when using a CC linker driver - Applying the linker driver variant of the flag `-mfix-cortex-a53-843419`, which can be overridden with `-mno-fix-cortex-a53-843419` - Attempt an automatic linking retry without the mitigation when the linker or linker driver reports that it isn't aware of the flag. This is particularly an issue with Clang which only [added the mitigation control flag](llvm/llvm-project#143915) in v21. If a target wishes it can force the mitigation enabled with the linker version of the flag, as [fuchsia](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_fuchsia.rs#L24), [nuttx](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_nuttx.rs#L21) and the [bare-metal target](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs#L21) do, though this limits the versions of LD that can be used. As mentioned above in the reproduction guide in rust-lang#164275 this mitigation results in a large build time regression for rustc crates with more than 128MiB. I haven't reproduced the findings, but the repo does contain a setup for running all the benchmarks detailed. For many users this change won't have an effect as the mitigation is forced on anyway by unpatched versions of LD, or builds of GCC which enable the mitigation (Debian's GCC does this). For users this PR does affect, switching the target to LLD I expect would significantly reduce this compile time regression. An interesting footnote, Clang does not enable this mitigation by default at all for Linux targets, but does for Android. r? @lqd

@lqd

…ation, r=lqd,bjorn3 Apply the Cortex-A53 843419 CC mitigation to aarch64 targets This PR sets out a strategy for more consistently applying the mitigation for Cortex A53 Errata 843419 to aarch64 targets. See rust-lang#118095 for more detailed background information on the mitigation itself. In the last stable release rust-lang#155453 applied the linker flag for this mitigation (`--fix-cortex-a53-843419`) to aarch64 linux gnu & musl targets, but this raised two bugs: - rust-lang#161486 - old versions of LD (before 2.26 in 2016 I believe) do not support the mitigation and this form of the flag cannot be disabled. The LD version requirement was not detailed in the release notes. - rust-lang#164275 - large build time regression. When LD [is patched](https://inbox.sourceware.org/binutils/20260806054354.27168-1-ktkachov@nvidia.com/) to allow disabling the mitigation, having the mitigation enabled results in a large regression in link time. This is particularly bad for large Rust projects (+327% debug build time for deno) as Rust defaults to `-Zfunction-sections=yes` for most targets, while Clang defaults to -`fno-function-sections`. Again, the mitigation cannot be disabled. This PR does a few things to fix those: - Apply the mitigation by default for all aarch64 targets when using a CC linker driver - Applying the linker driver variant of the flag `-mfix-cortex-a53-843419`, which can be overridden with `-mno-fix-cortex-a53-843419` - Attempt an automatic linking retry without the mitigation when the linker or linker driver reports that it isn't aware of the flag. This is particularly an issue with Clang which only [added the mitigation control flag](llvm/llvm-project#143915) in v21. If a target wishes it can force the mitigation enabled with the linker version of the flag, as [fuchsia](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_fuchsia.rs#L24), [nuttx](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_nuttx.rs#L21) and the [bare-metal target](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs#L21) do, though this limits the versions of LD that can be used. As mentioned above in the reproduction guide in rust-lang#164275 this mitigation results in a large build time regression for rustc crates with more than 128MiB. I haven't reproduced the findings, but the repo does contain a setup for running all the benchmarks detailed. For many users this change won't have an effect as the mitigation is forced on anyway by unpatched versions of LD, or builds of GCC which enable the mitigation (Debian's GCC does this). For users this PR does affect, switching the target to LLD I expect would significantly reduce this compile time regression. An interesting footnote, Clang does not enable this mitigation by default at all for Linux targets, but does for Android. r? @lqd

…uwer Rollup of 7 pull requests Successful merges: - #164752 (Apply the Cortex-A53 843419 CC mitigation to aarch64 targets ) - #165376 (Add `Forget` trait feature gate) - #165257 (Revert FCW on lint attributes on macro calls) - #165364 (Update books) - #165424 (Update amdgpu datalayout for LLVM 24) - #165443 (Add `Discriminant::ord`) - #165445 (Add an unstable option to increase the chain depth of the next solver overflow FCW)

@lqd

…ation, r=lqd,bjorn3 Apply the Cortex-A53 843419 CC mitigation to aarch64 targets This PR sets out a strategy for more consistently applying the mitigation for Cortex A53 Errata 843419 to aarch64 targets. See rust-lang#118095 for more detailed background information on the mitigation itself. In the last stable release rust-lang#155453 applied the linker flag for this mitigation (`--fix-cortex-a53-843419`) to aarch64 linux gnu & musl targets, but this raised two bugs: - rust-lang#161486 - old versions of LD (before 2.26 in 2016 I believe) do not support the mitigation and this form of the flag cannot be disabled. The LD version requirement was not detailed in the release notes. - rust-lang#164275 - large build time regression. When LD [is patched](https://inbox.sourceware.org/binutils/20260806054354.27168-1-ktkachov@nvidia.com/) to allow disabling the mitigation, having the mitigation enabled results in a large regression in link time. This is particularly bad for large Rust projects (+327% debug build time for deno) as Rust defaults to `-Zfunction-sections=yes` for most targets, while Clang defaults to -`fno-function-sections`. Again, the mitigation cannot be disabled. This PR does a few things to fix those: - Apply the mitigation by default for all aarch64 targets when using a CC linker driver - Applying the linker driver variant of the flag `-mfix-cortex-a53-843419`, which can be overridden with `-mno-fix-cortex-a53-843419` - Attempt an automatic linking retry without the mitigation when the linker or linker driver reports that it isn't aware of the flag. This is particularly an issue with Clang which only [added the mitigation control flag](llvm/llvm-project#143915) in v21. If a target wishes it can force the mitigation enabled with the linker version of the flag, as [fuchsia](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_fuchsia.rs#L24), [nuttx](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_nuttx.rs#L21) and the [bare-metal target](https://github.com/rust-lang/rust/blob/afe686de2708699b69dd31ed14be326f4e95edfc/compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs#L21) do, though this limits the versions of LD that can be used. As mentioned above in the reproduction guide in rust-lang#164275 this mitigation results in a large build time regression for rustc crates with more than 128MiB. I haven't reproduced the findings, but the repo does contain a setup for running all the benchmarks detailed. For many users this change won't have an effect as the mitigation is forced on anyway by unpatched versions of LD, or builds of GCC which enable the mitigation (Debian's GCC does this). For users this PR does affect, switching the target to LLD I expect would significantly reduce this compile time regression. An interesting footnote, Clang does not enable this mitigation by default at all for Linux targets, but does for Android. r? @lqd

…uwer Rollup of 17 pull requests Successful merges: - #164752 (Apply the Cortex-A53 843419 CC mitigation to aarch64 targets ) - #165011 (std: Clean up and improve errors for `is_*_feature_detected` macros) - #165376 (Add `Forget` trait feature gate) - #164482 (Remove the label starting with 0 in the test binary_asm_labels_allowed.rs) - #165201 (Move a bunch of methods out of `AttributeExt`) - #165268 (Fix constant-pattern equality suggestion spans in macros) - #165318 (Fix explicit destructor-call suggestion spans in macros) - #164440 ([Outreachy] alloc: Add test coverage for try_clone_from_ref_in (Box, Arc, Rc)) - #165001 (Document allocator swap in BinaryHeap::append) - #165257 (Revert FCW on lint attributes on macro calls) - #165330 (Impl read_le/read_be for f16 and f128) - #165364 (Update books) - #165414 (Remove unusued query key impl) - #165424 (Update amdgpu datalayout for LLVM 24) - #165440 (docker: bump node to v24.22.2 in shared script) - #165443 (Add `Discriminant::ord`) - #165445 (Add an unstable option to increase the chain depth of the next solver overflow FCW)

rustbot assigned lqd Oct 22, 2026

adamgemmell added the O-AArch64 Armv8-A or later processors in AArch64 mode label Oct 22, 2026

adamgemmell mentioned this pull request Oct 22, 2026

Aarch64 broken with gcc not supporting --fix-cortex-a53-843419 linker flag #161486

Open

bjorn3 reviewed Oct 22, 2026

View reviewed changes

lqd reviewed Oct 23, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_ssa/src/back/link.rs Resolved

adamgemmell added 4 commits October 23, 2026 12:05

Apply reversible compiler driver flag for a53 mitigation when required

737930a

Retry linking if the linker doesn't support the A53 mitigation

d28c750

Omit the mitigation on Apple and Windows targets

0a217f2

Remove unnecessary calls to to_string_lossy()

8274e7a

adamgemmell mentioned this pull request Oct 23, 2026

1.98 Build speed regression - GNU ld on arm #164275

Open

adamgemmell force-pushed the dev/adagem01/a53-mitigation branch from e1c6075 to 8274e7a Compare October 23, 2026 11:40

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 26, 2026

rust-bors Bot pushed a commit that referenced this pull request Oct 26, 2026

Auto merge of #164752 - adamgemmell:dev/adagem01/a53-mitigation, r=<try>

887a9a5

Apply the Cortex-A53 843419 CC mitigation to aarch64 targets

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 26, 2026

bjorn3 reviewed Oct 26, 2026

View reviewed changes

lqd approved these changes Oct 26, 2026

View reviewed changes

rust-bors Bot 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 Nov 4, 2026

JonathanBrouwer mentioned this pull request Nov 4, 2026

Rollup of 8 pull requests #165453

Closed

JonathanBrouwer mentioned this pull request Nov 4, 2026

Rollup of 7 pull requests #165454

Closed

JonathanBrouwer mentioned this pull request Nov 4, 2026

Rollup of 17 pull requests #165464

Open

Conversation

adamgemmell commented Oct 22, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 22, 2026

Uh oh!

rustbot commented Oct 22, 2026

Uh oh!

bjorn3 Oct 22, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lqd commented Oct 23, 2026

Uh oh!

Uh oh!

rustbot commented Oct 23, 2026

Uh oh!

lqd commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Oct 26, 2026

Uh oh!

This comment has been minimized.

adamgemmell commented Oct 26, 2026

Uh oh!

rust-timer commented Oct 26, 2026

Overall result: ✅ improvements - no action needed

Uh oh!

bjorn3 Oct 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lqd commented Oct 26, 2026

Uh oh!

rust-bors Bot commented Oct 26, 2026

Uh oh!

jonathanpallant commented Nov 2, 2026

Uh oh!

jonathanpallant commented Nov 4, 2026

Uh oh!

lqd commented Nov 4, 2026

Uh oh!

rust-bors Bot commented Nov 4, 2026

Uh oh!

rust-bors Bot commented Nov 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JonathanBrouwer commented Nov 4, 2026

Uh oh!

rust-bors Bot commented Nov 4, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

adamgemmell commented Oct 22, 2026 •

edited by rustbot

Loading

bjorn3 Oct 22, 2026 •

edited by rustbot

Loading

lqd commented Oct 26, 2026 •

edited

Loading

bjorn3 Oct 26, 2026 •

edited by rustbot

Loading

rust-bors Bot commented Nov 4, 2026 •

edited

Loading