Rollup merge of #61665 - aschampion:slice-eq-ptr, r=sfackler

core: check for pointer equality when comparing Eq slices

Because `Eq` types must be reflexively equal, an equal-length slice to the same memory location must be equal.

This is related to #33892 (and #32699) answering this comment from that PR:

> Great! One more easy question: why does this optimization not apply in the non-BytewiseEquality implementation directly above?

Because slices of non-reflexively equal types (like `f64`) are not equal even if it's the same slice. But if the types are `Eq`, we can use this same-address optimization, which this PR implements. Obviously this changes behavior if types violate the reflexivity condition of `Eq`, because their impls of `PartialEq` will no longer be called per-item, but 🤷‍♂ .

It's not clear how often this optimization comes up in the real world outside of the same-`&str` case covered by #33892, so **I'm requesting a perf run** (on MacOS today, so can't run `rustc_perf` myself). I'm going ahead and making the PR on the basis of being surprised things didn't already work this way.

This is my first time hacking rust itself, so as a perf sanity check I ran `./x.py bench --stage 0 src/lib{std,alloc}`, but the differences were noisy.

To make the existing specialization for `BytewiseEquality` explicit, it's now a supertrait of `Eq + Copy`. `Eq` should be sufficient, but `Copy` was included for clarity.

0 files changed, 0 insertions, 0 deletions