replace box_new with lower-level intrinsics by RalfJung · Pull Request #148190 · rust-lang/rust

RalfJung · 2025-10-27T21:27:43Z

The box_new intrinsic is super special: during THIR construction it turns into an ExprKind::Box (formerly known as the box keyword), which then during MIR building turns into a special instruction sequence that invokes the exchange_malloc lang item (which has a name from a different time) and a special MIR statement to represent a shallowly-initialized Box (which raises interesting opsem questions).

This PR is the n-th attempt to get rid of box_new. That's non-trivial because it usually causes a perf regression: replacing box_new by naive unsafe code will incur extra copies in debug builds, making the resulting binaries a lot slower, and will generate a lot more MIR, making compilation measurably slower. Furthermore, vec! is a macro, so the exact code it expands to is highly relevant for borrow checking, type inference, and temporary scopes.

To avoid those problems, this PR does its best to make the MIR almost exactly the same as what it was before. box_new is used in two places, Box::new and vec!:

For Box::new that is fairly easy: the move_by_value intrinsic is basically all we need. However, to avoid the extra copy that would usually be generated for the argument of a function call, we need to special-case this intrinsic during MIR building. That's what the first commit does.
vec! is a lot more tricky. As a macro, its details leak to stable code, so almost every variant I tried broke either type inference or the lifetimes of temporaries in some ui test or ended up accepting unsound code due to the borrow checker not enforcing all the constraints I hoped it would enforce. I ended up with a variant that involves a new intrinsic, fn write_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<MaybeUninit<T>>, that writes a value into a Box<MaybeUninit<T>> and returns that box again. In exchange we can get rid of somewhat similar code in the lowering for ExprKind::Box, and the exchange_malloc lang item. (We can also get rid of Rvalue::ShallowInitBox; I didn't include that in this PR -- I think @cjgillot has a commit for this somewhere around here.)

See here for the latest perf numbers. Most of the regressions are in deep-vector which consists entirely of an invocation of vec!, so any change to that macro affects this benchmark disproportionally.

This is my first time even looking at MIR building code, so I am very low confidence in that part of the patch, in particular when it comes to scopes and drops and things like that.

I also had do nerf some clippy tests because clippy gets confused by the new expansion of vec! so it makes fewer suggestions when vec! is involved.

`vec!` FAQ

Why does write_box_via_move return the Box again? Because we need to expand vec! to a bunch of method invocations without any blocks or let-statements, or else the temporary scopes (and type inference) don't work out.
Why is box_assume_init_into_vec_unsafe (unsoundly!) a safe function? Because we can't use an unsafe block in vec! as that would necessarily also include the $x (due to it all being one big method invocation) and therefore interpret the user's code as being inside unsafe, which would be bad (and 10 years later, we still don't have safe blocks for macros like this).
Why does write_box_via_move use Box as input/output type, and not, say, raw pointers? Because that is the only way to get the correct behavior when $x panics or has control effects: we need the Box to be dropped in that case. (As a nice side-effect this also makes the intrinsic safe, which is imported as explained in the previous bullet.)
Can't we make it safe by having write_box_via_move return Box<T>? Yes we could, but there's no easy way for the intrinsic to convert its Box<MaybeUninit<T>> to a Box<T>. Transmuting would be unsound as the borrow checker would no longer properly enforce that lifetimes involved in a vec! invocation behave correctly.
Is this macro truly cursed? Yes, yes it is.

rustbot · 2025-10-27T21:27:47Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

Some changes occurred in match checking

cc @Nadrieril

rustbot · 2025-10-27T21:27:49Z

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

RalfJung · 2025-10-27T21:29:14Z

compiler/rustc_borrowck/src/type_check/mod.rs

+                        //         rvalue,
+                        //         "Unexpected CastKind::Transmute {ty_from:?} -> {ty:?}, which is not permitted in Analysis MIR",
+                        //     ),
+                        // }


This obviously needs to be resolved before landing... what should we do here? A transmute cast is always well-typed (it is UB if the sizes mismatch), so... can we just do nothing? I don't know what the type checker inside borrow checker is about.^^

MIR typeck exists to collect all the lifetime constraints for borrowck to check. It also acts as a little bit of a double-check that typechecking on HIR actually checked everything it was supposed to, in some sense it's kind of the "soundness critical typeck". Having this do nothing seems fine to me, there's nothing to really typeck here

Do we need to still visit the cast type to find any lifetimes in there, or so?

FWIW this "is not permitted in Analysis MIR" part in the error I am removing here is odd as this is not documented in the MIR syntax where we usually list such restrictions, and also not checked by the MIR validator.

Do we need to still visit the cast type to find any lifetimes in there, or so?

I don't think so, that should be handled by the super_rvalue call at the top of this visit_rvalue fn

I guess we do need to check something here, right now nothing enforces that the lifetimes match for the various uses of T in init_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<T>.

RalfJung · 2025-10-27T21:30:52Z

compiler/rustc_mir_build/src/builder/expr/into.rs

+                        // Make sure `StorageDead` gets emitted.
+                        this.schedule_drop_storage_and_value(expr_span, this.local_scope(), ptr);


Here I am completely guessing... well really for all the changes in this file I am guessing, but the drop/storage scope stuff I know even less about than the rest of this.

RalfJung · 2025-10-27T21:31:18Z

compiler/rustc_mir_build/src/builder/expr/into.rs

+                            block,
+                            source_info,
+                            Place::from(ptr),
+                            // Needs to be a `Copy` so that `b` still gets dropped if `val` panics.


I added a Miri test to ensure the drop does indeed happen. That's the easiest way to check for memory leaks...

RalfJung · 2025-10-27T21:32:10Z

library/alloc/src/boxed.rs

+        // Nothing below can panic so we do not have to worry about deallocating `ptr`.
+        // SAFETY: we just allocated the box to store `x`.
+        unsafe { core::intrinsics::write_via_move(ptr, x) };
+        // SAFETY: we just initialized `b`.
+        unsafe { mem::transmute(ptr) }


I tried using init_box_via_move here instead and it makes things a bit slower in some secondary benchmarks. I have no idea why.

Do you mean write_box_via_move? Is the "bit slower" acceptable to simplify the implementation?

Should new_in and new_uninit_in get the same kind of inlined implementation?

Do you mean write_box_via_move?

Yeah. (I renamed that intrinsic since writing the comment.)

Is the "bit slower" acceptable to simplify the implementation?

It doesn't simplify it by much, does it? Also it clearly leaves write_box_via_move as a vec!-only hack which I like.

Should new_in and new_uninit_in get the same kind of inlined implementation?

That seems orthogonal to this PR. They didn't use box_new before and are not involved with vec! either.

RalfJung · 2025-10-27T21:33:50Z

...s/mir-opt/building/uniform_array_move_out.move_out_by_subslice.CleanupPostBorrowck.after.mir

This MIR is apparently so different from the previous one that it doesn't even show a diff (and the filename changed since I had to use CleanupPostBorrowck as built contains user types which contain super fragile DefIds). I have no idea what this test is testing and there are no filecheck annotations so... 😨

RalfJung · 2025-10-27T21:35:12Z

tests/mir-opt/dont_reset_cast_kind_without_updating_operand.test.GVN.64bit.panic-abort.diff

Are these changes fine? Who knows! At least the filecheck annotations in the test still pass.

This is a regression test for an ICE where GVN would cast with wrong types. We only check a cast, the rest is boilerplate from inlining.

RalfJung · 2025-10-27T21:38:30Z

tests/mir-opt/issue_62289.test.ElaborateDrops.before.panic-abort.mir

+        StorageDead(_10);
+        StorageDead(_8);
+        StorageDead(_4);
+        drop(_3) -> [return: bb10, unwind: bb15];


I think this is the relevant drop... but the before drop-elaboration MIR makes this quite hard to say. No idea why that's what the test checks. I think after drop elaboration this is a lot more obvious as the drops of moved-out variables are gone.

rustbot · 2025-10-28T07:22:52Z

This PR modifies tests/ui/issues/. If this PR is adding new tests to tests/ui/issues/,
please refrain from doing so, and instead add it to more descriptive subdirectories.

RalfJung · 2025-10-28T07:24:18Z

tests/ui/nll/borrowck-annotate-static-lifetime.rs

This is fully a duplicate of something already tested in nll/user-annotations/patterns.rs.

RalfJung · 2025-10-28T07:25:16Z

tests/ui/nll/user-annotations/patterns.rs

+    // FIXME: What is happening?!??
    let _: Vec<&'static String> = vec![&String::new()];
-    //~^ ERROR temporary value dropped while borrowed [E0716]

    let (_, a): (Vec<&'static String>, _) = (vec![&String::new()], 44);
-    //~^ ERROR temporary value dropped while borrowed [E0716]

    let (_a, b): (Vec<&'static String>, _) = (vec![&String::new()], 44);
-    //~^ ERROR temporary value dropped while borrowed [E0716]
 }


I have no idea what is happening here -- somehow code like let _: Vec<&'static String> = vec![&String::new()]; now compiles. I guess something is wrong with how I am lowering init_box_via_move?

It's probably related to the transmutes there. Is there some way to insert those in a way that the lifetime constraints still get enforced?

RalfJung · 2025-10-28T11:12:48Z

I can't think of any way to actually preserve these lifetimes while using transmutes... so we'll have to add more method calls to vec!, which will show up in perf. On the plus side it seems I misunderstood the errors I saw before regarding temporary scopes around vec!... or may our test suite just can't reproduce those problems.

So here's another redesign of the vec! macro. Macros were a mistake, and this one in particular has turned into my worst nightmare...

@bors try
@rust-timer queue

replace box_new with lower-level intrinsics

@cjgillot

replace box_new with lower-level intrinsics The `box_new` intrinsic is super special: during THIR construction it turns into an `ExprKind::Box` (formerly known as the `box` keyword), which then during MIR building turns into a special instruction sequence that invokes the exchange_malloc lang item (which has a name from a different time) and a special MIR statement to represent a shallowly-initialized `Box` (which raises [interesting opsem questions](#97270)). This PR is the n-th attempt to get rid of `box_new`. That's non-trivial because it usually causes a perf regression: replacing `box_new` by naive unsafe code will incur extra copies in debug builds, making the resulting binaries a lot slower, and will generate a lot more MIR, making compilation measurably slower. Furthermore, `vec!` is a macro, so the exact code it expands to is highly relevant for borrow checking, type inference, and temporary scopes. To avoid those problems, this PR does its best to make the MIR almost exactly the same as what it was before. `box_new` is used in two places, `Box::new` and `vec!`: - For `Box::new` that is fairly easy: the `move_by_value` intrinsic is basically all we need. However, to avoid the extra copy that would usually be generated for the argument of a function call, we need to special-case this intrinsic during MIR building. That's what the first commit does. - `vec!` is a lot more tricky. As a macro, its details leak to stable code, so almost every variant I tried broke either type inference or the lifetimes of temporaries in some ui test or ended up accepting unsound code due to the borrow checker not enforcing all the constraints I hoped it would enforce. I ended up with a variant that involves a new intrinsic, `fn write_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<MaybeUninit<T>>`, that writes a value into a `Box<MaybeUninit<T>>` and returns that box again. In exchange we can get rid of somewhat similar code in the lowering for `ExprKind::Box`, and the `exchange_malloc` lang item. (We can also get rid of `Rvalue::ShallowInitBox`; I didn't include that in this PR -- I think @cjgillot has a commit for this somewhere.) See [here](#148190 (comment)) for the latest perf numbers. Most of the regressions are in deep-vector which consists entirely of an invocation of `vec!`, so any change to that macro affects this benchmark disproportionally. This is my first time even looking at MIR building code, so I am very low confidence in that part of the patch, in particular when it comes to scopes and drops and things like that. I also had do nerf some clippy tests because clippy gets confused by the new expansion of `vec!` so it makes fewer suggestions when `vec!` is involved. ### `vec!` FAQ - Why does `write_box_via_move` return the `Box` again? Because we need to expand `vec!` to a bunch of method invocations without any blocks or let-statements, or else the temporary scopes (and type inference) don't work out. - Why is `box_assume_init_into_vec_unsafe` (unsoundly!) a safe function? Because we can't use an unsafe block in `vec!` as that would necessarily also include the `$x` (due to it all being one big method invocation) and therefore interpret the user's code as being inside `unsafe`, which would be bad (and 10 years later, we still don't have safe blocks for macros like this). - Why does `write_box_via_move` use `Box` as input/output type, and not, say, raw pointers? Because that is the only way to get the correct behavior when `$x` panics or has control effects: we need the `Box` to be dropped in that case. (As a nice side-effect this also makes the intrinsic safe, which is imported as explained in the previous bullet.) - Can't we make it safe by having `write_box_via_move` return `Box<T>`? Yes we could, but there's no easy way for the intrinsic to convert its `Box<MaybeUninit<T>>` to a `Box<T>`. Transmuting would be unsound as the borrow checker would no longer properly enforce that lifetimes involved in a `vec!` invocation behave correctly. - Is this macro truly cursed? Yes, yes it is.

rust-bors · 2026-02-16T15:32:35Z

💔 Test for 27e09ac failed: CI. Failed job:

auto - test-various (web logs, enhanced plaintext logs)

This allows us to get rid of box_new entirely

RalfJung · 2026-02-16T16:32:34Z

@bors r+

rust-bors · 2026-02-16T16:32:37Z

📌 Commit 0df1764 has been approved by RalfJung

It is now in the queue for this repository.

rust-bors · 2026-02-16T22:27:54Z

☀️ Test successful - CI
Approved by: RalfJung
Duration: 3h 41m 34s
Pushing 3c9faa0 to main...

github-actions · 2026-02-16T22:30:20Z

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 71e0027 (parent) -> 3c9faa0 (this PR)

Test differences

Show 280 test diffs

Stage 1

[mir-opt] tests/mir-opt/box_expr.rs: pass -> [missing] (J0)
[mir-opt] tests/mir-opt/building/write_box_via_move.rs: [missing] -> pass (J0)
[mir-opt] tests/mir-opt/building/write_via_move.rs: [missing] -> pass (J0)
[mir-opt] tests/mir-opt/const_prop/boxes.rs: pass -> [missing] (J0)
[ui] tests/ui/coercion/vec-macro-coercions.rs: [missing] -> pass (J0)
[ui] tests/ui/error-codes/E0010-teach.rs: pass -> [missing] (J0)
[ui] tests/ui/error-codes/E0010.rs: pass -> [missing] (J0)
[ui] tests/ui/nll/borrowck-annotate-static-lifetime.rs: pass -> [missing] (J0)
[ui] tests/ui/span/issue-15480.rs: pass -> [missing] (J0)
[ui] tests/ui/span/vec-macro-outlives-issue-15480.rs: [missing] -> pass (J0)
[ui] tests/ui/unpretty/box.rs: pass -> [missing] (J0)

Stage 2

[ui] tests/ui/coercion/vec-macro-coercions.rs: [missing] -> pass (J1)
[ui] tests/ui/error-codes/E0010-teach.rs: pass -> [missing] (J1)
[ui] tests/ui/error-codes/E0010.rs: pass -> [missing] (J1)
[ui] tests/ui/nll/borrowck-annotate-static-lifetime.rs: pass -> [missing] (J1)
[ui] tests/ui/span/issue-15480.rs: pass -> [missing] (J1)
[ui] tests/ui/span/vec-macro-outlives-issue-15480.rs: [missing] -> pass (J1)
[ui] tests/ui/unpretty/box.rs: pass -> [missing] (J1)
[mir-opt] tests/mir-opt/box_expr.rs: pass -> [missing] (J2)
[mir-opt] tests/mir-opt/building/write_box_via_move.rs: [missing] -> pass (J2)
[mir-opt] tests/mir-opt/building/write_via_move.rs: [missing] -> pass (J2)
[mir-opt] tests/mir-opt/const_prop/boxes.rs: pass -> [missing] (J2)

Additionally, 258 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 3c9faa0d037b9eecda4a440cc482ff7f960fb8a5 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

pr-check-1: 34m 19s -> 24m 26s (-28.8%)
aarch64-apple: 4h 27m -> 3h 34m (-19.9%)
x86_64-gnu-aux: 2h 20m -> 1h 55m (-17.9%)
x86_64-gnu-tools: 1h 4m -> 55m 13s (-14.5%)
i686-gnu-2: 1h 44m -> 1h 30m (-13.8%)
armhf-gnu: 1h 33m -> 1h 21m (-12.9%)
x86_64-gnu-distcheck: 2h 22m -> 2h 4m (-12.7%)
x86_64-gnu-llvm-21-1: 1h 13m -> 1h 4m (-12.1%)
x86_64-gnu-llvm-21-2: 1h 45m -> 1h 32m (-11.9%)
arm-android: 1h 48m -> 1h 36m (-11.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-02-16T23:08:44Z

Finished benchmarking commit (3c9faa0): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.8%	[0.5%, 1.9%]	8
Regressions ❌ (secondary)	1.8%	[0.4%, 5.5%]	24
Improvements ✅ (primary)	-0.8%	[-0.8%, -0.8%]	1
Improvements ✅ (secondary)	-0.3%	[-0.3%, -0.3%]	1
All ❌✅ (primary)	0.6%	[-0.8%, 1.9%]	9

Max RSS (memory usage)

Results (primary -6.2%, secondary -1.3%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-6.2%	[-9.3%, -3.1%]	2
Improvements ✅ (secondary)	-4.7%	[-4.7%, -4.7%]	1
All ❌✅ (primary)	-6.2%	[-9.3%, -3.1%]	2

Cycles

Results (primary 2.0%, secondary 2.6%)

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

	mean	range	count
Regressions ❌ (primary)	2.0%	[2.0%, 2.0%]	1
Regressions ❌ (secondary)	3.6%	[2.2%, 6.8%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.5%	[-2.5%, -2.5%]	1
All ❌✅ (primary)	2.0%	[2.0%, 2.0%]	1

Binary size

Results (primary 0.6%, secondary 2.0%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.2%, 1.4%]	30
Regressions ❌ (secondary)	2.0%	[0.1%, 8.5%]	17
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.6%	[-0.0%, 1.4%]	33

Bootstrap: 485.967s -> 480.798s (-1.06%)
Artifact size: 397.80 MiB -> 395.81 MiB (-0.50%)

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. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 27, 2025

rustbot assigned SparrowLii Oct 27, 2025

RalfJung commented Oct 27, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

RalfJung force-pushed the box_new branch from a3cd68b to 2ff0fae Compare October 28, 2025 07:22

RalfJung commented Oct 28, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

RalfJung force-pushed the box_new branch 2 times, most recently from 4e526d4 to cb7642b Compare October 28, 2025 07:41

This comment has been minimized.

Sign in to view

RalfJung force-pushed the box_new branch 2 times, most recently from 86e5a72 to 020bc3a Compare October 28, 2025 09:33

This comment has been minimized.

Sign in to view

RalfJung force-pushed the box_new branch from 020bc3a to a1b255c Compare October 28, 2025 11:06

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Oct 28, 2025

Auto merge of #148190 - RalfJung:box_new, r=<try>

500cf8b

replace box_new with lower-level intrinsics

This comment has been minimized.

Sign in to view

rust-bors bot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 16, 2026

RalfJung added 3 commits February 16, 2026 17:27

add write_box_via_move intrinsic and use it for vec!

5e65109

This allows us to get rid of box_new entirely

adjust clippy to fix some of the issues

e5ed864

add helper to project to a field of a place

0df1764

RalfJung force-pushed the box_new branch from 920df79 to 0df1764 Compare February 16, 2026 16:27

rust-bors bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 16, 2026

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 16, 2026

This comment has been minimized.

Sign in to view

rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 16, 2026

rust-bors bot merged commit 3c9faa0 into rust-lang:main Feb 16, 2026
12 checks passed

rustbot added this to the 1.95.0 milestone Feb 16, 2026

scottmcm mentioned this pull request Feb 17, 2026

Just pass Layout directly to box_new_uninit #152737

Open

		// Make sure `StorageDead` gets emitted.
		this.schedule_drop_storage_and_value(expr_span, this.local_scope(), ptr);

Uh oh!

Conversation

RalfJung commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

vec! FAQ

Uh oh!

rustbot commented Oct 27, 2025

Uh oh!

rustbot commented Oct 27, 2025

Uh oh!

RalfJung Oct 27, 2025 • edited 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!

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!

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!

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!

This comment has been minimized.

rustbot commented Oct 28, 2025

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!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

RalfJung commented Oct 28, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Feb 16, 2026

Uh oh!

RalfJung commented Feb 16, 2026

Uh oh!

rust-bors bot commented Feb 16, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Feb 16, 2026

Uh oh!

Uh oh!

github-actions bot commented Feb 16, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Feb 16, 2026

Overall result: ❌ regressions - please read the text below

RalfJung commented Oct 27, 2025 •

edited

Loading

`vec!` FAQ

RalfJung Oct 27, 2025 •

edited

Loading