Constify Eq, Ord, PartialOrd

[Randl]

Adds #[const_trait] and impls for Eq, Ord, PartialOrd. Impl for some other traits (e.g., slices and arrays) are blocked mainly on const closures (#106003).
For TypeId Ord we need const pointer comparison (#53020)
Tracking issue #143800

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
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

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[compiler-errors]

Squash this into one commit please

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Randl]

@rustbot ready

[ShoyuVanilla]

Not a review but just a question as I don't know the contexts very well 😅
I guess PartialEq and Eq could be const impl'd on tuples as well?

[Randl]

Fair enough, I've added impl const for tuples

[compiler-errors]

Sorry for taking a long time to review this. I'm actually somewhat uncomfortable by the scope of this PR. Could you please limit the number of types that this adds const impls for to just types that seem relevant for const programming?

Specifically, things like:

#[derive(Copy, Debug)]
#[derive_const(Clone, PartialEq, Eq)]
pub struct AllocError;

Don't seem really relevant here. I think this constification could probably just stick to constifying some impls for built-in types and other important types, and not just try to constify everything that can be constified in the standard library.

Also, since this adds new bounds to things, let's run a perf test.

@bors2 try @rust-timer queue

[compiler-errors]

@rustbot author

[fee1-dead]

#143949 also caused some minor perf regressions, but so far nobody from wg-const-eval has commented on whether this is considered acceptable or not. Right now my understanding is that the goal is to constify everything, but there may need to be some changes with consteval since my suspicion is that the built-in stuff to allow these operators to work even without trait impls on primitives may now be slower with the const trait impls present and enabled.

Note that regressions on the PR you linked was ultimately triaged at the rollup.

Those negative perf results are due to making built-in traits const, which then increases the times where we have to check const conditions of traits, find implied predicates (super traits), etc. They're pretty much unavoidable, there's nothing much we can do, and we'll have to stick with it if we want libstd constified.

[oli-obk]

Some leftover syntax, otherwise lgtm

[rustbot]

This PR was rebased onto a different master commit! Check out the changes with our range-diff.

[oli-obk]

@bors r+

[bors]

📌 Commit f70c98f has been approved by oli-obk

It is now in the queue for this repository.

[jieyouxu]

@bors p=4 (rollup interleaving)

[bors]

⌛ Testing commit f70c98f with merge 953f713...

[bors]

💔 Test failed - checks-actions

[clarfonthey]

Appears to be a legitimate codegen failure related to Ord, but I'm not exactly sure why there'd be a regression here. Might just fix itself with a rebase.

[Randl]

Ok. It is a legitimate codegen failure; I can reproduce it locally, including after rebase. I do not understand what is specifically wrong with the codegen (cc @scottmcm ), but the reason appears to be this change:

https://github.com/rust-lang/rust/pull/144847/files#diff-b3bc3e9849f0b9690cf061db39e229a23495e0ff8dd3eded8e2ac5d9bb3eb7a7L215-R232

I'm unsure why the difference between the while loop and the for loop results in incorrect codegen. I can revert this specific change for now (it doesn't give us slice Ord anyway because that requires const closures, for example, in

rust/library/core/src/slice/cmp.rs

Line 186 in f70c98f

let len_chain = |a: &_, b: &_| ControlFlow::Break(usize::partial_cmp(a, b));

) until we either figure out how to make the while loop work with codegen, or we can use for in const code (though if I understand correctly, this will require iterators, which by themselves will probably depend on this code).

[bors]

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

[Randl]

Ok I've pushed the version that drops the const-hack in slice code. cc @oli-obk

[rustbot]

This PR was rebased onto a different master 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.

[clarfonthey]

Since this was removed from the queue, could you also replace the references to the const_from feature with const_convert so it no longer conflicts with my PR? You don't need to fix it everywhere, just on the traits you make const for this PR.

[jhpratt]

@bors p=0

No longer needed to thread between rollups, as the queue is back to normal now.