cargo fmt --all

state-chain/amm/src/limit_orders.rs

@@ -39,8 +39,8 @@ use crate::common::{
 // LP attempts to add more liquidity that would increase the total at the tick past this value, the
 // minting operation will error. Note this maximum is for all lps combined, and not a single lp,
 // therefore it is possible for an LP to "consume" a tick by filling it up to the maximum, and
-// thereby not allowing other LPs to mint at that price (But the maximum is high enough that this is not
-// feasible).
+// thereby not allowing other LPs to mint at that price (But the maximum is high enough that this is
+// not feasible).
 const MAX_FIXED_POOL_LIQUIDITY: Amount = U256([u64::MAX, u64::MAX, 0, 0] /* little endian */);
 
 /// Represents a number exclusively between 0 and 1.
@@ -329,11 +329,11 @@ struct Position {
 
 #[derive(Clone, Debug, TypeInfo, Encode, Decode, MaxEncodedLen)]
 pub(super) struct FixedPool {
-	/// Whenever a FixedPool is destroyed and recreated i.e. all the liquidity in the FixedPool is used,
-	/// a new value for pool_instance is used, and the previously used value will never be used again.
-	/// This is used to determine whether a position was created during the current FixedPool's
-	/// lifetime and therefore that FixedPool's `percent_remaining` is meaningful for the position,
-	/// or if the position was created before the current FixedPool's lifetime.
+	/// Whenever a FixedPool is destroyed and recreated i.e. all the liquidity in the FixedPool is
+	/// used, a new value for pool_instance is used, and the previously used value will never be
+	/// used again. This is used to determine whether a position was created during the current
+	/// FixedPool's lifetime and therefore that FixedPool's `percent_remaining` is meaningful for
+	/// the position, or if the position was created before the current FixedPool's lifetime.
 	pool_instance: u128,
 	/// This is the total liquidity/amount available for swaps at this price. This value is greater
 	/// than or equal to the amount provided currently by all positions at the same tick. It is not

state-chain/amm/src/range_orders.rs

@@ -123,9 +123,9 @@ impl Position {
 #[derive(Clone, Debug, TypeInfo, Encode, Decode, MaxEncodedLen)]
 pub struct TickDelta {
 	/// This is the change in the total amount of liquidity in the pool at this price, i.e. if the
-	/// price moves from a lower price to a higher one above this tick (higher/lower in literal integer
-	/// value), the liquidity will increase by `liquidity_delta` and therefore swaps (In both
-	/// directions) will experience less slippage (Assuming liquidity_delta is positive).
+	/// price moves from a lower price to a higher one above this tick (higher/lower in literal
+	/// integer value), the liquidity will increase by `liquidity_delta` and therefore swaps (In
+	/// both directions) will experience less slippage (Assuming liquidity_delta is positive).
 	liquidity_delta: i128,
 	/// This is the sum of the liquidity of all the orders that start or end at this tick. Note
 	/// this is the value that MAX_TICK_GROSS_LIQUIDITY applies to.

state-chain/pallets/cf-pools/src/lib.rs

@@ -293,8 +293,8 @@ pub mod pallet {
 	pub type AssetAmounts = AssetsMap<AssetAmount>;
 
 	/// Represents an amount of liquidity, either as an exact amount, or through maximum and minimum
-	/// amounts of both assets. Internally those max/min are converted into exact liquidity amounts, that is if
-	/// the appropiate asset ratio can be achieved while maintaining the max/min bounds.
+	/// amounts of both assets. Internally those max/min are converted into exact liquidity amounts,
+	/// that is if the appropiate asset ratio can be achieved while maintaining the max/min bounds.
 	#[derive(
 		Copy,
 		Clone,
@@ -794,10 +794,10 @@ pub mod pallet {
 		/// of liquidity. The appropiate assets will be debited or credited from your balance as
 		/// needed. If the order_id isn't being used at the moment you must specify a tick,
 		/// otherwise it will not know what tick you want the order to be over. Note limit order
-		/// order_id's are independent of range order order_id's. In addition to that, order_id's for
-		/// buy and sell limit orders i.e. those in different directions are independent. Therefore
-		/// you may have two limit orders with the same order_id in the same pool, one to buy Eth
-		/// and one to sell Eth for example.
+		/// order_id's are independent of range order order_id's. In addition to that, order_id's
+		/// for buy and sell limit orders i.e. those in different directions are independent.
+		/// Therefore you may have two limit orders with the same order_id in the same pool, one to
+		/// buy Eth and one to sell Eth for example.
 		#[pallet::call_index(5)]
 		#[pallet::weight(T::WeightInfo::update_limit_order())]
 		pub fn update_limit_order(
@@ -869,11 +869,11 @@ pub mod pallet {
 		/// Optionally move the order to a different tick and then set its amount of liquidity. The
 		/// appropiate assets will be debited or credited from your balance as needed. If the
 		/// order_id isn't being used at the moment you must specify a tick, otherwise it will not
-		/// know what tick you want the order to be over. Note limit order order_id's are independent
-		/// of range order order_id's. In addition to that, order_id's for buy and sell limit orders
-		/// i.e. those in different directions are independent. Therefore you may have two limit
-		/// orders with the same order_id in the same pool, one to buy Eth and one to sell Eth for
-		/// example.
+		/// know what tick you want the order to be over. Note limit order order_id's are
+		/// independent of range order order_id's. In addition to that, order_id's for buy and sell
+		/// limit orders i.e. those in different directions are independent. Therefore you may have
+		/// two limit orders with the same order_id in the same pool, one to buy Eth and one to sell
+		/// Eth for example.
 		#[pallet::call_index(6)]
 		#[pallet::weight(T::WeightInfo::set_limit_order())]
 		pub fn set_limit_order(