chore: apply fmt

Author: luisschwab

crates/bitcoind_rpc/src/lib.rs

@@ -1,7 +1,8 @@
 //! This crate is used for emitting blockchain data from the `bitcoind` RPC interface. It does not
 //! use the wallet RPC API, so this crate can be used with wallet-disabled Bitcoin Core nodes.
 //!
-//! [`Emitter`] is the main structure which sources blockchain data from [`bitcoincore_rpc::Client`].
+//! [`Emitter`] is the main structure which sources blockchain data from
+//! [`bitcoincore_rpc::Client`].
 //!
 //! To only get block updates (exclude mempool transactions), the caller can use
 //! [`Emitter::next_block`] until it returns `Ok(None)` (which means the chain tip is reached). A
@@ -47,8 +48,8 @@ pub struct Emitter<C> {
     /// A set of txids currently assumed to still be in the mempool.
     ///
     /// This is used to detect mempool evictions by comparing the set against the latest mempool
-    /// snapshot from bitcoind. Any txid in this set that is missing from the snapshot is considered
-    /// evicted.
+    /// snapshot from bitcoind. Any txid in this set that is missing from the snapshot is
+    /// considered evicted.
     ///
     /// When the emitter emits a block, confirmed txids are removed from this set. This prevents
     /// confirmed transactions from being mistakenly marked with an `evicted_at` timestamp.
@@ -124,8 +125,8 @@ where
         // Loop to make sure that the fetched mempool content and the fetched tip are consistent
         // with one another.
         let (raw_mempool, raw_mempool_txids, rpc_height, rpc_block_hash) = loop {
-            // Determine if height and hash matches the best block from the RPC. Evictions are deferred
-            // if we are not at the best block.
+            // Determine if height and hash matches the best block from the RPC. Evictions are
+            // deferred if we are not at the best block.
             let height = client.get_block_count()?;
             let hash = client.get_block_hash(height)?;
 
@@ -232,9 +233,9 @@ pub struct MempoolEvent {
     ///
     /// To understand the second condition, consider a receiver which filters transactions based on
     /// whether it alters the UTXO set of tracked script pubkeys. If an emitted mempool transaction
-    /// spends a tracked UTXO which is confirmed at height `h`, but the receiver has only seen up to
-    /// block of height `h-1`, we want to re-emit this transaction until the receiver has seen the
-    /// block at height `h`.
+    /// spends a tracked UTXO which is confirmed at height `h`, but the receiver has only seen up
+    /// to block of height `h-1`, we want to re-emit this transaction until the receiver has
+    /// seen the block at height `h`.
     pub new_txs: Vec<(Transaction, u64)>,
 
     /// [`Txid`]s of all transactions that have been evicted from mempool.
@@ -263,8 +264,8 @@ pub struct BlockEvent<B> {
     /// The checkpoint of the new block.
     ///
     /// A [`CheckPoint`] is a node of a linked list of [`BlockId`]s. This checkpoint is linked to
-    /// all [`BlockId`]s originally passed in [`Emitter::new`] as well as emitted blocks since then.
-    /// These blocks are guaranteed to be of the same chain.
+    /// all [`BlockId`]s originally passed in [`Emitter::new`] as well as emitted blocks since
+    /// then. These blocks are guaranteed to be of the same chain.
     ///
     /// This is important as BDK structures require block-to-apply to be connected with another
     /// block in the original chain.

crates/chain/src/indexed_tx_graph.rs

@@ -95,7 +95,8 @@ where
 
     /// Apply an `update` directly.
     ///
-    /// `update` is a [`tx_graph::TxUpdate<A>`] and the resultant changes is returned as [`ChangeSet`].
+    /// `update` is a [`tx_graph::TxUpdate<A>`] and the resultant changes is returned as
+    /// [`ChangeSet`].
     pub fn apply_update(&mut self, update: tx_graph::TxUpdate<A>) -> ChangeSet<A, I::ChangeSet> {
         let tx_graph = self.graph.apply_update(update);
         let indexer = self.index_tx_graph_changeset(&tx_graph);
@@ -341,7 +342,9 @@ where
 {
     /// List txids that are expected to exist under the given spks.
     ///
-    /// This is used to fill [`SyncRequestBuilder::expected_spk_txids`](bdk_core::spk_client::SyncRequestBuilder::expected_spk_txids).
+    /// This is used to fill
+    /// [`SyncRequestBuilder::expected_spk_txids`](bdk_core::spk_client::SyncRequestBuilder::expected_spk_txids).
+    ///
     ///
     /// The spk index range can be contrained with `range`.
     ///

crates/chain/src/indexer/keychain_txout.rs

@@ -70,8 +70,8 @@ pub const DEFAULT_LOOKAHEAD: u32 = 25;
 ///
 /// # Change sets
 ///
-/// Methods that can update the last revealed index or add keychains will return [`ChangeSet`] to report
-/// these changes. This should be persisted for future recovery.
+/// Methods that can update the last revealed index or add keychains will return [`ChangeSet`] to
+/// report these changes. This should be persisted for future recovery.
 ///
 /// ## Synopsis
 ///
@@ -569,8 +569,8 @@ impl<K: Clone + Ord + Debug> KeychainTxOutIndex<K> {
             .map(|((_, i), spk)| (*i, spk))
     }
 
-    /// Get the next derivation index for `keychain`. The next index is the index after the last revealed
-    /// derivation index.
+    /// Get the next derivation index for `keychain`. The next index is the index after the last
+    /// revealed derivation index.
     ///
     /// The second field in the returned tuple represents whether the next derivation index is new.
     /// There are two scenarios where the next derivation index is reused (not new):
@@ -708,8 +708,8 @@ impl<K: Clone + Ord + Debug> KeychainTxOutIndex<K> {
     /// This will derive and reveal a new script pubkey if no more unused script pubkeys exist.
     ///
     /// If the descriptor has no wildcard and already has a used script pubkey or if a descriptor
-    /// has used all scripts up to the derivation bounds, then the last derived script pubkey will be
-    /// returned.
+    /// has used all scripts up to the derivation bounds, then the last derived script pubkey will
+    /// be returned.
     ///
     /// Returns `None` if there are no script pubkeys that have been used and no new script pubkey
     /// could be revealed (see [`reveal_next_spk`] for when this happens).

crates/chain/src/indexer/spk_txout.rs

@@ -1,4 +1,5 @@
-//! [`SpkTxOutIndex`] is an index storing [`TxOut`]s that have a script pubkey that matches those in a list.
+//! [`SpkTxOutIndex`] is an index storing [`TxOut`]s that have a script pubkey that matches those in
+//! a list.
 
 use core::ops::RangeBounds;
 
@@ -15,14 +16,14 @@ use bitcoin::{Amount, OutPoint, ScriptBuf, SignedAmount, Transaction, TxOut, Txi
 /// index will look at any txouts you pass in and store and index any txouts matching one of its
 /// script pubkeys.
 ///
-/// Each script pubkey is associated with an application-defined index script index `I`, which must be
-/// [`Ord`]. Usually, this is used to associate the derivation index of the script pubkey or even a
-/// combination of `(keychain, derivation_index)`.
+/// Each script pubkey is associated with an application-defined index script index `I`, which must
+/// be [`Ord`]. Usually, this is used to associate the derivation index of the script pubkey or even
+/// a combination of `(keychain, derivation_index)`.
 ///
 /// Note there is no harm in scanning transactions that disappear from the blockchain or were never
 /// in there in the first place. `SpkTxOutIndex` is intentionally *monotone* -- you cannot delete or
-/// modify txouts that have been indexed. To find out which txouts from the index are actually in the
-/// chain or unspent, you must use other sources of information like a [`TxGraph`].
+/// modify txouts that have been indexed. To find out which txouts from the index are actually in
+/// the chain or unspent, you must use other sources of information like a [`TxGraph`].
 ///
 /// [`TxOut`]: bitcoin::TxOut
 /// [`insert_spk`]: Self::insert_spk
@@ -89,9 +90,10 @@ impl<I: Clone + Ord + core::fmt::Debug> SpkTxOutIndex<I> {
     ///
     /// Typically, this is used in two situations:
     ///
-    /// 1. After loading transaction data from the disk, you may scan over all the txouts to restore all
-    ///    your txouts.
-    /// 2. When getting new data from the chain, you usually scan it before incorporating it into your chain state.
+    /// 1. After loading transaction data from the disk, you may scan over all the txouts to restore
+    ///    all your txouts.
+    /// 2. When getting new data from the chain, you usually scan it before incorporating it into
+    ///    your chain state.
     pub fn scan(&mut self, tx: &Transaction) -> BTreeSet<I> {
         let mut scanned_indices = BTreeSet::new();
         let txid = tx.compute_txid();
@@ -191,7 +193,8 @@ impl<I: Clone + Ord + core::fmt::Debug> SpkTxOutIndex<I> {
         &self.spks
     }
 
-    /// Adds a script pubkey to scan for. Returns `false` and does nothing if spk already exists in the map
+    /// Adds a script pubkey to scan for. Returns `false` and does nothing if spk already exists in
+    /// the map
     ///
     /// the index will look for outputs spending to this spk whenever it scans new data.
     pub fn insert_spk(&mut self, index: I, spk: ScriptBuf) -> bool {
@@ -243,14 +246,14 @@ impl<I: Clone + Ord + core::fmt::Debug> SpkTxOutIndex<I> {
         !self.unused.contains(index)
     }
 
-    /// Marks the script pubkey at `index` as used even though it hasn't seen an output spending to it.
-    /// This only affects when the `index` had already been added to `self` and was unused.
+    /// Marks the script pubkey at `index` as used even though it hasn't seen an output spending to
+    /// it. This only affects when the `index` had already been added to `self` and was unused.
     ///
     /// Returns whether the `index` was initially present as `unused`.
     ///
     /// This is useful when you want to reserve a script pubkey for something but don't want to add
-    /// the transaction output using it to the index yet. Other callers will consider the `index` used
-    /// until you call [`unmark_used`].
+    /// the transaction output using it to the index yet. Other callers will consider the `index`
+    /// used until you call [`unmark_used`].
     ///
     /// [`unmark_used`]: Self::unmark_used
     pub fn mark_used(&mut self, index: &I) -> bool {
@@ -326,8 +329,8 @@ impl<I: Clone + Ord + core::fmt::Debug> SpkTxOutIndex<I> {
     /// matches one of our script pubkeys.
     ///
     /// It is easily possible to misuse this method and get false negatives by calling it before you
-    /// have scanned the `TxOut`s the transaction is spending. For example, if you want to filter out
-    /// all the transactions in a block that are irrelevant, you **must first scan all the
+    /// have scanned the `TxOut`s the transaction is spending. For example, if you want to filter
+    /// out all the transactions in a block that are irrelevant, you **must first scan all the
     /// transactions in the block** and only then use this method.
     pub fn is_relevant(&self, tx: &Transaction) -> bool {
         let input_matches = tx

crates/chain/src/lib.rs

@@ -9,11 +9,11 @@
 //! Our design goals for these mechanisms are:
 //!
 //! 1. Data source agnostic -- nothing in `bdk_chain` cares about where you get data from or whether
-//!    you do it synchronously or asynchronously. If you know a fact about the blockchain, you can just
-//!    tell `bdk_chain`'s APIs about it, and that information will be integrated, if it can be done
-//!    consistently.
-//! 2. Data persistence agnostic -- `bdk_chain` does not care where you cache on-chain data, what you
-//!    cache or how you retrieve it from persistent storage.
+//!    you do it synchronously or asynchronously. If you know a fact about the blockchain, you can
+//!    just tell `bdk_chain`'s APIs about it, and that information will be integrated, if it can be
+//!    done consistently.
+//! 2. Data persistence agnostic -- `bdk_chain` does not care where you cache on-chain data, what
+//!    you cache or how you retrieve it from persistent storage.
 //!
 //! [Bitcoin Dev Kit]: https://bitcoindevkit.org/
 

crates/chain/src/local_chain.rs

@@ -178,7 +178,8 @@ impl LocalChain {
         Ok(changeset)
     }
 
-    /// Update the chain with a given [`Header`] at `height` which you claim is connected to a existing block in the chain.
+    /// Update the chain with a given [`Header`] at `height` which you claim is connected to a
+    /// existing block in the chain.
     ///
     /// This is useful when you have a block header that you want to record as part of the chain but
     /// don't necessarily know that the `prev_blockhash` is in the chain.
@@ -410,8 +411,8 @@ impl LocalChain {
 pub struct ChangeSet {
     /// Changes to the [`LocalChain`] blocks.
     ///
-    /// The key represents the block height, and the value either represents added a new [`CheckPoint`]
-    /// (if [`Some`]), or removing a [`CheckPoint`] (if [`None`]).
+    /// The key represents the block height, and the value either represents added a new
+    /// [`CheckPoint`] (if [`Some`]), or removing a [`CheckPoint`] (if [`None`]).
     pub blocks: BTreeMap<u32, Option<BlockHash>>,
 }
 
@@ -584,9 +585,9 @@ fn merge_chains(
     let mut is_update_height_superset_of_original = true;
 
     // To find the difference between the new chain and the original we iterate over both of them
-    // from the tip backwards in tandem. We are always dealing with the highest one from either chain
-    // first and move to the next highest. The crucial logic is applied when they have blocks at the
-    // same height.
+    // from the tip backwards in tandem. We are always dealing with the highest one from either
+    // chain first and move to the next highest. The crucial logic is applied when they have
+    // blocks at the same height.
     loop {
         if curr_orig.is_none() {
             curr_orig = orig.next();
@@ -620,9 +621,10 @@ fn merge_chains(
                 if o.hash() == u.hash() {
                     // We have found our point of agreement 🎉 -- we require that the previous (i.e.
                     // higher because we are iterating backwards) block in the original chain was
-                    // invalidated (if it exists). This ensures that there is an unambiguous point of
-                    // connection to the original chain from the update chain (i.e. we know the
-                    // precisely which original blocks are invalid).
+                    // invalidated (if it exists). This ensures that there is an unambiguous point
+                    // of connection to the original chain from the update chain
+                    // (i.e. we know the precisely which original blocks are
+                    // invalid).
                     if !prev_orig_was_invalidated && !point_of_agreement_found {
                         if let (Some(prev_orig), Some(_prev_update)) = (&prev_orig, &prev_update) {
                             return Err(CannotConnectError {

crates/chain/src/spk_iter.rs

@@ -11,8 +11,8 @@ pub const BIP32_MAX_INDEX: u32 = (1 << 31) - 1;
 /// An iterator for derived script pubkeys.
 ///
 /// [`SpkIterator`] is an implementation of the [`Iterator`] trait which possesses its own `next()`
-/// and `nth()` functions, both of which circumvent the unnecessary intermediate derivations required
-/// when using their default implementations.
+/// and `nth()` functions, both of which circumvent the unnecessary intermediate derivations
+/// required when using their default implementations.
 ///
 /// ## Examples
 ///
@@ -101,8 +101,8 @@ where
     type Item = Indexed<ScriptBuf>;
 
     fn next(&mut self) -> Option<Self::Item> {
-        // For non-wildcard descriptors, we expect the first element to be Some((0, spk)), then None after.
-        // For wildcard descriptors, we expect it to keep iterating until exhausted.
+        // For non-wildcard descriptors, we expect the first element to be Some((0, spk)), then None
+        // after. For wildcard descriptors, we expect it to keep iterating until exhausted.
         if self.next_index >= self.end {
             return None;
         }