Cargo considers Rust versions for dependency version selection

1.84.0 stabilizes the minimum supported Rust version (MSRV) aware resolver, which prefers dependency versions compatible with the project’s declared MSRV. With MSRV-aware version selection, the toil is reduced for maintainers to support older toolchains by not needing to manually select older versions for each dependency.

You can opt-in to the MSRV-aware resolver via .cargo/config.toml:

[resolver]
incompatible-rust-versions = "fallback"

Then when adding a dependency:

$ cargo add clap
    Updating crates.io index
warning: ignoring clap@4.5.23 (which requires rustc 1.74) to maintain demo's rust-version of 1.60
      Adding clap v4.0.32 to dependencies
    Updating crates.io index
     Locking 33 packages to latest Rust 1.60 compatible versions
      Adding clap v4.0.32 (available: v4.5.23, requires Rust 1.74)

When verifying the latest dependencies in CI, you can override this:

$ CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS=allow cargo update
    Updating crates.io index
     Locking 12 packages to latest compatible versions
    Updating clap v4.0.32 -> v4.5.23

You can also opt-in by setting package.resolver = "3" in the Cargo.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).

This gives library authors more flexibility when deciding their policy on adopting new Rust toolchain features. Previously, a library adopting features from a new Rust toolchain would force downstream users of that library who have an older Rust version to either upgrade their toolchain or manually select an old version of the library compatible with their toolchain (and avoid running cargo update). Now, those users will be able to automatically use older library versions compatible with their older toolchain.

See the documentation for more considerations when deciding on an MSRV policy.

Migration to the new trait solver begins

The Rust compiler is in the process of moving to a new implementation for the trait solver. The next-generation trait solver is a reimplementation of a core component of Rust’s type system. It is not only responsible for checking whether trait-bounds - e.g. Vec<T>: Clone - hold, but is also used by many other parts of the type system, such as normalization - figuring out the underlying type of <Vec<T> as IntoIterator>::Item - and equating types (checking whether T and U are the same).

In 1.84, the new solver is used for checking coherence of trait impls. At a high level, coherence is responsible for ensuring that there is at most one implementation of a trait for a given type while considering not yet written or visible code from other crates.

This stabilization fixes a few mostly theoretical correctness issues of the old implementation, resulting in potential “conflicting implementations of trait …” errors that were not previously reported. We expect the affected patterns to be very rare based on evaluation of available code through Crater. The stabilization also improves our ability to prove that impls do not overlap, allowing more code to be written in some cases.

For more details, see a previous blog post and the stabilization report.

Strict provenance APIs

In Rust, pointers are not simply an “integer” or “address”. For instance, a “use after free” is undefined behavior even if you “get lucky” and the freed memory gets reallocated before your read/write. As another example, writing through a pointer derived from an &i32 reference is undefined behavior, even if writing to the same address via a different pointer is legal. The underlying pattern here is that the way a pointer is computed matters, not just the address that results from this computation. For this reason, we say that pointers have provenance: to fully characterize pointer-related undefined behavior in Rust, we have to know not only the address the pointer points to, but also track which other pointer(s) it is “derived from”.

Most of the time, programmers do not need to worry much about provenance, and it is very clear how a pointer got derived. However, when casting pointers to integers and back, the provenance of the resulting pointer is underspecified. With this release, Rust is adding a set of APIs that can in many cases replace the use of integer-pointer-casts, and therefore avoid the ambiguities inherent to such casts. In particular, the pattern of using the lowest bits of an aligned pointer to store extra information can now be implemented without ever casting a pointer to an integer or back. This makes the code easier to reason about, easier to analyze for the compiler, and also benefits tools like Miri and architectures like CHERI that aim to detect and diagnose pointer misuse.

For more details, see the standard library documentation on provenance.

Stabilized APIs

These APIs are now stable in const contexts

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.