chore: address clippy beta lints

Pull-Request: #5467.

Cargo.toml

@@ -144,7 +144,7 @@ libp2p-identity = { path = "identity" }
 [workspace.lints]
 rust.unreachable_pub = "warn"
 clippy.used_underscore_binding = "warn"
-clippy.pedantic = "allow"
+clippy.pedantic = { level = "allow", priority = -1 }
 clippy.type_complexity = "allow"
 clippy.unnecessary_wraps = "warn"
 clippy.manual_let_else = "warn"

core/src/upgrade.rs

@@ -52,9 +52,9 @@
 //! can be used by the user to control the behaviour of the protocol.
 //!
 //! > **Note**: You can use the `apply_inbound` or `apply_outbound` methods to try upgrade a
-//!             connection or substream. However if you use the recommended `Swarm` or
-//!             `ConnectionHandler` APIs, the upgrade is automatically handled for you and you don't
-//!             need to use these methods.
+//! > connection or substream. However if you use the recommended `Swarm` or
+//! > `ConnectionHandler` APIs, the upgrade is automatically handled for you and you don't
+//! > need to use these methods.
 //!
 
 mod apply;

examples/chat/README.md

@@ -11,7 +11,7 @@ It showcases how peers can connect, discover each other using mDNS, and engage i
 	```
 
 2. Mutual mDNS discovery may take a few seconds. When each peer does discover the other
-it will print a message like:
+   it will print a message like:
 	```sh
 	mDNS discovered a new peer: {peerId}
 	```

examples/distributed-key-value-store/README.md

@@ -9,10 +9,10 @@ This example showcases a basic distributed key-value store implemented using **l
 1.  Open two terminal windows, type `cargo run` and press Enter.
 
 2.  In terminal one, type `PUT my-key my-value` and press Enter.
-This command will store the value `my-value` with the key `my-key` in the distributed key-value store.
+    This command will store the value `my-value` with the key `my-key` in the distributed key-value store.
 
 3.  In terminal two, type `GET my-key` and press Enter.
-This command will retrieve the value associated with the key `my-key` from the key-value store.
+    This command will retrieve the value associated with the key `my-key` from the key-value store.
 
 4.  To exit, press `Ctrl-c` in each terminal window to gracefully close the instances.
 
@@ -22,13 +22,13 @@ This command will retrieve the value associated with the key `my-key` from the k
 You can also use provider records instead of key-value records in the distributed store.
 
 1.  Open two terminal windows and start two instances of the key-value store.
-If your local network supports mDNS, the instances will automatically connect.
+    If your local network supports mDNS, the instances will automatically connect.
 
 2.  In terminal one, type `PUT_PROVIDER my-key` and press Enter.
-This command will register the peer as a provider for the key `my-key` in the distributed key-value store.
+    This command will register the peer as a provider for the key `my-key` in the distributed key-value store.
 
 3.  In terminal two, type `GET_PROVIDERS my-key` and press Enter.
-This command will retrieve the list of providers for the key `my-key` from the key-value store.
+    This command will retrieve the list of providers for the key `my-key` from the key-value store.
 
 4.  To exit, press `Ctrl-c` in each terminal window to gracefully close the instances.
 

examples/file-sharing/README.md

@@ -12,28 +12,28 @@ Retrievers can locate and retrieve files by their names from any node in the net
 Let's understand the flow of the file sharing process:
 
 - **File Providers**: Nodes A and B serve as file providers.
-Each node offers a specific file: file FA for node A and file FB for node B.
-To make their files available, they advertise themselves as providers on the DHT using `libp2p-kad`.
-This enables other nodes in the network to discover and retrieve their files.
+  Each node offers a specific file: file FA for node A and file FB for node B.
+  To make their files available, they advertise themselves as providers on the DHT using `libp2p-kad`.
+  This enables other nodes in the network to discover and retrieve their files.
 
 - **File Retrievers**: Node C acts as a file retriever.
-It wants to retrieve either file FA or FB.
-Using `libp2p-kad`, it can locate the providers for these files on the DHT without being directly connected to them.
-Node C connects to the corresponding provider node and requests the file content using `libp2p-request-response`.
+  It wants to retrieve either file FA or FB.
+  Using `libp2p-kad`, it can locate the providers for these files on the DHT without being directly connected to them.
+  Node C connects to the corresponding provider node and requests the file content using `libp2p-request-response`.
 
 - **DHT and Network Connectivity**: The DHT (Distributed Hash Table) plays a crucial role in the file sharing process.
-It allows nodes to store and discover information about file providers.
-Nodes in the network are interconnected via the DHT, enabling efficient file discovery and retrieval.
+  It allows nodes to store and discover information about file providers.
+  Nodes in the network are interconnected via the DHT, enabling efficient file discovery and retrieval.
 
 ## Architectural Properties
 
 The File Sharing application has the following architectural properties:
 
 - **Clean and Clonable Interface**: The application provides a clean and clonable async/await interface, allowing users to interact with the network layer seamlessly.
-The `Client` module encapsulates the necessary functionality for network communication.
+  The `Client` module encapsulates the necessary functionality for network communication.
 
 - **Efficient Network Handling**: The application operates with a single task that drives the network layer.
-This design choice ensures efficient network communication without the need for locks or complex synchronization mechanisms.
+  This design choice ensures efficient network communication without the need for locks or complex synchronization mechanisms.
 
 ## Usage
 

examples/ipfs-private/README.md

@@ -24,11 +24,11 @@ To run the example, follow these steps:
 2.  Once the example is running, you can interact with the IPFS node using the following commands:
 
     -   **Pubsub (Gossipsub):** You can use the gossipsub protocol to send and receive messages on the "chat" topic.
-    To send a message, type it in the console and press Enter.
-    The message will be broadcasted to other connected nodes using gossipsub.
+        To send a message, type it in the console and press Enter.
+        The message will be broadcasted to other connected nodes using gossipsub.
 
     -   **Ping:** You can ping other connected nodes to test network connectivity.
-    The example will display the round-trip time (RTT) for successful pings or indicate if a timeout occurs.
+        The example will display the round-trip time (RTT) for successful pings or indicate if a timeout occurs.
 
 
 ## Conclusion

examples/relay-server/README.md

@@ -16,7 +16,7 @@ To run the example, follow these steps:
    Replace `<seed>` with a seed value used to generate a deterministic peer ID for the relay node.
 
 2. The relay node will start listening for incoming connections.
-It will print the listening address once it is ready.
+   It will print the listening address once it is ready.
 
 3. Connect other **libp2p** nodes to the relay node by specifying the relay's listening address as one of the bootstrap nodes in their configuration.
 

libp2p/src/builder.rs

@@ -575,16 +575,14 @@ mod tests {
 
     #[test]
     #[cfg(all(feature = "tokio", feature = "quic"))]
-    fn quic_bandwidth_metrics() -> Result<(), Box<dyn std::error::Error>> {
+    fn quic_bandwidth_metrics() {
         let _ = SwarmBuilder::with_new_identity()
             .with_tokio()
             .with_quic()
             .with_bandwidth_metrics(&mut libp2p_metrics::Registry::default())
             .with_behaviour(|_| libp2p_swarm::dummy::Behaviour)
             .unwrap()
             .build();
-
-        Ok(())
     }
 
     #[test]

misc/multistream-select/src/protocol.rs

@@ -136,24 +136,21 @@ pub(crate) enum Message {
 
 impl Message {
     /// Encodes a `Message` into its byte representation.
-    fn encode(&self, dest: &mut BytesMut) -> Result<(), ProtocolError> {
+    fn encode(&self, dest: &mut BytesMut) {
         match self {
             Message::Header(HeaderLine::V1) => {
                 dest.reserve(MSG_MULTISTREAM_1_0.len());
                 dest.put(MSG_MULTISTREAM_1_0);
-                Ok(())
             }
             Message::Protocol(p) => {
                 let len = p.as_ref().len() + 1; // + 1 for \n
                 dest.reserve(len);
                 dest.put(p.0.as_ref());
                 dest.put_u8(b'\n');
-                Ok(())
             }
             Message::ListProtocols => {
                 dest.reserve(MSG_LS.len());
                 dest.put(MSG_LS);
-                Ok(())
             }
             Message::Protocols(ps) => {
                 let mut buf = uvi::encode::usize_buffer();
@@ -166,12 +163,10 @@ impl Message {
                 encoded.push(b'\n');
                 dest.reserve(encoded.len());
                 dest.put(encoded.as_ref());
-                Ok(())
             }
             Message::NotAvailable => {
                 dest.reserve(MSG_PROTOCOL_NA.len());
                 dest.put(MSG_PROTOCOL_NA);
-                Ok(())
             }
         }
     }
@@ -288,7 +283,7 @@ where
 
     fn start_send(self: Pin<&mut Self>, item: Message) -> Result<(), Self::Error> {
         let mut buf = BytesMut::new();
-        item.encode(&mut buf)?;
+        item.encode(&mut buf);
         self.project()
             .inner
             .start_send(buf.freeze())
@@ -499,8 +494,7 @@ mod tests {
     fn encode_decode_message() {
         fn prop(msg: Message) {
             let mut buf = BytesMut::new();
-            msg.encode(&mut buf)
-                .unwrap_or_else(|_| panic!("Encoding message failed: {msg:?}"));
+            msg.encode(&mut buf);
             match Message::decode(buf.freeze()) {
                 Ok(m) => assert_eq!(m, msg),
                 Err(e) => panic!("Decoding failed: {e:?}"),

protocols/gossipsub/src/behaviour.rs

@@ -549,6 +549,7 @@ where
     /// Unsubscribes from a topic.
     ///
     /// Returns [`Ok(true)`] if we were subscribed to this topic.
+    #[allow(clippy::unnecessary_wraps)]
     pub fn unsubscribe<H: Hasher>(&mut self, topic: &Topic<H>) -> Result<bool, PublishError> {
         tracing::debug!(%topic, "Unsubscribing from topic");
         let topic_hash = topic.hash();
@@ -2551,6 +2552,7 @@ where
     /// Helper function which forwards a message to mesh\[topic\] peers.
     ///
     /// Returns true if at least one peer was messaged.
+    #[allow(clippy::unnecessary_wraps)]
     fn forward_msg(
         &mut self,
         msg_id: &MessageId,

protocols/gossipsub/src/lib.rs

@@ -43,16 +43,16 @@
 //! implementations, due to undefined elements in the current specification.
 //!
 //! - **Topics** -  In gossipsub, topics configurable by the `hash_topics` configuration parameter.
-//! Topics are of type [`TopicHash`]. The current go implementation uses raw utf-8 strings, and this
-//! is default configuration in rust-libp2p. Topics can be hashed (SHA256 hashed then base64
-//! encoded) by setting the `hash_topics` configuration parameter to true.
+//!   Topics are of type [`TopicHash`]. The current go implementation uses raw utf-8 strings, and this
+//!   is default configuration in rust-libp2p. Topics can be hashed (SHA256 hashed then base64
+//!   encoded) by setting the `hash_topics` configuration parameter to true.
 //!
 //! - **Sequence Numbers** - A message on the gossipsub network is identified by the source
-//! [`PeerId`](libp2p_identity::PeerId) and a nonce (sequence number) of the message. The sequence numbers in
-//! this implementation are sent as raw bytes across the wire. They are 64-bit big-endian unsigned
-//! integers. When messages are signed, they are monotonically increasing integers starting from a
-//! random value and wrapping around u64::MAX. When messages are unsigned, they are chosen at random.
-//! NOTE: These numbers are sequential in the current go implementation.
+//!   [`PeerId`](libp2p_identity::PeerId) and a nonce (sequence number) of the message. The sequence numbers in
+//!   this implementation are sent as raw bytes across the wire. They are 64-bit big-endian unsigned
+//!   integers. When messages are signed, they are monotonically increasing integers starting from a
+//!   random value and wrapping around u64::MAX. When messages are unsigned, they are chosen at random.
+//!   NOTE: These numbers are sequential in the current go implementation.
 //!
 //! # Peer Discovery
 //!

protocols/gossipsub/src/protocol.rs

@@ -541,20 +541,6 @@ mod tests {
     struct TestKeypair(Keypair);
 
     impl Arbitrary for TestKeypair {
-        #[cfg(feature = "rsa")]
-        fn arbitrary(g: &mut Gen) -> Self {
-            let keypair = if bool::arbitrary(g) {
-                // Small enough to be inlined.
-                Keypair::generate_ed25519()
-            } else {
-                // Too large to be inlined.
-                let mut rsa_key = hex::decode("308204bd020100300d06092a864886f70d0101010500048204a7308204a30201000282010100ef930f41a71288b643c1cbecbf5f72ab53992249e2b00835bf07390b6745419f3848cbcc5b030faa127bc88cdcda1c1d6f3ff699f0524c15ab9d2c9d8015f5d4bd09881069aad4e9f91b8b0d2964d215cdbbae83ddd31a7622a8228acee07079f6e501aea95508fa26c6122816ef7b00ac526d422bd12aed347c37fff6c1c307f3ba57bb28a7f28609e0bdcc839da4eedca39f5d2fa855ba4b0f9c763e9764937db929a1839054642175312a3de2d3405c9d27bdf6505ef471ce85c5e015eee85bf7874b3d512f715de58d0794fd8afe021c197fbd385bb88a930342fac8da31c27166e2edab00fa55dc1c3814448ba38363077f4e8fe2bdea1c081f85f1aa6f02030100010282010028ff427a1aac1a470e7b4879601a6656193d3857ea79f33db74df61e14730e92bf9ffd78200efb0c40937c3356cbe049cd32e5f15be5c96d5febcaa9bd3484d7fded76a25062d282a3856a1b3b7d2c525cdd8434beae147628e21adf241dd64198d5819f310d033743915ba40ea0b6acdbd0533022ad6daa1ff42de51885f9e8bab2306c6ef1181902d1cd7709006eba1ab0587842b724e0519f295c24f6d848907f772ae9a0953fc931f4af16a07df450fb8bfa94572562437056613647818c238a6ff3f606cffa0533e4b8755da33418dfbc64a85110b1a036623c947400a536bb8df65e5ebe46f2dfd0cfc86e7aeeddd7574c253e8fbf755562b3669525d902818100f9fff30c6677b78dd31ec7a634361438457e80be7a7faf390903067ea8355faa78a1204a82b6e99cb7d9058d23c1ecf6cfe4a900137a00cecc0113fd68c5931602980267ea9a95d182d48ba0a6b4d5dd32fdac685cb2e5d8b42509b2eb59c9579ea6a67ccc7547427e2bd1fb1f23b0ccb4dd6ba7d206c8dd93253d70a451701302818100f5530dfef678d73ce6a401ae47043af10a2e3f224c71ae933035ecd68ccbc4df52d72bc6ca2b17e8faf3e548b483a2506c0369ab80df3b137b54d53fac98f95547c2bc245b416e650ce617e0d29db36066f1335a9ba02ad3e0edf9dc3d58fd835835042663edebce81803972696c789012847cb1f854ab2ac0a1bd3867ac7fb502818029c53010d456105f2bf52a9a8482bca2224a5eac74bf3cc1a4d5d291fafcdffd15a6a6448cce8efdd661f6617ca5fc37c8c885cc3374e109ac6049bcbf72b37eabf44602a2da2d4a1237fd145c863e6d75059976de762d9d258c42b0984e2a2befa01c95217c3ee9c736ff209c355466ff99375194eff943bc402ea1d172a1ed02818027175bf493bbbfb8719c12b47d967bf9eac061c90a5b5711172e9095c38bb8cc493c063abffe4bea110b0a2f22ac9311b3947ba31b7ef6bfecf8209eebd6d86c316a2366bbafda7279b2b47d5bb24b6202254f249205dcad347b574433f6593733b806f84316276c1990a016ce1bbdbe5f650325acc7791aefe515ecc60063bd02818100b6a2077f4adcf15a17092d9c4a346d6022ac48f3861b73cf714f84c440a07419a7ce75a73b9cbff4597c53c128bf81e87b272d70428a272d99f90cd9b9ea1033298e108f919c6477400145a102df3fb5601ffc4588203cf710002517bfa24e6ad32f4d09c6b1a995fa28a3104131bedd9072f3b4fb4a5c2056232643d310453f").unwrap();
-                Keypair::rsa_from_pkcs8(&mut rsa_key).unwrap()
-            };
-            TestKeypair(keypair)
-        }
-
-        #[cfg(not(feature = "rsa"))]
         fn arbitrary(_g: &mut Gen) -> Self {
             // Small enough to be inlined.
             TestKeypair(Keypair::generate_ed25519())

protocols/identify/src/lib.rs

@@ -29,9 +29,9 @@
 //! # Important Discrepancies
 //!
 //! - **Using Identify with other protocols** Unlike some other libp2p implementations,
-//! rust-libp2p does not treat Identify as a core protocol. This means that other protocols cannot
-//! rely upon the existence of Identify, and need to be manually hooked up to Identify in order to
-//! make use of its capabilities.
+//!   rust-libp2p does not treat Identify as a core protocol. This means that other protocols cannot
+//!   rely upon the existence of Identify, and need to be manually hooked up to Identify in order to
+//!   make use of its capabilities.
 //!
 //! # Usage
 //!

protocols/kad/src/behaviour.rs

@@ -925,11 +925,11 @@ where
     /// > See [`Behaviour::add_address`].
     ///
     /// > **Note**: Bootstrap does not require to be called manually. It is periodically
-    /// invoked at regular intervals based on the configured `periodic_bootstrap_interval` (see
-    /// [`Config::set_periodic_bootstrap_interval`] for details) and it is also automatically invoked
-    /// when a new peer is inserted in the routing table.
-    /// This parameter is used to call [`Behaviour::bootstrap`] periodically and automatically
-    /// to ensure a healthy routing table.
+    /// > invoked at regular intervals based on the configured `periodic_bootstrap_interval` (see
+    /// > [`Config::set_periodic_bootstrap_interval`] for details) and it is also automatically invoked
+    /// > when a new peer is inserted in the routing table.
+    /// > This parameter is used to call [`Behaviour::bootstrap`] periodically and automatically
+    /// > to ensure a healthy routing table.
     pub fn bootstrap(&mut self) -> Result<QueryId, NoKnownPeers> {
         let local_key = *self.kbuckets.local_key();
         let info = QueryInfo::Bootstrap {