reword 'sort-by' edge-conditions documentation; resolves #130122

library/alloc/src/slice.rs

@@ -180,10 +180,15 @@ impl<T> [T] {
     /// This sort is stable (i.e., does not reorder equal elements) and *O*(*n* \* log(*n*))
     /// worst-case.
     ///
-    /// If the implementation of [`Ord`] for `T` does not implement a [total order] the resulting
-    /// order of elements in the slice is unspecified. All original elements will remain in the
-    /// slice and any possible modifications via interior mutability are observed in the input. Same
-    /// is true if the implementation of [`Ord`] for `T` panics.
+    /// If the comparison function compare does not implement a [total order], the function may
+    /// panic; even if the function exits normally, the resulting order of elements in the slice is
+    /// unspecified.
+    ///
+    /// Even if `sort_by` or `compare` panics, all original elements will remain in the slice and
+    /// any possible modifications via interior mutability are observed in the input. This ensures
+    /// that recovery code (for instance inside of a `Drop` or following a `catch_unwind`) will
+    /// still have access to all the original elements. For instance, if the slice belongs to a
+    /// `Vec`, the `Vec::drop` method will be able to dispose of all contained elements.
     ///
     /// When applicable, unstable sorting is preferred because it is generally faster than stable
     /// sorting and it doesn't allocate auxiliary memory. See