Run cargo fmt

Author: nessex

src/radix_key.rs

@@ -18,4 +18,4 @@ impl<T: RadixKey> RadixKeyChecked for T {
         debug_assert!(level < Self::LEVELS);
         self.get_level(level)
     }
-}
+}

src/sorter.rs

@@ -1,6 +1,6 @@
+use crate::radix_key::RadixKeyChecked;
 use crate::tuner::{Algorithm, Tuner, TuningParams};
 use crate::utils::*;
-use crate::radix_key::RadixKeyChecked;
 use arbitrary_chunks::ArbitraryChunks;
 #[cfg(feature = "multi-threaded")]
 use rayon::current_num_threads;

src/sorts/comparative_sort.rs

@@ -21,9 +21,9 @@
 //! small inputs. However for those very small inputs it provides a significant speed-up due to
 //! having essentially no overhead (from count arrays, buffers etc.) compared to a radix sort.
 
+use crate::radix_key::RadixKeyChecked;
 use crate::sorter::Sorter;
 use std::cmp::Ordering;
-use crate::radix_key::RadixKeyChecked;
 
 impl<'a> Sorter<'a> {
     pub(crate) fn comparative_sort<T>(&self, bucket: &mut [T], start_level: usize)

src/sorts/mt_lsb_sort.rs

@@ -28,9 +28,9 @@
 //!
 //! This variant uses the same algorithm as `mt_lsb_sort` but uses it in msb-first order.
 
+use crate::radix_key::RadixKeyChecked;
 use crate::sorter::Sorter;
 use crate::utils::*;
-use crate::radix_key::RadixKeyChecked;
 use arbitrary_chunks::ArbitraryChunks;
 use rayon::prelude::*;
 

src/sorts/out_of_place_sort.rs

@@ -43,8 +43,8 @@
 //!  * single-threaded
 //!  * lsb-first
 
-use crate::utils::*;
 use crate::radix_key::RadixKeyChecked;
+use crate::utils::*;
 
 #[inline]
 pub fn out_of_place_sort<T>(

src/sorts/recombinating_sort.rs

@@ -22,10 +22,10 @@
 //! constraints. As this is an out-of-place algorithm, you need 2n memory relative to the input for
 //! this sort, and eventually the extra allocation and freeing required eats away at the performance.
 
+use crate::radix_key::RadixKeyChecked;
 use crate::sorter::Sorter;
 use crate::sorts::out_of_place_sort::out_of_place_sort;
 use crate::utils::*;
-use crate::radix_key::RadixKeyChecked;
 use arbitrary_chunks::ArbitraryChunks;
 use rayon::prelude::*;
 

src/sorts/regions_sort.rs

@@ -38,10 +38,10 @@
 //! This may not be entirely the same as the algorithm described by the research paper. Some steps
 //! did not seem to provide any value, and have been omitted for performance reasons.
 
+use crate::radix_key::RadixKeyChecked;
 use crate::sorter::Sorter;
 use crate::sorts::ska_sort::ska_sort;
 use crate::utils::*;
-use crate::radix_key::RadixKeyChecked;
 use partition::partition_index;
 use rayon::current_num_threads;
 use rayon::prelude::*;

src/sorts/scanning_sort.rs

@@ -33,9 +33,9 @@
 //! overhead of the thread-local stores and mutexes prevents it from being fast for smaller inputs
 //! however, so it should not be used in all situations.
 
+use crate::radix_key::RadixKeyChecked;
 use crate::sorter::Sorter;
 use crate::utils::*;
-use crate::radix_key::RadixKeyChecked;
 use arbitrary_chunks::ArbitraryChunks;
 use partition::partition_index;
 use rayon::current_num_threads;

src/sorts/ska_sort.rs

@@ -20,9 +20,9 @@
 //! This is generally slower than `lsb_sort` for smaller types T or smaller input arrays. For larger
 //! types or inputs, the memory efficiency of this algorithm can make it faster than `lsb_sort`.
 
+use crate::radix_key::RadixKeyChecked;
 use crate::sorter::Sorter;
 use crate::utils::*;
-use crate::radix_key::RadixKeyChecked;
 use partition::partition_index;
 
 pub fn ska_sort<T>(