chore: clippy happy (#8362)

Co-authored-by: Alexey Shekhirin <a.shekhirin@gmail.com>
This commit is contained in:
Matthias Seitz
2024-05-23 13:24:20 +02:00
committed by GitHub
parent 155876d28c
commit 4250c33da1
28 changed files with 70 additions and 76 deletions

View File

@@ -34,16 +34,16 @@
//!
//! In essence the transaction pool is made of three separate sub-pools:
//!
//! - Pending Pool: Contains all transactions that are valid on the current state and satisfy
//! (3. a)(1): _No_ nonce gaps. A _pending_ transaction is considered _ready_ when it has the lowest
//! nonce of all transactions from the same sender. Once a _ready_ transaction with nonce `n` has
//! been executed, the next highest transaction from the same sender `n + 1` becomes ready.
//! - Pending Pool: Contains all transactions that are valid on the current state and satisfy (3.
//! a)(1): _No_ nonce gaps. A _pending_ transaction is considered _ready_ when it has the lowest
//! nonce of all transactions from the same sender. Once a _ready_ transaction with nonce `n` has
//! been executed, the next highest transaction from the same sender `n + 1` becomes ready.
//!
//! - Queued Pool: Contains all transactions that are currently blocked by missing
//! transactions: (3. a)(2): _With_ nonce gaps or due to lack of funds.
//! - Queued Pool: Contains all transactions that are currently blocked by missing transactions:
//! (3. a)(2): _With_ nonce gaps or due to lack of funds.
//!
//! - Basefee Pool: To account for the dynamic base fee requirement (3. b) which could render
//! an EIP-1559 and all subsequent transactions of the sender currently invalid.
//! - Basefee Pool: To account for the dynamic base fee requirement (3. b) which could render an
//! EIP-1559 and all subsequent transactions of the sender currently invalid.
//!
//! The classification of transactions is always dependent on the current state that is changed as
//! soon as a new block is mined. Once a new block is mined, the account changeset must be applied

View File

@@ -90,9 +90,9 @@ impl<T: TransactionOrdering> PendingPool<T> {
/// Returns an iterator over all transactions that are _currently_ ready.
///
/// 1. The iterator _always_ returns transaction in order: It never returns a transaction with
/// an unsatisfied dependency and only returns them if dependency transaction were yielded
/// previously. In other words: The nonces of transactions with the same sender will _always_
/// increase by exactly 1.
/// an unsatisfied dependency and only returns them if dependency transaction were yielded
/// previously. In other words: The nonces of transactions with the same sender will _always_
/// increase by exactly 1.
///
/// The order of transactions which satisfy (1.) is determent by their computed priority: A
/// transaction with a higher priority is returned before a transaction with a lower priority.

View File

@@ -1002,6 +1002,7 @@ impl<T: PoolTransaction> AllTransactions<T> {
/// For all transactions:
/// - decreased basefee: promotes from `basefee` to `pending` sub-pool.
/// - increased basefee: demotes from `pending` to `basefee` sub-pool.
///
/// Individually:
/// - decreased sender allowance: demote from (`basefee`|`pending`) to `queued`.
/// - increased sender allowance: promote from `queued` to