Make par_slice consistent with single-threaded execution

[zetanumbers]

#152375 removed this consistency by switching from order preserving join to scope, which does not preserve order as stated in par_fns as well. This also makes par_slice behavior consistent with par_fns.

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
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 69 candidates
• Random selection from 16 candidates

[JohnTitor]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 92a974f (92a974f57b8130b5e94def614a94cea0fa4d6845, parent: d1ee5e59a964a419b84b760812a35075034f4861)

[rust-timer]

Finished benchmarking commit (92a974f): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@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)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -2.7%)

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)	-	-	0
Improvements ✅ (secondary)	-2.7%	[-4.6%, -0.9%]	2
All ❌✅ (primary)	-	-	0

Cycles

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

Binary size

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

Bootstrap: 480.488s -> 481.482s (0.21%)
Artifact size: 394.87 MiB -> 394.99 MiB (0.03%)

[zetanumbers]

@rustbot ready

[JohnTitor]

@Zoxc I think it makes sense but do you have any thoughts on this? Just wanna make sure it doesn't hurt your intention.
@zetanumbers Meanwhile, it'd be great if you could squash commits into one.

[Zoxc]

@JohnTitor No, the change is fine.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JohnTitor]

Thank you! @bors r=JohnTitor,Zoxc

View changes since this review

[rust-bors]

📌 Commit 50c564e has been approved by JohnTitor,Zoxc

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: JohnTitor,Zoxc
Duration: 3h 10m 10s
Pushing 7218b7f to main...

[github-actions]

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 e52f547 (parent) -> 7218b7f (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 7218b7fa17e8ef5e99525ae25e6e82224c27039d --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

1. dist-aarch64-linux: 1h 49m -> 2h 29m (+37.2%)
2. pr-check-1: 26m 48s -> 33m 27s (+24.8%)
3. x86_64-gnu-stable: 2h 4m -> 2h 29m (+19.7%)
4. aarch64-gnu-llvm-21-2: 46m 43s -> 55m 43s (+19.3%)
5. aarch64-apple: 3h 2m -> 2h 31m (-16.6%)
6. i686-gnu-2: 1h 31m -> 1h 44m (+15.2%)
7. optional-x86_64-gnu-parallel-frontend: 2h 21m -> 2h 41m (+14.0%)
8. dist-apple-various: 1h 51m -> 1h 36m (-13.6%)
9. i686-gnu-1: 2h 6m -> 2h 24m (+13.6%)
10. x86_64-gnu-tools: 56m 15s -> 1h 3m (+13.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]

Finished benchmarking commit (7218b7f): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (primary -2.5%, secondary -0.5%)

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

Binary size

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

Bootstrap: 483.272s -> 499.005s (3.26%)
Artifact size: 396.98 MiB -> 397.04 MiB (0.01%)