chore: update rustc-hash 2.1.0 to 2.1.1

[lsunsi]

This PR updates the rustc-hash crate to include a palliative fix for #135477.
The discussion for this can be found in the issue and on rust-lang/rustc-hash#55.

This PR is the output of running cargo +nightly update rustc-hash@2.1.0. I ran all tests locally and they all seem to pass, with the exception of tests/ui/process/nofile-limit.rs which always fails on my setup.

@steffahn @orlp and @Noratrieb all have full context on this, I'm opening the pull request trying to be helpful. I'm not sure if anything else needs to be done, like documentation I'm not aware of or running any special CIs but if I can do anything else please let me know!

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

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.

[lqd]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 62c2f65 with merge 2b6f2af...

[Noratrieb]

Thanks!

tests/ui/process/nofile-limit.rs which always fails on my setup.

you need to install glibc-static for that test to work (not that it really matters it's fine).

Let's have a final look at perf but it should be fine.

I'm nominating this for a beta backport since this is a large compile time regression for some projects.

[bors]

☀️ Try build successful - checks-actions
Build commit: 2b6f2af (2b6f2afaae5aaf495bd89cc1f9e9aa4f44fa2570)

[lqd]

come on, bot. @rust-timer build 2b6f2af

[lsunsi]

@Noratrieb Got it, thanks a lot! The backport would really be helpful to me and my team, since we always try to stay current with rust versions and we're currently stuck on 1.83 haha

[rust-timer]

Finished benchmarking commit (2b6f2af): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (primary 1.0%, secondary 2.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	2.8%	[2.0%, 4.2%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[1.0%, 1.0%]	1

Binary size

Results (secondary -0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Bootstrap: 778.801s -> 779.894s (0.14%)
Artifact size: 328.78 MiB -> 328.13 MiB (-0.20%)

[lqd]

ok, let’s hope this is enough for now :)

r? lqd @bors r+

[bors]

📌 Commit 62c2f65 has been approved by lqd

It is now in the queue for this repository.

[lsunsi]

@lqd Out of curiosity, I'be checking up on the queue and I'm curious to understand how it works. What does "mergeable" mean? And what are the rolloups, how do they work?

Sorry to bother with random questions, I'm just using this experience to learn more how stuff works around here

[steffahn]

@lsunsi see: https://rustc-dev-guide.rust-lang.org/tests/ci.html#merging-prs-serially-with-bors

[lsunsi]

@steffahn you're like, the best. thanks a lot I'll read it up

[steffahn]

Not sure about “Mergeable” column when there isn’t any entry; but if I had to guess, perhaps only shows “yes” if it used to be “no” in the past (which looks like it can be e.g. from a failed build or merge conflict or so, when bors detects this and complains in the issue – edit: looking through more examples, that’s not quite it; I’m really not sure).

I’ve also found more info about rollups, there’s a guide for rust maintainers on how to create them: https://forge.rust-lang.org/release/rollups.html

[Zalathar]

Rollups are basically a workaround for the fact that:

• We want to run full CI on every single merge, but
• If we ran full CI on every single PR, that would take ages

So instead, approved PRs get bundled into “rollup” PRs, manually (with the help of a tool). If the rollup passes CI, great, all the PRs in the rollup can merge immediately. If the rollup fails CI, someone will figure out which PR was probably responsible, and unapprove it while the author fixes the problem. In the meantime, the build queue will move on to the next PR, which might be another rollup.

Some PRs get marked rollup=never for various reasons, typically to make it easier to track down performance regressions or other problems.

[lsunsi]

@Zalathar Makes a lot sense, thanks for the explanation!

[lsunsi]

@lqd I ended up reading up this doc which mentioned that issues nomited for backport could get prority in the queue. Since @Noratrieb mentioned about backporting this, does that mean this PR could be given some priority?

[lqd]

This PR already has priority over normal PRs.

[lsunsi]

@lqd Nice, I didn't know that! I saw the priority column equal 0 and assumed, my bad. How come it already has priority?

[lqd]

The queue is sorted using multiple fields, but for this case here PRs with rollup=never come before others at the same priority level. Your PR is near the top of the queue, it won’t take much longer.

[lsunsi]

@lqd It's all good, I'm just keeping a close eye because using this experience to learn how things work around here. It's been pretty interesting to me

[steffahn]

@lsundi FYI, how fast this PR gets merged to nightly isn't very relevant for the backport; for now, the backport decision is waiting for the next T-compiler meeting next Thursday (Feb 13) anyway. After which the last (regular) merge of beta backports would be done, which is a PR created manually; this will be done before the new stable branch is being created on Monday (Feb 17), on path for a release on the Thursday after (Feb 20).

See:

• https://forge.rust-lang.org/release/backporting.html
• https://forge.rust-lang.org/release/process.html

---

Also, everything else being equal, PRs in the queue are sorted by creation date, so the longer this waits, the higher the priority gets. (I bet it'll be merged within the next 24h anyway, AFAICT there's been a number of only slightly (a few hours) older rollup=never PRs already merged making it to the top within the last day; e.g. #136585 and #136586.)

[lsunsi]

@steffahn As usual your explanation made everything clearer! I'll keep keeping a close watch on things, I'll try to follow the meeting too. Thanks again

[jieyouxu]

@bors p=5 (rollup scheduling)

[bors]

⌛ Testing commit 62c2f65 with merge 92bedea...

[bors]

☀️ Test successful - checks-actions
Approved by: lqd
Pushing 92bedea to master...

[rust-timer]

Finished benchmarking commit (92bedea): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary -2.0%, secondary -2.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	5.0%	[3.2%, 6.3%]	3
Improvements ✅ (primary)	-2.0%	[-2.5%, -0.5%]	15
Improvements ✅ (secondary)	-3.3%	[-4.2%, -1.6%]	23
All ❌✅ (primary)	-2.0%	[-2.5%, -0.5%]	15

Cycles

Results (secondary 0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.7%	[2.5%, 2.9%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.8%, -1.0%]	4
All ❌✅ (primary)	-	-	0

Binary size

Results (secondary -0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Bootstrap: 785.608s -> 786.984s (0.18%)
Artifact size: 348.20 MiB -> 347.64 MiB (-0.16%)

[apiraino]

Beta backport accepted as per compiler team on Zulip. If this will have adverse side-effects, we will discover anyway in 1.86, so it makes sense to test it now.

A backport PR will be authored by the release team at the end of the current development cycle. Backport labels handled by them.

@rustbot label +beta-accepted