From 92221aba7b5f3e1688548cb97f51a21da981e3e2 Mon Sep 17 00:00:00 2001
From: Steven Fackler <sfackler@gmail.com>
Date: Sat, 7 Jun 2014 13:38:24 -0700
Subject: [PATCH 1/2] Fix PartialEq documentation with regards to floats

It is in fact the case that `NaN != NaN`. The true relations for
compareQuietNotEqual are LT, GT *and* UN.

I also rephrased the docs for PartialOrd since floats are not the only
types which are not totally ordered.
---
 src/libcore/cmp.rs | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/libcore/cmp.rs b/src/libcore/cmp.rs
index ef00643177b..5c3e891a2f8 100644
--- a/src/libcore/cmp.rs
+++ b/src/libcore/cmp.rs
@@ -39,13 +39,12 @@
 
 /// Trait for values that can be compared for equality and inequality.
 ///
-/// This trait allows partial equality, where types can be unordered instead of
-/// strictly equal or unequal. For example, with the built-in floating-point
-/// types `a == b` and `a != b` will both evaluate to false if either `a` or
-/// `b` is NaN (cf. IEEE 754-2008 section 5.11).
+/// This trait allows for partial equality, for types that do not have an
+/// equivalence relation. For example, in floating point numbers `NaN != NaN`,
+/// so floating point types implement `PartialEq` but not `Eq`.
 ///
-/// PartialEq only requires the `eq` method to be implemented; `ne` is its negation by
-/// default.
+/// PartialEq only requires the `eq` method to be implemented; `ne` is its
+/// negation by default.
 ///
 /// Eventually, this will be implemented by default for types that implement
 /// `Eq`.
@@ -147,9 +146,10 @@ pub fn lexical_ordering(o1: Ordering, o2: Ordering) -> Ordering {
 /// PartialOrd only requires implementation of the `lt` method,
 /// with the others generated from default implementations.
 ///
-/// However it remains possible to implement the others separately,
-/// for compatibility with floating-point NaN semantics
-/// (cf. IEEE 754-2008 section 5.11).
+/// However it remains possible to implement the others separately for types
+/// which do not have a total order. For example, for floating point numbers,
+/// `NaN < 0 == false` and `NaN >= 0 == false` (cf. IEEE 754-2008 section
+/// 5.11).
 #[lang="ord"]
 pub trait PartialOrd: PartialEq {
     /// This method tests less than (for `self` and `other`) and is used by the `<` operator.

From 6b3d3803eb8437907153bbb1b3c3978b29cd3a3b Mon Sep 17 00:00:00 2001
From: Steven Fackler <sfackler@gmail.com>
Date: Sat, 7 Jun 2014 17:50:45 -0700
Subject: [PATCH 2/2] Clarify restrictions on ne

I can't think of any sane cases where this restriction would not hold,
and the standard library seems to assume it pretty much everywhere.
---
 src/libcore/cmp.rs | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/libcore/cmp.rs b/src/libcore/cmp.rs
index 5c3e891a2f8..b25f69bca40 100644
--- a/src/libcore/cmp.rs
+++ b/src/libcore/cmp.rs
@@ -43,8 +43,10 @@
 /// equivalence relation. For example, in floating point numbers `NaN != NaN`,
 /// so floating point types implement `PartialEq` but not `Eq`.
 ///
-/// PartialEq only requires the `eq` method to be implemented; `ne` is its
-/// negation by default.
+/// PartialEq only requires the `eq` method to be implemented; `ne` is defined
+/// in terms of it by default. Any manual implementation of `ne` *must* respect
+/// the rule that `eq` is a strict inverse of `ne`; that is, `!(a == b)` if and
+/// only if `a != b`.
 ///
 /// Eventually, this will be implemented by default for types that implement
 /// `Eq`.