Merge pull request #619 from Dirbaio/remove-nightly-checks

Remove nightly checks.

Author: MabezDev

.github/workflows/clippy.yml

@@ -11,10 +11,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: dtolnay/rust-toolchain@master
+      - uses: dtolnay/rust-toolchain@stable
         with:
-          # embedded-hal-async needs nightly.
-          # Use a pinned version to avoid spontaneous breakages (new clippy lints are added often)
-          toolchain: nightly-2023-10-14
           components: clippy
       - run: cargo clippy --all-features -- --deny=warnings

.github/workflows/rustdoc.yml

@@ -13,6 +13,6 @@ jobs:
       - uses: actions/checkout@v4
       - uses: dtolnay/rust-toolchain@master
         with:
-          toolchain: nightly-2023-10-14
+          toolchain: nightly-2024-07-26
       # tokio/net required to workaround https://github.com/tokio-rs/tokio/issues/6165
       - run: RUSTDOCFLAGS="--deny=warnings --cfg=docsrs" cargo doc --all-features --features tokio/net

.github/workflows/rustfmt.yml

@@ -12,8 +12,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
-      - uses: dtolnay/rust-toolchain@master
+      - uses: dtolnay/rust-toolchain@stable
         with:
-          toolchain: nightly
           components: rustfmt
       - run: cargo fmt --check

embedded-hal-async/build.rs

@@ -1,12 +1,6 @@
 #![doc = include_str!("../README.md")]
 #![warn(missing_docs)]
 #![no_std]
-// disable warning for already-stabilized features.
-// Needed to pass CI, because we deny warnings.
-// We don't immediately remove them to not immediately break older nightlies.
-// When all features are stable, we'll remove them.
-#![cfg_attr(nightly, allow(stable_features, unknown_lints))]
-#![cfg_attr(nightly, feature(async_fn_in_trait, impl_trait_projections))]
 #![allow(async_fn_in_trait)]
 
 pub mod delay;

embedded-hal-async/src/lib.rs

@@ -2,15 +2,6 @@
 #![warn(missing_docs)]
 #![cfg_attr(not(feature = "std"), no_std)]
 #![cfg_attr(docsrs, feature(doc_cfg))]
-// disable warning for already-stabilized features.
-// Needed to pass CI, because we deny warnings.
-// We don't immediately remove them to not immediately break older nightlies.
-// When all features are stable, we'll remove them.
-#![cfg_attr(all(feature = "async", nightly), allow(stable_features))]
-#![cfg_attr(
-    all(feature = "async", nightly),
-    feature(async_fn_in_trait, impl_trait_projections)
-)]
 
 // needed to prevent defmt macros from breaking, since they emit code that does `defmt::blahblah`.
 #[cfg(feature = "defmt-03")]

embedded-hal-bus/build.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-bus/src/lib.rs

@@ -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