Wouldn't it be more robust to set `resolver.incompatible-rust-versions="fallback"`

[thejpster]

Wouldn't it be more robust to set resolver.incompatible-rust-versions="fallback" (or resolver = "3" or edition = '2024' which changed the default to fallback)?

That way, cargo will automatically select versions of dependencies that are compatible with the current compiler.
Bumping the rustc version used in CI only helps with the new MSRV of heapless, but will break again once any dependency updates to a more recent MSRV.

Originally posted by @jannic in #211 (comment)

[jannic]

I tried all three options before #211 was merged. All three fixed the build issue, as expected, like this:

    Updating crates.io index
     Locking 84 packages to latest Rust 1.86 compatible versions
      Adding embedded-io v0.6.1 (available: v0.7.1)
      Adding generic-array v0.14.7 (available: v0.14.9)
      Adding heapless v0.9.1 (available: v0.9.2, requires Rust 1.87)
   Compiling heapless v0.9.1
   Compiling byteorder v1.5.0
   Compiling stable_deref_trait v1.2.1
   Compiling embedded-hal v1.0.0
   Compiling embedded-io v0.6.1
   Compiling hash32 v0.3.1
   Compiling embedded-sdmmc v0.9.0 (/home/jan/embedded/embedded-sdmmc-rs)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.73s

For setting resolver.incompatible-rust-versions="fallback" I had to add a .cargo/config.toml which is a little bit less discoverable than setting edition or resolver in Cargo.toml.

Setting edition to 2024 triggers a new clippy::let_and_return clippy warning, but otherwise works fine. To me this looks like the best approach.

[jannic]

Setting edition to 2024 triggers a new clippy::let_and_return clippy warning, but otherwise works fine. To me this looks like the best approach.

It also changes some formatting details, see https://doc.rust-lang.org/stable/edition-guide/rust-2024/rustfmt.html