Upgrade `thin-vec` to 0.2.21, including fix for `.collect()` capacity by joshtriplett · Pull Request #163959 · rust-lang/rust

joshtriplett · 2026-10-08T00:26:34Z

This includes mozilla/thin-vec#99 , which makes thin-vec respect size_hint when collecting.

In particular, this causes collections of 1-3 items to not be grown to a capacity of 4. The compiler has a lot of TinyVecs in the 1-3 range, so this substantially helps memory, and seems neutral on instructions.

For aws-sdk-ec2 full check, this saves 30.69 MiB max-rss (0.55% of peak RSS).

Merging this avoids the need to work around it in other work (e.g. by replacing .collect() with something calling ThinVec::with_capacity(...) first).

This includes mozilla/thin-vec#99 , which makes thin-vec respect size_hint when collecting. In particular, this causes collections of 1-3 items to not be grown to a capacity of 4. The compiler has a lot of `TinyVec`s in the 1-3 range, so this substantially helps memory, and seems neutral on instructions. For aws-sdk-ec2 full check, this saves 30.69 MiB max-rss (0.55% of peak RSS).

rustbot · 2026-10-08T00:26:38Z

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

rustbot · 2026-10-08T00:26:42Z

r? @wesleywiser

rustbot has assigned @wesleywiser.
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 18 candidates

joshtriplett · 2026-10-08T00:27:05Z

@bors try @rust-timer queue

Upgrade `thin-vec` to 0.2.21, including fix for `.collect()` capacity

rust-bors · 2026-10-08T01:27:20Z

☀️ Try build successful (CI)
Build commit: bcfac1e (bcfac1ea16fee40ab6e47646bd224f4a43dc8a1c)
Base parent: 33ffc9b (33ffc9b4d83afef2445b585d379d7158cbbd2315)

rust-timer · 2026-10-08T02:11:50Z

Finished benchmarking commit (bcfac1e): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

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.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@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.1%	[0.1%, 0.3%]	6
Regressions ❌ (secondary)	0.1%	[0.1%, 0.2%]	5
Improvements ✅ (primary)	-0.3%	[-0.6%, -0.1%]	8
Improvements ✅ (secondary)	-0.4%	[-0.7%, -0.1%]	42
All ❌✅ (primary)	-0.1%	[-0.6%, 0.3%]	14

Max RSS (memory usage)

Results (primary 0.4%, secondary 2.1%)

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

	mean	range	count
Regressions ❌ (primary)	1.7%	[1.2%, 2.4%]	3
Regressions ❌ (secondary)	2.9%	[0.5%, 5.9%]	4
Improvements ✅ (primary)	-1.5%	[-2.2%, -0.8%]	2
Improvements ✅ (secondary)	-1.1%	[-1.1%, -1.1%]	1
All ❌✅ (primary)	0.4%	[-2.2%, 2.4%]	5

Cycles

Results (primary -2.1%, secondary -4.9%)

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)	-	-	0
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-4.9%	[-5.9%, -2.5%]	5
All ❌✅ (primary)	-2.1%	[-2.1%, -2.1%]	1

Binary size

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

Bootstrap: 490.731s -> 491.187s (0.09%)
Artifact size: 408.59 MiB -> 408.82 MiB (0.06%)

nnethercote · 2026-10-08T02:40:06Z

Improvements outweigh regressions.

@bors r+

rust-bors · 2026-10-08T02:40:09Z

📌 Commit 611e0fd has been approved by nnethercote

It is now in the queue for this repository.

Upgrade `thin-vec` to 0.2.21, including fix for `.collect()` capacity This includes mozilla/thin-vec#99 , which makes thin-vec respect size_hint when collecting. In particular, this causes collections of 1-3 items to not be grown to a capacity of 4. The compiler has a lot of `TinyVec`s in the 1-3 range, so this substantially helps memory, and seems neutral on instructions. For aws-sdk-ec2 full check, this saves 30.69 MiB max-rss (0.55% of peak RSS). --- Merging this avoids the need to work around it in other work (e.g. by replacing `.collect()` with something calling `ThinVec::with_capacity(...)` first).

rust-log-analyzer · 2026-10-08T16:06:57Z

The job test-aarch64-gnu-llvm-22-1 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-10-08T16:07:12Z

💔 Test for 2e13aef failed: CI. Failed job:

auto - test-aarch64-gnu-llvm-22-1 (web logs, enhanced plaintext logs)

joshtriplett · 2026-10-08T16:10:55Z

Looks like a spurious network failure...

@bors r=nnethercote

rust-bors · 2026-10-08T16:10:58Z

📌 Commit 611e0fd has been approved by nnethercote

It is now in the queue for this repository.

A failed build status on this PR was cleared due to the approval.

rust-bors · 2026-10-08T20:23:45Z

☀️ Test successful - CI
Approved by: nnethercote
Duration: 2h 54m 23s
Pushing ae0fe51 to main...

github-actions · 2026-10-08T20:26:59Z

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 65efa19 (parent) -> ae0fe51 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard ae0fe511b15ab760d7e963b13389d1bc2ab42b18 --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-apple: 1h 40m -> 2h 36m (+55.5%)
test-x86_64-gnu-nopt: 1h 40m -> 2h 33m (+51.9%)
test-i686-gnu-nopt-1: 1h 30m -> 2h 14m (+48.0%)
test-i686-gnu-1: 1h 29m -> 2h 11m (+47.1%)
test-x86_64-rust-for-linux: 59m 56s -> 33m 41s (-43.8%)
test-x86_64-gnu-stable: 2h 39m -> 1h 30m (-43.3%)
test-x86_64-gnu-gcc: 1h 27m -> 51m 33s (-40.9%)
test-armhf-gnu: 1h 40m -> 1h (-39.8%)
test-x86_64-gnu-gcc-core-tests: 18m 47s -> 11m 30s (-38.8%)
dist-x86_64-msvc: 3h 13m -> 1h 59m (-38.4%)

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-10-08T21:46:49Z

Finished benchmarking commit (ae0fe51): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.2%	[0.1%, 0.3%]	2
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.2%, -0.1%]	5
All ❌✅ (primary)	0.2%	[0.1%, 0.3%]	2

Max RSS (memory usage)

Results (primary -0.5%, secondary 2.4%)

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

	mean	range	count
Regressions ❌ (primary)	1.3%	[1.3%, 1.4%]	2
Regressions ❌ (secondary)	3.8%	[2.3%, 5.7%]	3
Improvements ✅ (primary)	-1.6%	[-2.1%, -1.3%]	3
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	1
All ❌✅ (primary)	-0.5%	[-2.1%, 1.4%]	5

Cycles

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

Binary size

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

Bootstrap: 485.904s -> 487.56s (0.34%)
Artifact size: 406.44 MiB -> 406.48 MiB (0.01%)

Kobzol · 2026-10-11T15:39:58Z

Dependency update, so not much to do here, but the perf. result is a wash anyway.

@rustbot label: +perf-regression-triaged

rustbot assigned wesleywiser Oct 8, 2026