Rollup of 6 pull requests

[matthiaskrgr]

Successful merges:

• fix std::thread docs are unclear regarding stack sizes #104537 (fix std::thread docs are unclear regarding stack sizes)
• Don't assume FILE_ID_BOTH_DIR_INFO will be aligned #104558 (Don't assume FILE_ID_BOTH_DIR_INFO will be aligned)
• interpret: use Either over Result when it is not representing an error condition #104564 (interpret: use Either over Result when it is not representing an error condition)
• clarify that realloc refreshes pointer provenance even when the allocation remains in-place #104568 (clarify that realloc refreshes pointer provenance even when the allocation remains in-place)
• rustdoc: use real buttons for scrape examples controls #104611 (rustdoc: use real buttons for scrape examples controls)
• Migrate kdb style to CSS variables #104640 (Migrate kdb style to CSS variables)

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

[matthiaskrgr]

@bors r+ rollup=never p=6

[bors]

📌 Commit 2aa7f54 has been approved by matthiaskrgr

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2aa7f54 with merge a28f3c8...

[bors]

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing a28f3c8 to master...

[rust-timer]

📌 Perf builds for each rolled up PR:

PR#	Perf Build Sha
#104640	2651bb59e2f7a0ad141ff65b387dd63dbd6c5ee9
#104611	9547f6a6fa67fbb907415d51a6eb7585f33f9590
#104568	2b95b5e394ded34850c42fa5f9de85ade6549f49
#104564	793d7ee883b660b852a4d0588fb1a323246a51b1
#104558	48b4c86dd8dc21636a715eff59fa883156d8c3a1
#104537	2e85a899f4da80e0b9b0340d223850f786b763a5

previous master: 911cbf8e46

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

[rust-timer]

Finished benchmarking commit (a28f3c8): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.4%, 0.9%]	7
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.4%	[-2.1%, -0.4%]	9
All ❌✅ (primary)	0.7%	[0.4%, 0.9%]	7

Max RSS (memory usage)

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

Cycles

Results

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)	-10.3%	[-10.9%, -9.9%]	6
All ❌✅ (primary)	-	-	0

[lqd]

The regressions are recent bitmaps noise:
@rustbot label: +perf-regression-triaged

However, it'd be nice to showcase the PR bringing the wins in the weekly report, likely #104564:
@rust-timer build 793d7ee883b660b852a4d0588fb1a323246a51b1

[rust-timer]

Finished benchmarking commit (793d7ee883b660b852a4d0588fb1a323246a51b1): comparison URL.

Overall result: ✅ improvements - 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-review -S-waiting-on-perf -perf-regression

Instruction count

This is a highly reliable metric that was 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)	-1.6%	[-2.5%, -0.4%]	9
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

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

Cycles

Results

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)	-10.0%	[-11.2%, -8.9%]	6
All ❌✅ (primary)	-	-	0

[lqd]

(it would be cool if the post-merge perfbot messages wouldn't change the labels while we're investigating PRs within a rollup)

Note for weekly triage: the regressions here were noise, and the cool CTFE wins are coming from @RalfJung's #104564.

And since it improved eval_to_allocation_raw, it's likely going to improve real-word CTFE-heavy crates (that we don't track in rustc-perf) similarly to ctfe-stress-5, and the ones in all the issues about big consts & statics being slow to compile.

[RalfJung]

Uh, why would using Either over Result result in a perf win...?^^

[RalfJung]

Maybe swapping the order of types in read_immediate_raw was a perf win, but that would still be really surprising.

[lqd]

My theory was that it simplified the previous Err codepaths (e.g. removing some Try-related error conversions code), similar to making fallible code infallible which usually results in better codegen -- but I haven't checked.

[RalfJung]

No, Err was always replaced by Left/Right and no ? were removed.