add slice::swap_unchecked

[ibraheemdev]

An unsafe version of slice::swap that does not do bounds checking.

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[leonardo-m]

See #71874

[leonardo-m]

I think it's worth using this inside slice::reverse.

[camelid]

triage: @ibraheemdev could you address the above comments? Thanks!

[kennytm]

@bors r+

[bors]

📌 Commit cf12732 has been approved by kennytm

[matthiaskrgr]

@bors rollup=never likely has some perf effects

[bors]

⌛ Testing commit cf12732 with merge 1dafe6d...

[bors]

☀️ Test successful - checks-actions
Approved by: kennytm
Pushing 1dafe6d to master...

[rust-timer]

Finished benchmarking commit (1dafe6d): comparison url.

Summary: This change led to small relevant regressions 😿 in compiler performance.

• Small regression in instruction counts (up to 1.5% on full builds of piston-image)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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

[kennytm]

maybe revert the implementation of the safe swap, keeping swap and swap_unchecked separate? at least we don't need to do bounds checking 4 times in debug build.

[rylev]

@kennytm @ibraheemdev this seems to have landed with more bounds checking than is necessary though I would imagine that the extra checking shouldn't be happening in the compiler since debug assertions are off. While the regressions aren't huge, they are in real world crates and this is likely to effect the perf of many (most?) Rust programs in a negative way. Perhaps we should do the suggestion of reverting the implementation of the safe swap since it's not necessary for swap_unchecked to land.

Also FYI, when it's likely that a perf regression could come out of a change (as was pointed out) it's best to just run a perf run before merging.

[camelid]

While the regressions aren't huge, they are in real world crates and this is likely to effect the perf of many (most?) Rust programs in a negative way.

IIRC, std is always distributed with debug-assertions turned off (unless you build std yourself), so while it'd be good to fix the redundant bounds checks, I think it's unlikely to affect that many user crates.

I'm also surprised that there's a regression; like you said, I thought the compiler was by default built with debug assertions turned off. Maybe the bounds checks are not the source of the regression?