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

[rust-bors]

☀️ Try build successful (CI)
Build commit: 755ce71 (755ce7187800ec4265e0a582d1b48de6998d9916, parent: 30017c36d6b5e3382ee7cf018d330a6a4a937d39)

[rust-timer]

Finished benchmarking commit (755ce71): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@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.2%	[0.2%, 0.2%]	3
Regressions ❌ (secondary)	0.3%	[0.1%, 1.7%]	19
Improvements ✅ (primary)	-1.6%	[-1.6%, -1.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.2%	[-1.6%, 0.2%]	4

Max RSS (memory usage)

Results (primary 1.2%, secondary 3.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.2%	[1.0%, 1.4%]	3
Regressions ❌ (secondary)	3.2%	[3.0%, 3.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.2%	[1.0%, 1.4%]	3

Cycles

Results (primary -2.4%, secondary 1.2%)

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

Binary size

Results (primary -0.1%, secondary -0.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	1
Regressions ❌ (secondary)	0.1%	[0.0%, 0.2%]	6
Improvements ✅ (primary)	-0.1%	[-0.2%, -0.0%]	11
Improvements ✅ (secondary)	-0.3%	[-0.9%, -0.1%]	9
All ❌✅ (primary)	-0.1%	[-0.2%, 0.2%]	12

Bootstrap: 470.205s -> 469.279s (-0.20%)
Artifact size: 377.38 MiB -> 377.44 MiB (0.02%)

[Randl]

I've removed some of these; I left arrays, NonZero, ControlFlow, slices, str, TypeId, primitives, Option, ranges, Result, and tuples. Again, all seems to be the stuff that we want to be const.

As for perf, I'm not sure how to read it and if something needs to be done? The largest changes seem to be oscillating for some time before this commit, so it may be unrelated?

[clarfonthey]

#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.

[Randl]

@rustbot ready

[oli-obk]

Isn't [const] PartialOrd implied from the super trait bounds?

[oli-obk]

How come F doesn't need a Destruct bound?

[Randl]

I'm not sure? I've added const and then fixed the error messages until it compiled.