chore: fix clippy warnings

iroh-base/src/ticket.rs

@@ -36,7 +36,7 @@ pub trait Ticket: Sized {
     /// Serialize to string.
     fn serialize(&self) -> String {
         let mut out = Self::KIND.to_string();
-        base32::fmt_append(&self.to_bytes(), &mut out);
+        base32::fmt_append(self.to_bytes(), &mut out);
         out
     }
 

iroh-blobs/src/get/db.rs

@@ -346,7 +346,7 @@ async fn get_hash_seq<
                             child: BlobId::from_offset((i as u64) + 1),
                             hash: children[i],
                             size,
-                            valid_ranges: RangeSpec::new(&info.valid_ranges()),
+                            valid_ranges: RangeSpec::new(info.valid_ranges()),
                         })
                         .await?;
                 }

iroh-blobs/src/protocol.rs

@@ -12,31 +12,29 @@
 //!
 //! - Be paranoid about data integrity.
 //!
-//!   Data integrity is considered more important than performance. Data will be
-//! validated both on the provider and getter side. A well behaved provider will
-//! never send invalid data. Responses to range requests contain sufficient
-//! information to validate the data.
+//!   Data integrity is considered more important than performance. Data will be validated both on
+//!   the provider and getter side. A well behaved provider will never send invalid data. Responses
+//!   to range requests contain sufficient information to validate the data.
 //!
-//!   Note: Validation using blake3 is extremely fast, so in almost all scenarios the
-//! validation will not be the bottleneck even if we validate both on the provider
-//! and getter side.
+//!   Note: Validation using blake3 is extremely fast, so in almost all scenarios the validation
+//!   will not be the bottleneck even if we validate both on the provider and getter side.
 //!
 //! - Do not limit the size of blobs or collections.
 //!
-//!   Blobs can be of arbitrary size, up to terabytes. Likewise, collections
-//! can contain an arbitrary number of links. A well behaved implementation will
-//! not require the entire blob or collection to be in memory at once.
+//!   Blobs can be of arbitrary size, up to terabytes. Likewise, collections can contain an
+//!   arbitrary number of links. A well behaved implementation will not require the entire blob or
+//!   collection to be in memory at once.
 //!
 //! - Be efficient when transferring large blobs, including range requests.
 //!
-//!   It is possible to request entire blobs or ranges of blobs, where the
-//! minimum granularity is a chunk group of 16KiB or 16 blake3 chunks. The worst
-//! case overhead when doing range requests is about two chunk groups per range.
+//!   It is possible to request entire blobs or ranges of blobs, where the minimum granularity is a
+//!   chunk group of 16KiB or 16 blake3 chunks. The worst case overhead when doing range requests
+//!   is about two chunk groups per range.
 //!
 //! - Be efficient when transferring multiple tiny blobs.
 //!
-//!   For tiny blobs the overhead of sending the blob hashes and the round-trip time
-//! for each blob would be prohibitive.
+//!   For tiny blobs the overhead of sending the blob hashes and the round-trip time for each blob
+//!   would be prohibitive.
 //!
 //! To avoid roundtrips, the protocol allows grouping multiple blobs into *collections*.
 //! The semantic meaning of a collection is up to the application. For the purpose
@@ -46,21 +44,21 @@
 //!
 //! - Do not attempt to be generic in terms of the used hash function.
 //!
-//!   The protocol makes extensive use of the [blake3](https://crates.io/crates/blake3)
-//! hash function and it's special properties such as blake3 verified streaming.
+//!   The protocol makes extensive use of the [blake3](https://crates.io/crates/blake3) hash
+//!   function and it's special properties such as blake3 verified streaming.
 //!
 //! - Do not support graph traversal.
 //!
-//!   The protocol only supports collections that directly contain blobs. If you have
-//! deeply nested graph data, you will need to either do multiple requests or flatten
-//! the graph into a single temporary collection.
+//!   The protocol only supports collections that directly contain blobs. If you have deeply nested
+//!   graph data, you will need to either do multiple requests or flatten the graph into a single
+//!   temporary collection.
 //!
 //! - Do not support discovery.
 //!
-//!   The protocol does not yet have a discovery mechanism for asking the provider
-//! what ranges are available for a given blob. Currently you have to have some
-//! out-of-band knowledge about what node has data for a given hash, or you can
-//! just try to retrieve the data and see if it is available.
+//!   The protocol does not yet have a discovery mechanism for asking the provider what ranges are
+//!   available for a given blob. Currently you have to have some out-of-band knowledge about what
+//!   node has data for a given hash, or you can just try to retrieve the data and see if it is
+//!   available.
 //!
 //! A discovery protocol is planned in the future though.
 //!
@@ -314,10 +312,10 @@
 //! Reasons for not retrieving a complete response are two-fold:
 //!
 //! - the connection to the provider was interrupted, or the provider encountered
-//! an internal error. In this case the provider will close the entire quinn connection.
+//!   an internal error. In this case the provider will close the entire quinn connection.
 //!
 //! - the provider does not have the requested data, or discovered on send that the
-//! requested data is not valid.
+//!   requested data is not valid.
 //!
 //! In this case the provider will close just the stream used to send the response.
 //! The exact location of the missing data can be retrieved from the error.

iroh-blobs/src/store/fs.rs

@@ -36,12 +36,11 @@
 //!
 //! Data can get out of the store in two ways:
 //!
-//! 1. the data and outboard of both partial and complete entries can be read
-//! at any time and shared over the network. Only data that is complete will
-//! be shared, everything else will lead to validation errors.
+//! 1. the data and outboard of both partial and complete entries can be read at any time and
+//!    shared over the network. Only data that is complete will be shared, everything else will
+//!    lead to validation errors.
 //!
-//! 2. entries can be exported to the file system. This currently only works
-//! for complete entries.
+//! 2. entries can be exported to the file system. This currently only works for complete entries.
 //!
 //! Tables:
 //!

iroh-docs/src/lib.rs

@@ -18,8 +18,8 @@
 //! Aljoscha Meyer:
 //!
 //! > Range-based set reconciliation is a simple approach to efficiently compute the union of two
-//! sets over a network, based on recursively partitioning the sets and comparing fingerprints of
-//! the partitions to probabilistically detect whether a partition requires further work.
+//! > sets over a network, based on recursively partitioning the sets and comparing fingerprints of
+//! > the partitions to probabilistically detect whether a partition requires further work.
 //!
 //! The crate exposes a [generic storage interface](store::Store). There is an implementation
 //! of this interface, [store::fs::Store], that can be used either

iroh-docs/src/ranger.rs

@@ -56,9 +56,11 @@ pub trait RangeValue: Sized + Debug + Ord + PartialEq + Clone + 'static {}
 /// Stores a range.
 ///
 /// There are three possibilities
+///
 /// - x, x: All elements in a set, denoted with
 /// - [x, y): x < y: Includes x, but not y
 /// - S \ [y, x) y < x: Includes x, but not y.
+///
 /// This means that ranges are "wrap around" conceptually.
 #[derive(Debug, Clone, Copy, PartialEq, Serialize, Deserialize, Default)]
 pub struct Range<K> {

iroh-gossip/src/proto/hyparview.rs

@@ -469,10 +469,10 @@ where
     /// Handle a [`Message::Shuffle`]
     ///
     /// > A node q that receives a Shuffle request will first decrease its time to live. If the time
-    /// to live of the message is greater than zero and the number of nodes in q’s active view is
-    /// greater than 1, the node will select a random node from its active view, different from the
-    /// one he received this shuffle message from, and simply forwards the Shuffle request.
-    /// Otherwise, node q accepts the Shuffle request and send back (p.8)
+    /// > to live of the message is greater than zero and the number of nodes in q’s active view is
+    /// > greater than 1, the node will select a random node from its active view, different from the
+    /// > one he received this shuffle message from, and simply forwards the Shuffle request.
+    /// > Otherwise, node q accepts the Shuffle request and send back (p.8)
     fn on_shuffle(&mut self, from: PI, shuffle: Shuffle<PI>, io: &mut impl IO<PI>) {
         if shuffle.ttl.expired() || self.active_view.len() <= 1 {
             let len = shuffle.nodes.len();

iroh-gossip/src/proto/plumtree.rs

@@ -234,16 +234,16 @@ pub struct Config {
     ///
     /// The plumtree paper notes:
     /// > The timeout value is a protocol parameter that should be configured considering the
-    /// diameter of the overlay and a target maximum recovery latency, defined by the application
-    /// requirements. (p.8)
+    /// > diameter of the overlay and a target maximum recovery latency, defined by the application
+    /// > requirements. (p.8)
     pub graft_timeout_1: Duration,
     /// This timeout is registered when sending a [`Graft`] message. If a reply has not been
     /// received once the timeout expires, we send another [`Graft`] message to the next peer that
     /// sent us an [`IHave`] for this message.
     ///
     /// The plumtree paper notes:
     /// > This second timeout value should be smaller that the first, in the order of an average
-    /// round trip time to a neighbor.
+    /// > round trip time to a neighbor.
     pub graft_timeout_2: Duration,
     /// Timeout after which [`IHave`] messages are pushed to peers.
     pub dispatch_timeout: Duration,
@@ -561,11 +561,11 @@ impl<PI: PeerIdentity> State<PI> {
     /// Handle receiving a [`Message::IHave`].
     ///
     /// > When a node receives a IHAVE message, it simply marks the corresponding message as
-    /// missing It then starts a timer, with a predefined timeout value, and waits for the missing
-    /// message to be received via eager push before the timer expires. The timeout value is a
-    /// protocol parameter that should be configured considering the diameter of the overlay and a
-    /// target maximum recovery latency, defined by the application requirements. This is a
-    /// parameter that should be statically configured at deployment time. (p8)
+    /// > missing It then starts a timer, with a predefined timeout value, and waits for the missing
+    /// > message to be received via eager push before the timer expires. The timeout value is a
+    /// > protocol parameter that should be configured considering the diameter of the overlay and a
+    /// > target maximum recovery latency, defined by the application requirements. This is a
+    /// > parameter that should be statically configured at deployment time. (p8)
     fn on_ihave(&mut self, sender: PI, ihaves: Vec<IHave>, io: &mut impl IO<PI>) {
         for ihave in ihaves {
             if !self.received_messages.contains_key(&ihave.id) {
@@ -636,8 +636,8 @@ impl<PI: PeerIdentity> State<PI> {
 
     /// Handle a [`InEvent::NeighborDown`] when a peer leaves the topic.
     /// > When a neighbor is detected to leave the overlay, it is simple removed from the
-    /// membership. Furthermore, the record of IHAVE messages sent from failed members is deleted
-    /// from the missing history. (p9)
+    /// > membership. Furthermore, the record of IHAVE messages sent from failed members is deleted
+    /// > from the missing history. (p9)
     fn on_neighbor_down(&mut self, peer: PI) {
         self.missing_messages.retain(|_message_id, ihaves| {
             ihaves.retain(|(ihave_peer, _round)| *ihave_peer != peer);

iroh-net/src/endpoint.rs

@@ -841,7 +841,7 @@ impl Endpoint {
     /// This will launch discovery in all cases except if:
     /// 1) we do not have discovery enabled
     /// 2) we have discovery enabled, but already have at least one verified, unexpired
-    /// addresses for this `node_id`
+    ///    addresses for this `node_id`
     ///
     /// # Errors
     ///

iroh-net/src/relay/client_conn.rs

@@ -55,7 +55,7 @@ pub(crate) struct ClientConnManager {
 /// Channels that the [`ClientConnManager`] uses to communicate with the
 /// [`ClientConnIo`] to forward the client:
 ///  - information about a peer leaving the network (This should only happen for peers that this
-///  client was previously communciating with)
+///    client was previously communciating with)
 ///  - packets sent to this client from another client in the network
 #[derive(Debug)]
 pub(crate) struct ClientChannels {
@@ -192,7 +192,7 @@ impl ClientConnManager {
 /// On the "write" side, the [`ClientConnIo`] can send the client:
 ///  - a KEEP_ALIVE frame
 ///  - a PEER_GONE frame to inform the client that a peer they have previously sent messages to
-///  is gone from the network
+///    is gone from the network
 ///  - packets from other peers
 ///
 /// On the "read" side, it can:

iroh-net/src/relay/codec.rs

@@ -30,7 +30,8 @@ pub(super) const PER_CLIENT_READ_QUEUE_DEPTH: usize = 512;
 
 /// ProtocolVersion is bumped whenever there's a wire-incompatible change.
 ///  - version 1 (zero on wire): consistent box headers, in use by employee dev nodes a bit
-///  - version 2: received packets have src addrs in FrameType::RecvPacket at beginning
+///  - version 2: received packets have src addrs in FrameType::RecvPacket at beginning.
+///
 /// NOTE: we are technically running a modified version of the protocol.
 /// `FrameType::PeerPresent`, `FrameType::WatchConn`, `FrameType::ClosePeer`, have been removed.
 /// The server will error on that connection if a client sends one of these frames.