Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix
Ord
and PartialOrd
differing for FloatOrd
and optimize impl…
…ementation (bevyengine#12711) # Objective - `FloatOrd` currently has a different comparison behavior between its derived `PartialOrd` impl and manually implemented `Ord` impl (The [`Ord` doc](https://doc.rust-lang.org/std/cmp/trait.Ord.html) says this is a logic error). This might be a problem for some `std` containers/algorithms if they rely on both matching, and a footgun for Bevy users. ## Solution - Replace the `PartialEq` and `Ord` impls of `FloatOrd` with some equivalent ones producing [better assembly.](https://godbolt.org/z/jaWbjnMKx) - Manually derive `PartialOrd` with the same behavior as `Ord`, implement the comparison operators. - Add some tests. I first tried using a match-based implementation similar to the `PartialOrd` impl [of the std](https://doc.rust-lang.org/src/core/cmp.rs.html#1457) (with added NaN ordering) but I couldn't get it to produce non-branching assembly. The current implementation is based on [the one from the `ordered_float` crate](https://github.com/reem/rust-ordered-float/blob/3641f59e314030b2ffa3e6321c0d51f8ce50b385/src/lib.rs#L121), adapted since it uses a different ordering. Should this be mentionned somewhere in the code? --- ## Changelog ### Fixed - `FloatOrd` now uses the same ordering for its `PartialOrd` and `Ord` implementations. ## Migration Guide - If you were depending on the `PartialOrd` behaviour of `FloatOrd`, it has changed from matching `f32` to matching `FloatOrd`'s `Ord` ordering, never returning `None`.
- Loading branch information