
The Rust team has released version 1.84.0 stable, with progress in the next-generation trait solver and improved dependency version checking, though a name change in the WebAssembly System Interface (WASI) target could break toolchains if developers have not yet made the necessary updates.
There are three headline features in this new version of Rust. The first is that the Cargo resolver is aware of the minimum supported Rust version (MRSV) is now stable, though not enabled by default. Cargo is the official Rust package manager. If an updated package requires a newer version of Rust, cargo can now automatically ignore it. MSRV uses an optional rust-version field in the package manifest.
Next, there is progress in the next generation trait solver. The new trait solver is part of the Rust type system, and determines whether and how a type implements a trait (similar to an interface in other languages). According to the Rust Types Team, the new solver “should fix many long-standing (soundness) bugs, enable future type system improvements, and improve compile-times.” The new solver is not yet complete, but will now be used for coherence checking, ensuring that there is at most one implementation of a trait for any given type.
Third, Rust is adding APIs for strict provenance checking of pointers, particularly when casting pointers to integers and back, which the team explains has inherent ambiguities. The new APIs will benefit tools like Miri which detect undefined behavior in Rust code, as well as efforts to prove that Rust code is formally correct.
Some developers will receive an error when upgrading Rust because the target wasm32-wasi is no longer available. This is because this target was renamed in Rust 1.71 to was32-wasip1 [zero point 1]. The solution is to remove the target with:
rustup target remove wasm32-wasi
before upgrading.
The story behind this is that there is also a wasm-wasip2 [zero point 2] target, matching the milestone releases of WASI (WebAssembly System Interface). Naming the original target wasm32-wasi, when it was still an early preview, was an error, disguising the fact that it is a snapshot of an interface under development. Developers were warned of the change in April last year, and given an eight-month transition period for projects to switch to the new target name. Inevitably some will not have done so, and the disappearance of wasm32-wasi will cause some friction, though it may also serve as impetus to move to the newer warm-wasip2 target where possible.