Fixes for 1.80 clippy.

Author: Dirbaio

embedded-hal-nb/src/spi.rs

@@ -13,13 +13,13 @@ pub use embedded_hal::spi::{
 /// - Due to how full duplex SPI works each `read` call must be preceded by a `write` call.
 ///
 /// - `read` calls only return the data received with the last `write` call.
-/// Previously received data is discarded
+///   Previously received data is discarded
 ///
 /// - Data is only guaranteed to be clocked out when the `read` call succeeds.
-/// The slave select line shouldn't be released before that.
+///   The slave select line shouldn't be released before that.
 ///
 /// - Some SPIs can work with 8-bit *and* 16-bit words. You can overload this trait with different
-/// `Word` types to allow operation in both modes.
+///   `Word` types to allow operation in both modes.
 pub trait FullDuplex<Word: Copy = u8>: ErrorType {
     /// Reads the word stored in the shift register
     ///

embedded-hal/README.md

@@ -37,37 +37,37 @@ or a console to operate either on hardware serial ports or on virtual ones like
 The HAL
 
 - Must *erase* device specific details. Neither register, register blocks, nor magic values should
-appear in the API.
+  appear in the API.
 
 - Must be generic *within* a device and *across* devices. The API to use a serial interface must
-be the same regardless of whether the implementation uses the USART1 or UART4 peripheral of a
-device or the UART0 peripheral of another device.
+  be the same regardless of whether the implementation uses the USART1 or UART4 peripheral of a
+  device or the UART0 peripheral of another device.
 
 - Where possible must *not* be tied to a specific asynchronous model. The API should be usable
-in blocking mode, with the `futures` model, with an async/await model or with a callback model.
-(cf. the [`nb`](https://docs.rs/nb) crate)
+  in blocking mode, with the `futures` model, with an async/await model or with a callback model.
+  (cf. the [`nb`](https://docs.rs/nb) crate)
 
 - Must be minimal, and thus easy to implement and zero cost, yet highly composable. People that
-want higher level abstraction should *prefer to use this HAL* rather than *re-implement*
-register manipulation code.
+  want higher level abstraction should *prefer to use this HAL* rather than *re-implement*
+  register manipulation code.
 
 - Serve as a foundation for building an ecosystem of platform-agnostic drivers. Here driver
-means a library crate that lets a target platform interface an external device like a digital
-sensor or a wireless transceiver. The advantage of this system is that by writing the driver as
-a generic library on top of `embedded-hal` driver authors can support any number of target
-platforms (e.g. Cortex-M microcontrollers, AVR microcontrollers, embedded Linux, etc.). The
-advantage for application developers is that by adopting `embedded-hal` they can unlock all
-these drivers for their platform.
+  means a library crate that lets a target platform interface an external device like a digital
+  sensor or a wireless transceiver. The advantage of this system is that by writing the driver as
+  a generic library on top of `embedded-hal` driver authors can support any number of target
+  platforms (e.g. Cortex-M microcontrollers, AVR microcontrollers, embedded Linux, etc.). The
+  advantage for application developers is that by adopting `embedded-hal` they can unlock all
+  these drivers for their platform.
 
 - Trait methods must be fallible so that they can be used in any possible situation.
-Nevertheless, HAL implementations can additionally provide infallible versions of the same methods
-if they can never fail in their platform. This way, generic code can use the fallible abstractions
-provided here but platform-specific code can avoid fallibility-related boilerplate if possible.
+  Nevertheless, HAL implementations can additionally provide infallible versions of the same methods
+  if they can never fail in their platform. This way, generic code can use the fallible abstractions
+  provided here but platform-specific code can avoid fallibility-related boilerplate if possible.
 
 ## Out of scope
 
 - Initialization and configuration stuff like "ensure this serial interface and that SPI
-interface are not using the same pins". The HAL will focus on *doing I/O*.
+  interface are not using the same pins". The HAL will focus on *doing I/O*.
 
 ## Platform agnostic drivers
 

embedded-io-adapters/src/futures_03.rs

@@ -1,5 +1,10 @@
 //! Adapters to/from `futures::io` traits.
 
+// MSRV is 1.60 if you don't enable async, 1.80 if you do.
+// Cargo.toml has 1.60, which makes Clippy complain that `poll_fn` was introduced
+// in 1.64. So, just silence it for this file.
+#![allow(clippy::incompatible_msrv)]
+
 use core::future::poll_fn;
 use core::pin::Pin;
 

embedded-io-adapters/src/tokio_1.rs

@@ -1,5 +1,10 @@
 //! Adapters to/from `tokio::io` traits.
 
+// MSRV is 1.60 if you don't enable async, 1.80 if you do.
+// Cargo.toml has 1.60, which makes Clippy complain that `poll_fn` was introduced
+// in 1.64. So, just silence it for this file.
+#![allow(clippy::incompatible_msrv)]
+
 use core::future::poll_fn;
 use core::pin::Pin;
 use core::task::Poll;

embedded-io/README.md

@@ -15,9 +15,9 @@ targets.
 ## Differences with `std::io`
 
 - `Error` is an associated type. This allows each implementor to return its own error type,
-while avoiding `dyn` or `Box`. This is consistent with how errors are handled in [`embedded-hal`](https://github.com/rust-embedded/embedded-hal/).
+  while avoiding `dyn` or `Box`. This is consistent with how errors are handled in [`embedded-hal`](https://github.com/rust-embedded/embedded-hal/).
 - In `std::io`, the `Read`/`Write` traits might be blocking or non-blocking (i.e. returning `WouldBlock` errors) depending on the file descriptor's mode, which is only known at run-time. This allows passing a non-blocking stream to code that expects a blocking
-stream, causing unexpected errors. To solve this, `embedded-io` specifies `Read`/`Write` are always blocking, and adds new `ReadReady`/`WriteReady` traits to allow using streams in a non-blocking way.
+  stream, causing unexpected errors. To solve this, `embedded-io` specifies `Read`/`Write` are always blocking, and adds new `ReadReady`/`WriteReady` traits to allow using streams in a non-blocking way.
 
 ## Optional Cargo features