I own a library in Rust with daily tests running in github pipeline. These tests include MSRV build (currently 1.69.0). These MSRV tests fail from time to time when Cargo decides to resolve some package to version not compatible with the specified rust version.
Here's a most recent example on two consecutive days (no code changes in between):
tokio v1.38.1
. Builds fine with 1.69.0tokio v1.39.1
. Fails to build despite tokio
correctly specifying rust-version = 1.70.0
(bumped here, before release here)Again, tokio v1.39.1
says that it requires rust-version = 1.70.0
. My own Cargo.toml
specifies a very lax version:
#...
[dev-dependencies]
tokio = { version = "1", features = ["full"] }
#...
Because it's a dev dependency and I don't want to deal with bumping it regularly, just use the latest compatible version everywhere.
For now I pinned tokio
stricter, but the same problem happened in past with dependencies
, which was a huger problem I failed to deal with appropriately (just bumped MSRV due to dep resolution failure).
This is a library, so Cargo.lock
is not a thing I can leverage (ref) to deal with this. What am I missing? Why is cargo
resolver bringing package versions ignoring their rust-version
constraint?
As of Rust 1.84.0, the resolver is MSRV-aware:
You can opt-in to the MSRV-aware resolver via
.cargo/config.toml
:[resolver] incompatible-rust-versions = "fallback"
You can also opt-in by setting
package.resolver = "3"
in theCargo.toml
manifest file though that will require raising your MSRV to 1.84. The new resolver will be enabled by default for projects using the 2024 edition (which will stabilize in 1.85).
Prior to that, the cargo dependency resolver was not MSRV-aware. You'd need to manually determine compatible dependencies and lock their versions.