Introduce OptimizationObjective and fix the entry shim's size attributes by cezarbbb · Pull Request #164784 · rust-lang/rust

cezarbbb · 2026-10-23T09:26:42Z

The MIR inliner's 2 => arm allow-lists More | Aggressive by hand. s/z also derive MIR level 2, so the pass never runs there. I could not find why in the source or the history — the gate predates the tiered match and read mir_opt_level() >= 3, which s/z never satisfied either, and Size/SizeMin simply were not among the entries considered when the match was written. There is no revert or regression behind it. Dumping every MIR pass at all four levels, the pass sets at 2/3 and at s/z differ by exactly one name: Inline. So I enabled it through PassPolicy::size_only() and measured.

~~The general situation is as follows:~~
For the .text section in rlib files, I tested 24 crates; the results were −3.59% (17/24) for os and −5.78% (16/24) for oz.
Additional test data includes:
~~76-crate sample, Σ stripped: −0.08% (os), −0.13% (oz)~~
~~22 apps, Σ stripped: −0.09% (os), −0.07% (oz)~~
~~22 apps, on-disk bytes: −0.40% (7/22) (os), −0.74% (11/22) for (oz)~~
~~22 apps, Σ .text: +0.18% (os), +0.84% (oz)~~

~~Is enabling MIR inlining at s/z the right direction, given that it clearly shrinks libraries and application binaries on disk while growing application .text?~~

Update: as @oli-obk asked, the refactoring is now its own commit. The MIR inliner change will move out to another PR. The measurements above are why I still think it is worth doing, but it does not belong in this PR.

When I Split it out I found that LLVM 23 no longer has Os/Oz as pipeline levels, they both build the O2 pipeline now, and what marks a function as size-optimized is the optsize/minsize attribute on it. So at -Copt-level=s/z there is no longer any setting rustc hands to LLVM that says "this is a size build", it is entirely per-function.

It exposed a gap that the C entry shim and __rust_try have no item behind them and never go through the per-item attribute path, so they were the only definitions in a size build that LLVM optimized for speed. They now get the same attributes as everything else.

The refactoring itself gives size-versus-speed a name and moves the sites that are really asking "what is this build optimizing for" onto it. The ones that are asking "how hard" — the linker and pipeline level tables, where s and z map to different strings, still match on OptLevel. CodeGenOptSize was already being discarded at its only call site, so it is gone.

There are codegen tests for each knob that now reads the objective, at 2, s and z.

rustbot · 2026-10-23T09:26:46Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

rustbot · 2026-10-23T09:26:49Z

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 77 candidates
Random selection from 19 candidates

jieyouxu · 2026-10-23T09:39:04Z

r? mir-opt

oli-obk · 2026-10-23T11:19:44Z

please pull the refactoring changes out into a separate commit.

do we have anything in the perf test suite that actually uses z or s? I'd love to have some number we change in the perf test suite to track this over time

oli-obk

.

View changes since this review

rustbot · 2026-10-23T11:20:09Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

bjorn3 · 2026-10-23T11:29:06Z

Is enabling MIR inlining at s/z the right direction, given that it clearly shrinks libraries and application binaries on disk while growing application .text?

-Copt-level=s/z is most important for embedded applications where the total flash usage (combined size of all sections that will be mapped into memory, so no debuginfo, symbols, ... Generally only .text, .rodata and .data matter in the end) matters, not the size of rlibs or the size of the ELF files of the executable.

cezarbbb · 2026-10-23T12:39:15Z

please pull the refactoring changes out into a separate commit.

Alright, I will split this PR into two.

cezarbbb · 2026-10-23T12:44:02Z

do we have anything in the perf test suite that actually uses z or s? I'd love to have some number we change in the perf test suite to track this over time

Understood; I will take a look at the perf test suite. Currently, I am conducting tests on my local machine using crates sourced from crates.io.

cezarbbb · 2026-10-23T12:45:52Z

-Copt-level=s/z is most important for embedded applications where the total flash usage (combined size of all sections that will be mapped into memory, so no debuginfo, symbols, ... Generally only .text, .rodata and .data matter in the end) matters, not the size of rlibs or the size of the ELF files of the executable.

I will conduct further testing on these sections.

saethlin · 2026-10-23T19:21:50Z

I don't think this is the right way to improve the size of executables complied with levels s or z. If LLVM is making the wrong inlining decisions we should have an explanation for why LLVM cannot adapt its heuristics to make the right decisions, before we start fighting with its inliner.

What you are trying to do here could be a good idea, but I just want to point out that I have prototyped this change myself and discarded it because I concluded that the MIR inliner is likely to regress code size as often as it helps, because it isn't actually addressing the root cause of the problem inside LLVM.

cezarbbb · 2026-10-26T04:00:06Z

I don't think this is the right way to improve the size of executables complied with levels s or z. If LLVM is making the wrong inlining decisions we should have an explanation for why LLVM cannot adapt its heuristics to make the right decisions, before we start fighting with its inliner.

What you are trying to do here could be a good idea, but I just want to point out that I have prototyped this change myself and discarded it because I concluded that the MIR inliner is likely to regress code size as often as it helps, because it isn't actually addressing the root cause of the problem inside LLVM.

Hi. I want to separate two questions, because I think they get conflated.

One is whether the inliner makes good decisions and whether it grows code. The other is whether it is right that the MIR inliner has never run at -Os/-Oz at all.

On the second: at -Copt-level=s and z the MIR pass set is the -Copt-level=2 pass set minus inlining and nothing else. At the same time the compiler already treats both levels as level 2 when it decides how much MIR optimisation to do. So one gate, which looks at the global opt level, switches off a single pass that the rest of the pipeline was set up to run.

On the first: I agree the current state is not good, and I am not claiming this change makes executables smaller. LLVM's inliner gives a bonus to a call that is the only remaining call to a local function, because inlining it is known to reduce size. The MIR inliner has no equivalent; it only rewards a callee whose own body contains a single call. The thresholds are not aligned either: at -Oz LLVM lowers its threshold for size-annotated callers to a small number, while the MIR inliner's default is the same at every level. So at z the MIR inliner is considerably more permissive than LLVM while using a weaker model.
So the only thing I want to argue for is the second question. While that gate is closed, any future work on the MIR inliner's size behaviour is dead code at exactly the levels it is meant to serve. Opening it is not a size improvement and I am not presenting it as one. It is a prerequisite for being able to measure one.

cezarbbb · 2026-10-27T11:05:04Z

@rustbot ready

oli-obk

@bors r+

View changes since this review

rust-bors · 2026-11-06T09:24:10Z

📌 Commit 81c0b8e has been approved by oli-obk

It is now in the queue for this repository.

…uwer Rollup of 19 pull requests Successful merges: - #164784 (Introduce OptimizationObjective and fix the entry shim's size attributes) - #165037 (Drop array elements in order after a partial move) - #165078 (Use the `2.38` binutils version in CI) - #159374 (Lower #[no_mangle] to #[symbol_name]/#[link_name]) - #163284 (feat(Reborrow): Allow multiple lifetimes) - #164775 (Tweak output on misused `const` parameter to provide more context and more accurate suggestion) - #165194 (name elided lifetimes in `use<...>` suggestion when `impl Trait` params are present) - #165222 (Anonymize inner binders when checking refining) - #165335 (Fallible type ops) - #165388 (Accept variadic SysV64, Win64, and Aapcs FnAbis in rustc_public) - #165448 (Update `Vec::retain_unstable` docs to say that this method is generally faster than `Vec::retain_mut`) - #165494 (fix Miri ICE on exit with () return type) - #165503 (update Enzyme submodule) - #165505 (DFV: Reject `#[non_exhaustive]` on enum variants with default field values) - #165512 (Fix warnings for the L4Re targets) - #165514 (Remove unused `WhereEqPredicate` and `ScopeId` types) - #165518 (style-guide: Remove ABI explicitness prescription for extern items) - #165519 (Update books) - #165534 (rename MIR_borrow_checking timing scope to less confusing name)

…butes

rustbot · 2026-11-07T01:58:16Z

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.

rust-bors · 2026-11-07T01:58:18Z

⚠️ A new commit 4efd16754f76122bfef88dadf4ff22430418f82a was pushed.

This PR was contained in a rollup (#165548), which was closed.

cezarbbb · 2026-11-07T07:43:19Z

@rustbot ready

oli-obk · 2026-11-07T09:41:12Z

@bors r+

rust-bors · 2026-11-07T09:41:15Z

📌 Commit 4efd167 has been approved by oli-obk

It is now in the queue for this repository.

@oli-obk

…i-obk Introduce OptimizationObjective and fix the entry shim's size attributes ~~The MIR inliner's 2 => arm allow-lists `More | Aggressive` by hand. `s/z` also derive MIR level 2, so the pass never runs there. I could not find why in the source or the history — the gate predates the tiered match and read `mir_opt_level() >= 3`, which `s/z` never satisfied either, and `Size/SizeMin` simply were not among the entries considered when the match was written. There is no revert or regression behind it. Dumping every MIR pass at all four levels, the pass sets at `2/3` and at `s/z` differ by exactly one name: Inline. So I enabled it through `PassPolicy::size_only()` and measured.~~ ~~The general situation is as follows:~~ ~~For the `.text` section in `rlib` files, I tested 24 crates; the results were −3.59% (17/24) for `os` and −5.78% (16/24) for `oz`. Additional test data includes:~~ ~~76-crate sample, Σ stripped: −0.08% (`os`), −0.13% (`oz`)~~ ~~22 apps, Σ stripped: −0.09% (`os`), −0.07% (`oz`)~~ ~~22 apps, on-disk bytes: −0.40% (7/22) (`os`), −0.74% (11/22) for (`oz`)~~ ~~22 apps, Σ .text: +0.18% (`os`), +0.84% (`oz`)~~ ~~Is enabling MIR inlining at `s/z` the right direction, given that it clearly shrinks libraries and application binaries on disk while growing application `.text`?~~ *Update*: as @oli-obk asked, the refactoring is now its own commit. The MIR inliner change will move out to another PR. The measurements above are why I still think it is worth doing, but it does not belong in this PR. When I Split it out I found that LLVM 23 no longer has `Os/Oz` as pipeline levels, they both build the `O2` pipeline now, and what marks a function as size-optimized is the `optsize/minsize` attribute on it. So at `-Copt-level=s/z` there is no longer any setting rustc hands to LLVM that says "this is a size build", it is entirely per-function. It exposed a gap that the C entry shim and `__rust_try` have no item behind them and never go through the per-item attribute path, so they were the only definitions in a size build that LLVM optimized for speed. They now get the same attributes as everything else. The refactoring itself gives size-versus-speed a name and moves the sites that are really asking "what is this build optimizing for" onto it. The ones that are asking "how hard" — the linker and pipeline level tables, where `s` and `z` map to different strings, still match on `OptLevel`. `CodeGenOptSize` was already being discarded at its only call site, so it is gone. There are codegen tests for each knob that now reads the objective, at `2`, `s` and `z`.

Rollup of 5 pull requests Successful merges: - #164784 (Introduce OptimizationObjective and fix the entry shim's size attributes) - #147696 (Implement `bit` and `set_bit` for integral types.) - #163202 (nuttx: use updated pollfd definition) - #163571 ([rustdoc] Render `Deref` methods on aliased items) - #165482 (apply `-Zcrate-attr` attributes before the crate attributes)

@oli-obk

…i-obk Introduce OptimizationObjective and fix the entry shim's size attributes ~~The MIR inliner's 2 => arm allow-lists `More | Aggressive` by hand. `s/z` also derive MIR level 2, so the pass never runs there. I could not find why in the source or the history — the gate predates the tiered match and read `mir_opt_level() >= 3`, which `s/z` never satisfied either, and `Size/SizeMin` simply were not among the entries considered when the match was written. There is no revert or regression behind it. Dumping every MIR pass at all four levels, the pass sets at `2/3` and at `s/z` differ by exactly one name: Inline. So I enabled it through `PassPolicy::size_only()` and measured.~~ ~~The general situation is as follows:~~ ~~For the `.text` section in `rlib` files, I tested 24 crates; the results were −3.59% (17/24) for `os` and −5.78% (16/24) for `oz`. Additional test data includes:~~ ~~76-crate sample, Σ stripped: −0.08% (`os`), −0.13% (`oz`)~~ ~~22 apps, Σ stripped: −0.09% (`os`), −0.07% (`oz`)~~ ~~22 apps, on-disk bytes: −0.40% (7/22) (`os`), −0.74% (11/22) for (`oz`)~~ ~~22 apps, Σ .text: +0.18% (`os`), +0.84% (`oz`)~~ ~~Is enabling MIR inlining at `s/z` the right direction, given that it clearly shrinks libraries and application binaries on disk while growing application `.text`?~~ *Update*: as @oli-obk asked, the refactoring is now its own commit. The MIR inliner change will move out to another PR. The measurements above are why I still think it is worth doing, but it does not belong in this PR. When I Split it out I found that LLVM 23 no longer has `Os/Oz` as pipeline levels, they both build the `O2` pipeline now, and what marks a function as size-optimized is the `optsize/minsize` attribute on it. So at `-Copt-level=s/z` there is no longer any setting rustc hands to LLVM that says "this is a size build", it is entirely per-function. It exposed a gap that the C entry shim and `__rust_try` have no item behind them and never go through the per-item attribute path, so they were the only definitions in a size build that LLVM optimized for speed. They now get the same attributes as everything else. The refactoring itself gives size-versus-speed a name and moves the sites that are really asking "what is this build optimizing for" onto it. The ones that are asking "how hard" — the linker and pipeline level tables, where `s` and `z` map to different strings, still match on `OptLevel`. `CodeGenOptSize` was already being discarded at its only call site, so it is gone. There are codegen tests for each knob that now reads the objective, at `2`, `s` and `z`.

…uwer Rollup of 8 pull requests Successful merges: - #164784 (Introduce OptimizationObjective and fix the entry shim's size attributes) - #165469 (Make notable trait `i` badges `<span>` instead of `<a>`) - #165576 (compiletest: Reject whitespace between `//` & `@` and reject leading revision conditions like (e.g., `//[rev]@ dir`)) - #147696 (Implement `bit` and `set_bit` for integral types.) - #163202 (nuttx: use updated pollfd definition) - #165482 (apply `-Zcrate-attr` attributes before the crate attributes) - #165517 (Migrate basic block ctors to require Terminator where possible) - #165552 (use lang item instead of name when assembling builtin `Clone::clone` instances)

rust-bors · 2026-11-07T16:55:35Z

⌛ Testing commit 4efd167 with merge f1865dc...

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

@oli-obk

Introduce OptimizationObjective and fix the entry shim's size attributes ~~The MIR inliner's 2 => arm allow-lists `More | Aggressive` by hand. `s/z` also derive MIR level 2, so the pass never runs there. I could not find why in the source or the history — the gate predates the tiered match and read `mir_opt_level() >= 3`, which `s/z` never satisfied either, and `Size/SizeMin` simply were not among the entries considered when the match was written. There is no revert or regression behind it. Dumping every MIR pass at all four levels, the pass sets at `2/3` and at `s/z` differ by exactly one name: Inline. So I enabled it through `PassPolicy::size_only()` and measured.~~ ~~The general situation is as follows:~~ ~~For the `.text` section in `rlib` files, I tested 24 crates; the results were −3.59% (17/24) for `os` and −5.78% (16/24) for `oz`. Additional test data includes:~~ ~~76-crate sample, Σ stripped: −0.08% (`os`), −0.13% (`oz`)~~ ~~22 apps, Σ stripped: −0.09% (`os`), −0.07% (`oz`)~~ ~~22 apps, on-disk bytes: −0.40% (7/22) (`os`), −0.74% (11/22) for (`oz`)~~ ~~22 apps, Σ .text: +0.18% (`os`), +0.84% (`oz`)~~ ~~Is enabling MIR inlining at `s/z` the right direction, given that it clearly shrinks libraries and application binaries on disk while growing application `.text`?~~ *Update*: as @oli-obk asked, the refactoring is now its own commit. The MIR inliner change will move out to another PR. The measurements above are why I still think it is worth doing, but it does not belong in this PR. When I Split it out I found that LLVM 23 no longer has `Os/Oz` as pipeline levels, they both build the `O2` pipeline now, and what marks a function as size-optimized is the `optsize/minsize` attribute on it. So at `-Copt-level=s/z` there is no longer any setting rustc hands to LLVM that says "this is a size build", it is entirely per-function. It exposed a gap that the C entry shim and `__rust_try` have no item behind them and never go through the per-item attribute path, so they were the only definitions in a size build that LLVM optimized for speed. They now get the same attributes as everything else. The refactoring itself gives size-versus-speed a name and moves the sites that are really asking "what is this build optimizing for" onto it. The ones that are asking "how hard" — the linker and pipeline level tables, where `s` and `z` map to different strings, still match on `OptLevel`. `CodeGenOptSize` was already being discarded at its only call site, so it is gone. There are codegen tests for each knob that now reads the objective, at `2`, `s` and `z`.

JonathanBrouwer · 2026-11-07T17:04:05Z

@bors yield
Yielding to enclosing rollup

rust-bors · 2026-11-07T17:04:09Z

Auto build was cancelled. Cancelled workflows:

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

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

…uwer Rollup of 8 pull requests Successful merges: - #164784 (Introduce OptimizationObjective and fix the entry shim's size attributes) - #165469 (Make notable trait `i` badges `<span>` instead of `<a>`) - #165576 (compiletest: Reject whitespace between `//` & `@` and reject leading revision conditions like (e.g., `//[rev]@ dir`)) - #147696 (Implement `bit` and `set_bit` for integral types.) - #163202 (nuttx: use updated pollfd definition) - #165482 (apply `-Zcrate-attr` attributes before the crate attributes) - #165517 (Migrate basic block ctors to require Terminator where possible) - #165552 (use lang item instead of name when assembling builtin `Clone::clone` instances)

@oli-obk

Rollup merge of #164784 - cezarbbb:overhaul-size-flags, r=oli-obk Introduce OptimizationObjective and fix the entry shim's size attributes ~~The MIR inliner's 2 => arm allow-lists `More | Aggressive` by hand. `s/z` also derive MIR level 2, so the pass never runs there. I could not find why in the source or the history — the gate predates the tiered match and read `mir_opt_level() >= 3`, which `s/z` never satisfied either, and `Size/SizeMin` simply were not among the entries considered when the match was written. There is no revert or regression behind it. Dumping every MIR pass at all four levels, the pass sets at `2/3` and at `s/z` differ by exactly one name: Inline. So I enabled it through `PassPolicy::size_only()` and measured.~~ ~~The general situation is as follows:~~ ~~For the `.text` section in `rlib` files, I tested 24 crates; the results were −3.59% (17/24) for `os` and −5.78% (16/24) for `oz`. Additional test data includes:~~ ~~76-crate sample, Σ stripped: −0.08% (`os`), −0.13% (`oz`)~~ ~~22 apps, Σ stripped: −0.09% (`os`), −0.07% (`oz`)~~ ~~22 apps, on-disk bytes: −0.40% (7/22) (`os`), −0.74% (11/22) for (`oz`)~~ ~~22 apps, Σ .text: +0.18% (`os`), +0.84% (`oz`)~~ ~~Is enabling MIR inlining at `s/z` the right direction, given that it clearly shrinks libraries and application binaries on disk while growing application `.text`?~~ *Update*: as @oli-obk asked, the refactoring is now its own commit. The MIR inliner change will move out to another PR. The measurements above are why I still think it is worth doing, but it does not belong in this PR. When I Split it out I found that LLVM 23 no longer has `Os/Oz` as pipeline levels, they both build the `O2` pipeline now, and what marks a function as size-optimized is the `optsize/minsize` attribute on it. So at `-Copt-level=s/z` there is no longer any setting rustc hands to LLVM that says "this is a size build", it is entirely per-function. It exposed a gap that the C entry shim and `__rust_try` have no item behind them and never go through the per-item attribute path, so they were the only definitions in a size build that LLVM optimized for speed. They now get the same attributes as everything else. The refactoring itself gives size-versus-speed a name and moves the sites that are really asking "what is this build optimizing for" onto it. The ones that are asking "how hard" — the linker and pipeline level tables, where `s` and `z` map to different strings, still match on `OptLevel`. `CodeGenOptSize` was already being discarded at its only call site, so it is gone. There are codegen tests for each knob that now reads the objective, at `2`, `s` and `z`.

rustbot assigned jieyouxu Oct 23, 2026

rustbot assigned oli-obk and unassigned jieyouxu Oct 23, 2026

oli-obk requested changes Oct 23, 2026

View reviewed changes

rustbot 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 Oct 23, 2026

cezarbbb force-pushed the overhaul-size-flags branch from 4710fdd to 706ca60 Compare October 27, 2026 08:08

cezarbbb changed the title ~~Run the MIR inliner for os/oz~~ Introduce OptimizationObjective and fix the entry shim's size attributes Oct 27, 2026

This comment has been minimized.

Sign in to view

cezarbbb force-pushed the overhaul-size-flags branch from 706ca60 to 81c0b8e Compare October 27, 2026 09:28

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

oli-obk approved these changes Nov 6, 2026

View reviewed changes

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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 7, 2026

This comment has been minimized.

Sign in to view

Introduce OptimizationObjective and fix the entry shim's size attri…

4efd167

…butes

cezarbbb force-pushed the overhaul-size-flags branch from 81c0b8e to 4efd167 Compare November 7, 2026 01:58

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 7, 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-review Status: Awaiting review from the assignee but also interested parties. labels Nov 7, 2026

Zalathar mentioned this pull request Nov 7, 2026

Rollup of 5 pull requests #165591

Closed

Zalathar mentioned this pull request Nov 7, 2026

Rollup of 8 pull requests #165595

Closed

JonathanBrouwer mentioned this pull request Nov 7, 2026

Rollup of 8 pull requests #165597

Merged

rust-bors Bot merged commit 32a8daf into rust-lang:main Nov 7, 2026
14 of 15 checks passed

rustbot added this to the 1.102.0 milestone Nov 7, 2026

Conversation

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

Uh oh!

Uh oh!

rustbot commented Oct 23, 2026

Uh oh!

rustbot commented Oct 23, 2026

Uh oh!

jieyouxu commented Oct 23, 2026

Uh oh!

oli-obk commented Oct 23, 2026

Uh oh!

oli-obk left a comment • 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!

rustbot commented Oct 23, 2026

Uh oh!

bjorn3 commented Oct 23, 2026

Uh oh!

cezarbbb commented Oct 23, 2026

Uh oh!

cezarbbb commented Oct 23, 2026

Uh oh!

cezarbbb commented Oct 23, 2026

Uh oh!

saethlin commented Oct 23, 2026

Uh oh!

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

cezarbbb commented Oct 27, 2026

Uh oh!

oli-obk left a comment • 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!

rust-bors Bot commented Nov 6, 2026

Uh oh!

This comment has been minimized.

rustbot commented Nov 7, 2026

Uh oh!

rust-bors Bot commented Nov 7, 2026

Uh oh!

cezarbbb commented Nov 7, 2026

Uh oh!

oli-obk commented Nov 7, 2026

Uh oh!

rust-bors Bot commented Nov 7, 2026

Uh oh!

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

Uh oh!

Uh oh!

JonathanBrouwer commented Nov 7, 2026

Uh oh!

rust-bors Bot commented Nov 7, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

cezarbbb commented Oct 23, 2026 •

edited by rustbot

Loading

oli-obk left a comment •

edited by rustbot

Loading

cezarbbb commented Oct 26, 2026 •

edited

Loading

oli-obk left a comment •

edited by rustbot

Loading

rust-bors Bot commented Nov 7, 2026 •

edited

Loading