rustdoc: Only analyze head of self type when deciding impl inlining by camelid · Pull Request #159854 · rust-lang/rust

camelid · 2026-07-24T17:05:39Z

We only care about whether the self type is a generic or an item (inlined) in
the current crate, so we don't actually need to compute the param_env, which is
expensive when done to every external impl. This PR avoids computing the
param_env until we actually decide to inline the impl. Moreover, it adds
specialized cleaning logic for types that stops after the "head" (the top-level
structure) is constructed, which is enough for the self type-based impl
inlining analysis.

camelid · 2026-07-24T17:05:46Z

@bors try @rust-timer queue

rustdoc: Only analyze head of self type when deciding impl inlining

rust-bors · 2026-07-24T19:11:56Z

☀️ Try build successful (CI)
Build commit: b8110ca (b8110ca9b8652ec8b2b3ae78916c0f05ed62d565)
Base parent: 29e68fe (29e68fe2295f8fc2feb52b8cb0b61a055842fdcf)

rust-timer · 2026-07-24T19:53:53Z

Finished benchmarking commit (b8110ca): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never 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)	-8.4%	[-37.1%, -0.8%]	19
Improvements ✅ (secondary)	-21.1%	[-36.9%, -2.4%]	24
All ❌✅ (primary)	-8.4%	[-37.1%, -0.8%]	19

Max RSS (memory usage)

Results (primary -5.9%, secondary -8.7%)

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

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	6.0%	[6.0%, 6.0%]	1
Improvements ✅ (primary)	-6.4%	[-11.8%, -1.2%]	20
Improvements ✅ (secondary)	-9.3%	[-12.7%, -2.9%]	23
All ❌✅ (primary)	-5.9%	[-11.8%, 3.1%]	21

Cycles

Results (primary -11.5%, secondary -23.6%)

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.5%	[2.5%, 2.5%]	1
Improvements ✅ (primary)	-11.5%	[-38.4%, -2.6%]	17
Improvements ✅ (secondary)	-24.7%	[-38.6%, -2.7%]	23
All ❌✅ (primary)	-11.5%	[-38.4%, -2.6%]	17

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 488.104s -> 487.819s (-0.06%)
Artifact size: 387.69 MiB -> 387.70 MiB (0.00%)

We only care about whether the self type is a generic or an item (inlined) in the current crate, so we don't actually need to compute the param_env, which is expensive when done to every external impl.

rustbot · 2026-07-24T20:10:42Z

r? @notriddle

rustbot has assigned @notriddle.
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: rustdoc
rustdoc expanded to 8 candidates
Random selection from GuillaumeGomez, lolbinarycat, notriddle

Kobzol · 2026-07-28T17:31:30Z

Ugh, we really should enable compiler-docs in CI to avoid these annoying last-minute failures. Maybe we can enable mergeable CCI for internal docs since that should provide a big speedup to rustdoc?

With -Zrustdoc-mergeable-info, building compiler-docs goes from ~1m7s to ~20-25s on my desktop (on this branch, with all the rustdoc perf fixes I've done).

If it doesn't have any trade-offs that we would care about, please do send a PR! Building docs is indeed a non-trivial bottleneck for our CI.

This feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) -- note that this is with the latest rustdoc perf improvements (#159854).

rust-log-analyzer · 2026-07-28T19:12:33Z

The job dist-x86_64-solaris failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

rust-bors · 2026-07-28T19:13:37Z

💔 Test for e59475a failed: CI. Failed job:

auto - dist-x86_64-solaris (web logs, enhanced plaintext logs)

camelid · 2026-07-28T19:14:51Z

Argh. Appears spurious AFAICT. I don't even see an error in the logs, weirdly...

@bors retry spurious>

JonathanBrouwer · 2026-07-28T19:30:10Z

Just to be sure
@bors try jobs=dist-x86_64-solaris

rustdoc: Only analyze head of self type when deciding impl inlining try-job: dist-x86_64-solaris

rust-bors · 2026-07-28T21:20:34Z

☀️ Try build successful (CI)
Build commit: 217458e (217458eabef1c6d9349658606aaa4460fcb75fb7)
Base parent: e19d321 (e19d321c06479c6fd77533582b0d5a86651f1be3)

rust-bors · 2026-07-29T02:23:27Z

☀️ Test successful - CI
Approved by: notriddle,GuillaumeGomez
Duration: 3h 42m 18s
Pushing 701a651 to main...

github-actions · 2026-07-29T02:26:12Z

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 26ae60a (parent) -> 701a651 (this PR)

Test differences

Show 6 test diffs

Stage 1

[rustdoc-html] tests/rustdoc-html/inline_cross/impl-for-projection-reexport.rs: [missing] -> pass (J0)

Stage 2

[rustdoc-html] tests/rustdoc-html/inline_cross/impl-for-projection-reexport.rs: [missing] -> pass (J1)

Additionally, 4 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 701a6513a48eac30d49110ba06187648b7553622 --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

x86_64-gnu-gcc-core-tests: 14m 41s -> 8m 45s (-40.3%)
x86_64-gnu-llvm-21-1: 54m 59s -> 34m 57s (-36.4%)
dist-powerpc64le-linux-musl: 1h 12m -> 1h 36m (+33.7%)
x86_64-msvc-ext2: 2h 2m -> 1h 23m (-31.6%)
i686-msvc-1: 2h 13m -> 2h 54m (+30.0%)
x86_64-gnu-llvm-21-3: 1h 46m -> 1h 17m (-27.6%)
x86_64-gnu-miri: 1h 39m -> 1h 14m (-25.1%)
x86_64-gnu-gcc: 1h 14m -> 56m 24s (-24.8%)
x86_64-msvc-1: 1h 59m -> 2h 27m (+23.3%)
x86_64-msvc-ext1: 2h 7m -> 1h 38m (-23.3%)

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-07-29T03:04:49Z

Finished benchmarking commit (701a651): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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)	-9.1%	[-39.9%, -0.9%]	19
Improvements ✅ (secondary)	-22.8%	[-39.7%, -2.6%]	24
All ❌✅ (primary)	-9.1%	[-39.9%, -0.9%]	19

Max RSS (memory usage)

Results (primary -6.5%, secondary -10.6%)

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

	mean	range	count
Regressions ❌ (primary)	2.8%	[2.8%, 2.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-7.0%	[-13.7%, -1.5%]	20
Improvements ✅ (secondary)	-10.6%	[-13.2%, -3.0%]	23
All ❌✅ (primary)	-6.5%	[-13.7%, 2.8%]	21

Cycles

Results (primary -12.1%, secondary -25.4%)

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)	3.0%	[2.8%, 3.3%]	2
Improvements ✅ (primary)	-12.1%	[-41.4%, -3.0%]	19
Improvements ✅ (secondary)	-27.8%	[-41.8%, -4.4%]	23
All ❌✅ (primary)	-12.1%	[-41.4%, -3.0%]	19

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 489.651s -> 491.747s (0.43%)
Artifact size: 390.13 MiB -> 390.11 MiB (-0.00%)

@camelid

…obzol,jieyouxu bootstrap: Enable rustdoc mergeable CCI for std and internal docs Takes a different approach to #160098, where the internal docs are merged by bootstrap directly invoking rustdoc. This requires bootstrap to gather the list of metadata directories by inspecting cargo's fingerprint files (which aren't stable). The first commit is written by @camelid, but I wrote the other two. This feature is needed because: 1. The search index (that powers [web-based search](https://doc.rust-lang.org/nightly/nightly-rustc/?search=ty%20-%3E%20rustdoc%3A%3Atype)) needs to contain all of the crates in the nightly-rustc project. In particular, I'd prefer if it contained Clippy, Rustdoc, and Rustc, since those crates share type checker stuff and the ability to search all three at once is convenient. 2. For every crate that rustdoc *currently* documents, it has to load the search index from the doc output dir, and rebuild the search index with the new crate added to it. Loading the search index requires $O(\text{crates})$ work, so doing it once for every crate means we're doing $O(\text{crates}^2)$ work overall. 3. It would be more efficient, *instead*, if each crate wrote its data separately, and then the final search index was generated at the end by merging them all at once. Obviously, this would make the work linear instead of quadratic. For the record, Hoogle and Sherlodoc have a similar index-generating step. 4. We call this "Mergeable Cross-Crate-Information." Cargo stores it in the build directory, and supplies it to Rustdoc in a separate phase that runs after everything else. When we eventually stabilize this feature, it will be invisible to (most) end users. `cargo doc` will just be faster. 5. So, in order for crates to share their cross-crate info, we need them to share a build directory. 6. Tools, like Rustdoc and Cargo, don't normally share a build directory with Rustc. 7. To make them share a build directory while generating documentation, without forcing them to share a build directory while compiling, I added a new mode. --- This rustdoc feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) for `x doc src/tools` -- note that this is with the latest rustdoc perf improvements (#159854). r? @Kobzol

@camelid

…obzol,jieyouxu bootstrap: Enable rustdoc mergeable CCI for std and internal docs Takes a different approach to rust-lang/rust#160098, where the internal docs are merged by bootstrap directly invoking rustdoc. This requires bootstrap to gather the list of metadata directories by inspecting cargo's fingerprint files (which aren't stable). The first commit is written by @camelid, but I wrote the other two. This feature is needed because: 1. The search index (that powers [web-based search](https://doc.rust-lang.org/nightly/nightly-rustc/?search=ty%20-%3E%20rustdoc%3A%3Atype)) needs to contain all of the crates in the nightly-rustc project. In particular, I'd prefer if it contained Clippy, Rustdoc, and Rustc, since those crates share type checker stuff and the ability to search all three at once is convenient. 2. For every crate that rustdoc *currently* documents, it has to load the search index from the doc output dir, and rebuild the search index with the new crate added to it. Loading the search index requires $O(\text{crates})$ work, so doing it once for every crate means we're doing $O(\text{crates}^2)$ work overall. 3. It would be more efficient, *instead*, if each crate wrote its data separately, and then the final search index was generated at the end by merging them all at once. Obviously, this would make the work linear instead of quadratic. For the record, Hoogle and Sherlodoc have a similar index-generating step. 4. We call this "Mergeable Cross-Crate-Information." Cargo stores it in the build directory, and supplies it to Rustdoc in a separate phase that runs after everything else. When we eventually stabilize this feature, it will be invisible to (most) end users. `cargo doc` will just be faster. 5. So, in order for crates to share their cross-crate info, we need them to share a build directory. 6. Tools, like Rustdoc and Cargo, don't normally share a build directory with Rustc. 7. To make them share a build directory while generating documentation, without forcing them to share a build directory while compiling, I added a new mode. --- This rustdoc feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) for `x doc src/tools` -- note that this is with the latest rustdoc perf improvements (rust-lang/rust#159854). r? @Kobzol

@camelid

…obzol,jieyouxu bootstrap: Enable rustdoc mergeable CCI for std and internal docs Takes a different approach to rust-lang/rust#160098, where the internal docs are merged by bootstrap directly invoking rustdoc. This requires bootstrap to gather the list of metadata directories by inspecting cargo's fingerprint files (which aren't stable). The first commit is written by @camelid, but I wrote the other two. This feature is needed because: 1. The search index (that powers [web-based search](https://doc.rust-lang.org/nightly/nightly-rustc/?search=ty%20-%3E%20rustdoc%3A%3Atype)) needs to contain all of the crates in the nightly-rustc project. In particular, I'd prefer if it contained Clippy, Rustdoc, and Rustc, since those crates share type checker stuff and the ability to search all three at once is convenient. 2. For every crate that rustdoc *currently* documents, it has to load the search index from the doc output dir, and rebuild the search index with the new crate added to it. Loading the search index requires $O(\text{crates})$ work, so doing it once for every crate means we're doing $O(\text{crates}^2)$ work overall. 3. It would be more efficient, *instead*, if each crate wrote its data separately, and then the final search index was generated at the end by merging them all at once. Obviously, this would make the work linear instead of quadratic. For the record, Hoogle and Sherlodoc have a similar index-generating step. 4. We call this "Mergeable Cross-Crate-Information." Cargo stores it in the build directory, and supplies it to Rustdoc in a separate phase that runs after everything else. When we eventually stabilize this feature, it will be invisible to (most) end users. `cargo doc` will just be faster. 5. So, in order for crates to share their cross-crate info, we need them to share a build directory. 6. Tools, like Rustdoc and Cargo, don't normally share a build directory with Rustc. 7. To make them share a build directory while generating documentation, without forcing them to share a build directory while compiling, I added a new mode. --- This rustdoc feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) for `x doc src/tools` -- note that this is with the latest rustdoc perf improvements (rust-lang/rust#159854). r? @Kobzol

@camelid

…obzol,jieyouxu bootstrap: Enable rustdoc mergeable CCI for std and internal docs Takes a different approach to rust-lang/rust#160098, where the internal docs are merged by bootstrap directly invoking rustdoc. This requires bootstrap to gather the list of metadata directories by inspecting cargo's fingerprint files (which aren't stable). The first commit is written by @camelid, but I wrote the other two. This feature is needed because: 1. The search index (that powers [web-based search](https://doc.rust-lang.org/nightly/nightly-rustc/?search=ty%20-%3E%20rustdoc%3A%3Atype)) needs to contain all of the crates in the nightly-rustc project. In particular, I'd prefer if it contained Clippy, Rustdoc, and Rustc, since those crates share type checker stuff and the ability to search all three at once is convenient. 2. For every crate that rustdoc *currently* documents, it has to load the search index from the doc output dir, and rebuild the search index with the new crate added to it. Loading the search index requires $O(\text{crates})$ work, so doing it once for every crate means we're doing $O(\text{crates}^2)$ work overall. 3. It would be more efficient, *instead*, if each crate wrote its data separately, and then the final search index was generated at the end by merging them all at once. Obviously, this would make the work linear instead of quadratic. For the record, Hoogle and Sherlodoc have a similar index-generating step. 4. We call this "Mergeable Cross-Crate-Information." Cargo stores it in the build directory, and supplies it to Rustdoc in a separate phase that runs after everything else. When we eventually stabilize this feature, it will be invisible to (most) end users. `cargo doc` will just be faster. 5. So, in order for crates to share their cross-crate info, we need them to share a build directory. 6. Tools, like Rustdoc and Cargo, don't normally share a build directory with Rustc. 7. To make them share a build directory while generating documentation, without forcing them to share a build directory while compiling, I added a new mode. --- This rustdoc feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) for `x doc src/tools` -- note that this is with the latest rustdoc perf improvements (rust-lang/rust#159854). r? @Kobzol

@camelid

…obzol,jieyouxu bootstrap: Enable rustdoc mergeable CCI for std and internal docs Takes a different approach to rust-lang/rust#160098, where the internal docs are merged by bootstrap directly invoking rustdoc. This requires bootstrap to gather the list of metadata directories by inspecting cargo's fingerprint files (which aren't stable). The first commit is written by @camelid, but I wrote the other two. This feature is needed because: 1. The search index (that powers [web-based search](https://doc.rust-lang.org/nightly/nightly-rustc/?search=ty%20-%3E%20rustdoc%3A%3Atype)) needs to contain all of the crates in the nightly-rustc project. In particular, I'd prefer if it contained Clippy, Rustdoc, and Rustc, since those crates share type checker stuff and the ability to search all three at once is convenient. 2. For every crate that rustdoc *currently* documents, it has to load the search index from the doc output dir, and rebuild the search index with the new crate added to it. Loading the search index requires $O(\text{crates})$ work, so doing it once for every crate means we're doing $O(\text{crates}^2)$ work overall. 3. It would be more efficient, *instead*, if each crate wrote its data separately, and then the final search index was generated at the end by merging them all at once. Obviously, this would make the work linear instead of quadratic. For the record, Hoogle and Sherlodoc have a similar index-generating step. 4. We call this "Mergeable Cross-Crate-Information." Cargo stores it in the build directory, and supplies it to Rustdoc in a separate phase that runs after everything else. When we eventually stabilize this feature, it will be invisible to (most) end users. `cargo doc` will just be faster. 5. So, in order for crates to share their cross-crate info, we need them to share a build directory. 6. Tools, like Rustdoc and Cargo, don't normally share a build directory with Rustc. 7. To make them share a build directory while generating documentation, without forcing them to share a build directory while compiling, I added a new mode. --- This rustdoc feature is unstable but will be stabilized soon, and this is a good way of dogfooding it to make sure it works properly. It should have no effect on the generated docs, but it provides a significant speedup. For example, I measure a 3x speedup locally (3m 11s -> 1m 1s) for `x doc src/tools` -- note that this is with the latest rustdoc perf improvements (rust-lang/rust#159854). r? @Kobzol

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jul 24, 2026

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 Jul 24, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jul 24, 2026

Auto merge of #159854 - camelid:selfty-head, r=<try>

b8110ca

rustdoc: Only analyze head of self type when deciding impl inlining

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 Jul 24, 2026

camelid commented Jul 24, 2026

View reviewed changes

Comment thread src/librustdoc/passes/collect_trait_impls.rs Outdated

rustdoc: Skip param_env when making impl inlining decisions

f5b3643

We only care about whether the self type is a generic or an item (inlined) in the current crate, so we don't actually need to compute the param_env, which is expensive when done to every external impl.

camelid force-pushed the selfty-head branch from 5377944 to 74939c0 Compare July 24, 2026 20:10

camelid marked this pull request as ready for review July 24, 2026 20:10

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 24, 2026

rustbot assigned notriddle Jul 24, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jul 24, 2026

camelid force-pushed the selfty-head branch from 74939c0 to 0b267ab Compare July 24, 2026 20:30

GuillaumeGomez reviewed Jul 24, 2026

View reviewed changes

Comment thread src/librustdoc/passes/collect_trait_impls.rs Outdated

camelid force-pushed the selfty-head branch 3 times, most recently from 69b025c to a1136eb Compare July 25, 2026 18:04

notriddle requested changes Jul 26, 2026

View reviewed changes

Comment thread src/librustdoc/passes/collect_trait_impls.rs

Comment thread src/librustdoc/passes/collect_trait_impls.rs Outdated

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 Jul 26, 2026

camelid 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 Jul 27, 2026

rustbot added the T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. label Jul 27, 2026

camelid mentioned this pull request Jul 28, 2026

bootstrap: Enable rustdoc mergeable CCI for std and internal docs #160098

Closed

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 Jul 28, 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 Jul 28, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jul 28, 2026

Auto merge of #159854 - camelid:selfty-head, r=<try>

217458e

rustdoc: Only analyze head of self type when deciding impl inlining try-job: dist-x86_64-solaris

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 Jul 29, 2026

rust-bors Bot merged commit 701a651 into rust-lang:main Jul 29, 2026
15 checks passed

rustbot added this to the 1.99.0 milestone Jul 29, 2026

camelid deleted the selfty-head branch July 29, 2026 15:36

camelid mentioned this pull request Jul 30, 2026

Tracking issue for release notes of #159623: rustdoc: Only build extern trait impls if needed #159674

Open

notriddle mentioned this pull request Aug 25, 2026

bootstrap: Enable rustdoc mergeable CCI for std and internal docs #161716

Merged

Uh oh!

Uh oh!

Conversation

camelid commented Jul 24, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

camelid commented Jul 24, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors Bot commented Jul 24, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Jul 24, 2026

Overall result: ✅ improvements - no action needed

Uh oh!

Uh oh!

rustbot commented Jul 24, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Kobzol commented Jul 28, 2026

Uh oh!

rust-log-analyzer commented Jul 28, 2026

Uh oh!

rust-bors Bot commented Jul 28, 2026

Uh oh!

camelid commented Jul 28, 2026

Uh oh!

JonathanBrouwer commented Jul 28, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jul 28, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jul 29, 2026

Uh oh!

Uh oh!

github-actions Bot commented Jul 29, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Jul 29, 2026

Overall result: ✅ improvements - no action needed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

camelid commented Jul 24, 2026 •

edited by rustbot

Loading