Skip to content
Permalink

Comparing changes

This is a direct comparison between two commits made in this repository or its related repositories. View the default comparison for this range or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: rust-lang/rust
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: dab7935249469d33eaf4d0540703c8af52172610
Choose a base ref
..
head repository: rust-lang/rust
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 631c445971caf8f86262f4a60d2a95a4a64bde56
Choose a head ref
Showing with 47 additions and 25 deletions.
  1. +47 −25 library/alloc/src/slice.rs
72 changes: 47 additions & 25 deletions library/alloc/src/slice.rs
View file
Original file line number Diff line number Diff line change
@@ -180,15 +180,9 @@ impl<T> [T] {
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*n* \* log(*n*))
/// worst-case.
///
/// 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.
/// If the implementation of [`Ord`] for `T` 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. See also the note on panicking below.
///
/// When applicable, unstable sorting is preferred because it is generally faster than stable
/// sorting and it doesn't allocate auxiliary memory. See
@@ -217,7 +211,15 @@ impl<T> [T] {
///
/// # Panics
///
/// May panic if the implementation of [`Ord`] for `T` does not implement a [total order].
/// May panic if the implementation of [`Ord`] for `T` does not implement a [total order], or if
/// the [`Ord`] implementation itself panics.
///
/// All safe functions on slices preserve the invariant that even if the method 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.
///
/// # Examples
///
@@ -246,10 +248,9 @@ impl<T> [T] {
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*n* \* log(*n*))
/// worst-case.
///
/// If the comparison function `compare` 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 `compare` 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. See also the note on panicking below.
///
/// For example `|a, b| (a - b).cmp(a)` is a comparison function that is neither transitive nor
/// reflexive nor total, `a < b < c < a` with `a = 1, b = 2, c = 3`. For more information and
@@ -268,7 +269,14 @@ impl<T> [T] {
///
/// # Panics
///
/// May panic if `compare` does not implement a [total order].
/// May panic if `compare` does not implement a [total order], or if `compare` itself panics.
///
/// All safe functions on slices preserve the invariant that even if the method 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.
///
/// # Examples
///
@@ -300,10 +308,9 @@ impl<T> [T] {
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*m* \* *n* \* log(*n*))
/// worst-case, where the key function is *O*(*m*).
///
/// If the implementation of [`Ord`] for `K` 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 `K` panics.
/// If the implementation of [`Ord`] for `K` 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. See also the note on panicking below.
///
/// # Current implementation
///
@@ -318,7 +325,15 @@ impl<T> [T] {
///
/// # Panics
///
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order].
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order], or if
/// the [`Ord`] implementation or the key-function `f` panics.
///
/// All safe functions on slices preserve the invariant that even if the method 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.
///
/// # Examples
///
@@ -352,10 +367,9 @@ impl<T> [T] {
/// storage to remember the results of key evaluation. The order of calls to the key function is
/// unspecified and may change in future versions of the standard library.
///
/// If the implementation of [`Ord`] for `K` 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 `K` panics.
/// If the implementation of [`Ord`] for `K` 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. See also the note on panicking below.
///
/// For simple key functions (e.g., functions that are property accesses or basic operations),
/// [`sort_by_key`](slice::sort_by_key) is likely to be faster.
@@ -374,7 +388,15 @@ impl<T> [T] {
///
/// # Panics
///
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order].
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order], or if
/// the [`Ord`] implementation panics.
///
/// All safe functions on slices preserve the invariant that even if the method 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.
///
/// # Examples
///