[WIP] Constified slice::sort_unstable, sort_internals

[onestacked]

Constifies most of the sort related functions in core.

TODO:

• Probably not worth it to land this before Improve performance of unstable sort #104116
• Make sure no const UB occurs.
• Maybe wait for Allow const iterator implementations #102225 to land and use the Iterator functions and for loops instead of manual while loops again.
• Wait for Const closures #106004 so that Normal Closures can be used.
• Add some const tests. (or change existing ones to const?)
• Open tracking issue #Tracking Issue for unstable sorting in const context #102307
• Maybe try to find a way to restructure to reduce the amount of unsafe.

cc @RalfJung @fee1-dead

[rust-highfive]

r? @Mark-Simulacrum

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

[onestacked]

Should those helper functions themself be unsafe?

[RalfJung]

Yes they should, and they should document their precondition.

[onestacked]

But the the same safety comment would be duplicated 9 times for lt, 4 times for eq and 10 times for width.

[RalfJung]

That indicates that the code is repeatedly doing the same subtle safety-relevant reasoning. This doesn't get better by not talking about it, it only gets better by restructuring the code in a way that avoids doing subtle safety-relevant reasoning in many places. (I don't know if that is possible, I don't have the time to do a detailed code review -- sorry.)

[onestacked]

How should the const safety of this be verified?

What should the safety comment be exactly?

cc @RalfJung

[RalfJung]

You need to explain why these pointers are in the same allocation and their distance is an integer multiple of their size.

I am not familiar with this code unfortunately and won't be able to do a detailed review.

[onestacked]

cc @Gankra since the comment about maybe migrating was by them.

[onestacked]

The current sort relies on comparing with null pointers, which is (currently) UB.

I could add checks using ptr::is_null, but that would have some runtime cost.
I could use const_eval_select to use normal pointer comparison in RT
and add additional null checks at CT and then use ptr::offset_from.

I could investigate if i can adapt the algorithm to avoid null pointers but I don't know if that will be possible without large changes to the algorithm itself.

[onestacked]

I went with adding null pointer checks at CT using const_eval_select.
I think that it should be sound now, but a thorough review by someone who knows this code and const unsafety well is probably needed.

[bors]

☔ The latest upstream changes (presumably #104591) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #107143) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #107191) made this pull request unmergeable. Please resolve the merge conflicts.