Rollup of 5 pull requests by JonathanBrouwer · Pull Request #161783 · rust-lang/rust

JonathanBrouwer · 2026-08-25T21:01:13Z

Successful merges:

Enforce even more library clippy lints in CI #161328 (Enforce even more library clippy lints in CI)
Replace Allocator + Clone with AllocatorClone in btree #161684 (Replace Allocator + Clone with AllocatorClone in btree)
Don't list escaping bound regions in nested for<...> binders of E0308 notes #159232 (Don't list escaping bound regions in nested for<...> binders of E0308 notes)
various cleanups of rustc_builtin_macros #161464 (various cleanups of rustc_builtin_macros)
Add codegen test for disjunction fed to unreachable_unchecked #161774 (Add codegen test for disjunction fed to unreachable_unchecked)

…08 notes The `for<...>` prefixes in `cmp_fn_sig` are built from the region map returned by `name_all_regions`. That map also contained regions that are bound by an enclosing binder and merely escape through the binder being named, so nested binders in expected/found notes listed lifetimes they don't bind, printing invalid types such as `&mut for<'a> fn(for<'a> fn(&'a ()))` for `&mut for<'a> fn(fn(&'a ()))`. Key the folder's map by the region's binder offset and only return the regions actually bound by the binder being named. The offset in the key also fixes a latent collision between a bound and an escaping region sharing the same bound variable index. The printed text is unaffected: the `name` closure already skips escaping regions when writing to the printer, which is why diagnostic labels were already correct.

rust-bors · 2026-08-25T23:57:02Z

☀️ Try build successful (CI)
Build commit: e8bcad5 (e8bcad5e689e6a88d391a0743a715f1ce88507cd)
Base parent: 787af2b (787af2b8c80638c51a4fc8e44f84e6891f243ec7)

rust-bors · 2026-08-26T01:33:49Z

☀️ Test successful - CI
Approved by: JonathanBrouwer
Duration: 3h 8m 13s
Pushing 0f33d09 to main...

github-actions · 2026-08-26T01:37: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 787af2b (parent) -> 0f33d09 (this PR)

Test differences

Show 5547 test diffs

Stage 1

[ui] tests/ui/higher-ranked/nested-binder-cmp-fn-sig-print.rs: [missing] -> pass (J0)
[ui (polonius)] tests/ui/higher-ranked/nested-binder-cmp-fn-sig-print.rs: [missing] -> pass (J2)
[codegen] tests/codegen-llvm/issues/unreachable-disjunction-div-115026.rs: [missing] -> pass (J3)

Stage 2

[codegen] tests/codegen-llvm/issues/unreachable-disjunction-div-115026.rs: [missing] -> pass (J1)
[ui] tests/ui/higher-ranked/nested-binder-cmp-fn-sig-print.rs: [missing] -> pass (J4)

Additionally, 5542 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 0f33d0912709e847199218ebab88e2311872f364 --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

dist-x86_64-msvc-alt: 1h 35m -> 2h 45m (+74.1%)
armhf-gnu: 1h 2m -> 1h 29m (+43.4%)
dist-sparcv9-solaris: 1h 10m -> 1h 36m (+36.1%)
x86_64-gnu-next-trait-solver-polonius: 1h 4m -> 41m 32s (-35.3%)
x86_64-msvc-ext1: 2h 21m -> 1h 32m (-34.9%)
x86_64-gnu-llvm-22-1: 1h 24m -> 55m (-34.7%)
optional-x86_64-gnu-autodiff: 43m 40s -> 57m 47s (+32.3%)
x86_64-gnu-aux: 2h 1m -> 2h 38m (+29.7%)
i686-msvc-1: 2h 52m -> 2h 5m (-27.4%)
x86_64-gnu-tools: 56m 37s -> 1h 12m (+27.2%)

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-08-26T02:18:10Z

Finished benchmarking commit (0f33d09): comparison URL.

Overall result: ❌ regressions - please read:

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.3%	[0.3%, 0.3%]	1
Regressions ❌ (secondary)	0.3%	[0.2%, 0.4%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.3%, 0.3%]	1

Max RSS (memory usage)

Results (primary -0.0%, secondary -4.1%)

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

	mean	range	count
Regressions ❌ (primary)	2.6%	[1.9%, 3.6%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.7%	[-3.6%, -1.1%]	3
Improvements ✅ (secondary)	-4.1%	[-4.1%, -4.1%]	1
All ❌✅ (primary)	-0.0%	[-3.6%, 3.6%]	6

Cycles

Results (secondary 2.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.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

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.0%	[0.0%, 0.1%]	4
Regressions ❌ (secondary)	0.1%	[0.1%, 0.1%]	1
Improvements ✅ (primary)	-0.1%	[-0.2%, -0.1%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.2%, 0.1%]	11

Bootstrap: 474.247s -> 475.39s (0.24%)
Artifact size: 402.66 MiB -> 402.69 MiB (0.01%)

rust-bors · 2026-08-26T02:33:30Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#161328	Enforce even more library clippy lints in CI	`c2db6fdd88fc41f5cb4bfa3eb3caab38b7506a8a` (link)
#161684	Replace `Allocator + Clone` with `AllocatorClone` in btree	`f951449e56f2fe7f2f8ff8783ba1fd6f8b1e0c57` (link)
#159232	Don't list escaping bound regions in nested `for<...>` bind…	`ea1efb29bb2fd337f26d1144cd7627762df19387` (link)
#161464	various cleanups of `rustc_builtin_macros`	`b35202286c8a6a959ffd7de020ce37a006193441` (link)
#161774	Add codegen test for disjunction fed to unreachable_uncheck…	`cc71eca232e8eb1510c164b9a687cbe3b3a5f5fb` (link)

parent commit: 787af2b8c8

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

panstromek · 2026-08-26T07:12:46Z

include-blob is probably just noise again.

serde regresses slightly in doc in multiple variants, so that's probably real, but small.

#161464 was benchmarked before merge, #161774 is just a test.

It looks like it could be either of the remaining three, the clippy one changes various things in the standard library, it has a perf run but not on the final diff I believe. The Allocator changes a bunch of trait bounds. The for<..> one changes pretty printing of types, I'm not sure if rustdoc uses that, but I think it doesn't?

Detailed results show that there are more hits on get_lang_items and explicit_implied_clauses_of, so I guess it's the allocator one?

@rust-timer triage f951449

rust-timer · 2026-08-26T07:12:50Z

#161684 `f951449` Replace `Allocator + Clone` with `AllocatorClone` in btree

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.3%	[0.3%, 0.3%]	1
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.3%, 0.3%]	1

Max RSS (memory usage)

Results (primary -0.1%, secondary -3.7%)

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)	-	-	0
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-3.7%	[-3.7%, -3.7%]	1
All ❌✅ (primary)	-0.1%	[-2.2%, 2.0%]	2

Cycles

Results (primary 3.2%, 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)	3.2%	[3.2%, 3.2%]	1
Regressions ❌ (secondary)	1.7%	[1.7%, 1.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.2%	[3.2%, 3.2%]	1

Binary size

Results (primary 0.0%, secondary 0.0%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	4
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	4

maxdexh · 2026-08-26T07:46:38Z

That PR literally just find-and-replaces Allocator + Clone with AllocatorClone (in the btree module), which is just an unsafe marker subtrait Allocator + Clone. Nothing changes at runtime.

Edit: Ah this is compile time stuff. Then I have no idea ^^

panstromek · 2026-08-26T08:29:15Z

More specifically it's doc time, i.e. rustdoc now takes more time to figure out how to document serde. That's not surprising for a change like this, rustdoc needs to know stuff about types, so if you add one more trait layer, it might need to do more work.

I'm not sure what to do about it, but I think this is not really a problem of the original PR. If there's a way to address it, it's arguably in rustdoc code and not in here. I'll ask in T-rustdoc and mark this as triaged.

@rustbot label: +perf-regression-triaged

maxdexh · 2026-08-26T08:39:31Z

Yeah this was needed for soundness, so no way around this until we come up with a more permanent solution for how to do allocators in btree.

But why is the regression is serde of all places?
Do they build docs for their deps?

panstromek · 2026-08-26T08:41:55Z

I guess it's because rustdoc needs to resolve a lot of stuff about types, and serde uses BtreeMap?

maxdexh · 2026-08-26T08:43:09Z

i would've expected it to only do that stuff in bounds and signatures. There is no way serde is using anything other than the global allocator with BtreeMap/Set (AllocatorClone is way too new for that not to just break here)

panstromek · 2026-08-26T08:47:24Z

Not sure, we'd have to measure. But you can see in detailed results that there are a lot more query hits for get_lang_items and explicit_implied_clauses_of:

https://perf.rust-lang.org/detailed-query.html?commit=f951449e56f2fe7f2f8ff8783ba1fd6f8b1e0c57&benchmark=serde-1.0.219-doc&scenario=full&backend=llvm&target=x86_64-unknown-linux-gnu&base_commit=787af2b8c80638c51a4fc8e44f84e6891f243ec7&sort=-cacheHitsDelta

Not sure why lang items (are Allocator traits lang items?) but implied clauses are (I believe) related to the fact that AllocatorClone implies Allocator + Clone.

maxdexh · 2026-08-26T08:48:27Z

Probably because Clone is a lang-item

Global is too

panstromek · 2026-08-26T08:50:02Z

Opened a topic in T-rustdoc here: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/.60doc.60.20regression.20from.20.60AllocatorClone.60/with/619225713

maxdexh · 2026-08-26T08:50:39Z

I just checked, there is not a single result for btree in the docs of serde, neither in names, params, nor returns

So it only appears in impls

panstromek · 2026-08-26T08:58:42Z

Yea, it's only impls and reexports: https://github.com/search?q=repo%3Arust-lang%2Frustc-perf+path%3A%2F%5Ecollector%5C%2Fcompile-benchmarks%5C%2Fserde-1%5C.0%5C.219%5C%2F%2F+BTree&type=code

cyrgani and others added 30 commits August 20, 2026 09:15

apply various clippy lint fixes

3c1abf4

remove some unneeded format! uses

7705a93

create the Box inside of combine_substructure

e94980b

split format_foreign.rs into actual file modules

a572603

inline is_staged_api_crate

2ea3197

remove the RefCell from CombineSubstructureFunc

21c02fb

simplify large match

745b410

use SmallVec instead of Vec in TraitDef

e899f2c

misc small cleanups and inlinings

f0cfd1d

remove path_local!

be01a09

improve usage and naming of path[vec]_std!

0b59610

inline two trivial functions

b84ba04

Replace Allocator + Clone with AllocatorClone in btree

bd72f7a

Add codegen test for disjunction fed to unreachable_unchecked

c42b90f

clippy::manual_is_ascii_check

8432202

clippy::manual_ignore_case_cmp

563b112

clippy::manual_hash_one

5fa3b60

clippy::excessive_precision

7cf35bd

clippy::partialeq_ne_impl

abce09f

clippy::manual_contains

d867667

clippy::single_match

b6ef1ff

clippy::match_as_ref

fd0a93f

clippy::default_constructed_unit_structs

28f78d4

clippy::redundant_closure

a7f7b19

clippy::derivable_impls

097f843

clippy::partialeq_to_none

ff47e67

clippy::unnecessary_map_or

8523083

clippy::manual_clear

64393eb

clippy::bind_instead_of_map

30dc431

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

rust-bors Bot merged commit 0f33d09 into rust-lang:main Aug 26, 2026
15 checks passed

rustbot added this to the 1.100.0 milestone Aug 26, 2026

rustbot added the perf-regression Performance regression. label Aug 26, 2026

rustbot added the perf-regression-triaged The performance regression has been triaged. label Aug 26, 2026

Uh oh!

Uh oh!

Conversation

JonathanBrouwer commented Aug 25, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors Bot commented Aug 25, 2026

Uh oh!

rust-bors Bot commented Aug 26, 2026

Uh oh!

Uh oh!

github-actions Bot commented Aug 26, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Aug 26, 2026

Overall result: ❌ regressions - please read:

Uh oh!

rust-bors Bot commented Aug 26, 2026

Uh oh!

panstromek commented Aug 26, 2026

Uh oh!

rust-timer commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

#161684 f951449 Replace Allocator + Clone with AllocatorClone in btree

Uh oh!

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

Uh oh!

Uh oh!

panstromek commented Aug 26, 2026

Uh oh!

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

Uh oh!

Uh oh!

panstromek commented Aug 26, 2026

Uh oh!

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

Uh oh!

Uh oh!

panstromek commented Aug 26, 2026

Uh oh!

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

Uh oh!

Uh oh!

panstromek commented Aug 26, 2026

Uh oh!

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

Uh oh!

Uh oh!

panstromek commented Aug 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

JonathanBrouwer commented Aug 25, 2026 •

edited by rustbot

Loading

rust-timer commented Aug 26, 2026 •

edited

Loading

#161684 `f951449` Replace `Allocator + Clone` with `AllocatorClone` in btree

maxdexh commented Aug 26, 2026 •

edited

Loading

maxdexh commented Aug 26, 2026 •

edited

Loading

maxdexh commented Aug 26, 2026 •

edited

Loading

maxdexh commented Aug 26, 2026 •

edited

Loading

maxdexh commented Aug 26, 2026 •

edited

Loading