mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-26 00:34:06 +00:00
816f958ac3
Use `partial_cmp` to implement tuple `lt`/`le`/`ge`/`gt` In today's implementation, `(A, B)::gt` contains calls to *both* `A::eq` *and* `A::gt`. That's fine for primitives, but for things like `String`s it's kinda weird -- `(String, usize)::gt` has a call to both `bcmp` and `memcmp` (<https://rust.godbolt.org/z/7jbbPMesf>) because when `bcmp` says the `String`s aren't equal, it turns around and calls `memcmp` to find out which one's bigger. This PR changes the implementation to instead implement `(A, …, C, Z)::gt` using `A::partial_cmp`, `…::partial_cmp`, `C::partial_cmp`, and `Z::gt`. (And analogously for `lt`, `le`, and `ge`.) That way expensive comparisons don't need to be repeated. Technically this is an observable change on stable, so I've marked it `needs-fcp` + `T-libs-api` and will r? rust-lang/libs-api I'm hoping that this will be non-controversial, however, since it's very similar to the observable changes that were made to the derives (#81384 #98655) -- like those, this only changes behaviour if a type overrode behaviour in a way inconsistent with the rules for the various traits involved. (The first commit here is #108156, adding the codegen test, which I used to make sure this doesn't regress behaviour for primitives.) Zulip conversation about this change: <https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60.3E.60.20on.20Tuples/near/328392927>. |
||
|---|---|---|
| .. | ||
| alloc | ||
| backtrace@07872f28cd | ||
| core | ||
| panic_abort | ||
| panic_unwind | ||
| portable-simd | ||
| proc_macro | ||
| profiler_builtins | ||
| rtstartup | ||
| rustc-std-workspace-alloc | ||
| rustc-std-workspace-core | ||
| rustc-std-workspace-std | ||
| std | ||
| stdarch@a0c30f3e3c | ||
| test | ||
| unwind | ||