diff --git a/originals/announcements/2025-01-09-Rust-1.84.0.md b/originals/announcements/2025-01-09-Rust-1.84.0.md new file mode 100644 index 0000000..e8da20e --- /dev/null +++ b/originals/announcements/2025-01-09-Rust-1.84.0.md @@ -0,0 +1,117 @@ +--- +layout: post +title: "Announcing Rust 1.84.0" +author: The Rust Release Team +release: true +--- + +The Rust team is happy to announce a new version of Rust, 1.84.0. Rust is a programming language empowering everyone to build reliable and efficient software. + +If you have a previous version of Rust installed via `rustup`, you can get 1.84.0 with: + +```console +$ rustup update stable +``` + +If you don't have it already, you can [get `rustup`](https://www.rust-lang.org/install.html) from the appropriate page on our website, and check out the [detailed release notes for 1.84.0](https://doc.rust-lang.org/stable/releases.html#version-1840-2025-01-09). + +If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (`rustup default beta`) or the nightly channel (`rustup default nightly`). Please [report](https://github.com/rust-lang/rust/issues/new/choose) any bugs you might come across! + +## What's in 1.84.0 stable + +### Cargo can use toolchain version for library version selection + +1.84.0 stabilizes the minimum supported Rust version (MSRV) aware resolver, +which uses the declared [minimum supported Rust version](https://doc.rust-lang.org/cargo/reference/rust-version.html) from +dependencies, if available, to improve package version selection. Rust version +aware selection allows library authors to easily adopt newer Rust versions +while allowing consumers of the library to automatically use old versions +if they need compatibility with older toolchains. + +Library authors should take the MSRV-aware resolver into account 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. +In the future, we expect this to provide more flexibility for library authors +to select their preferred support strategy for Rust versions, with the toolchain +helping users on older toolchains avoid breakage. + +The new resolver will be enabled by default with the 2024 edition (expected to +stabilize in 1.85), but can be enabled as of 1.84 by setting +[`package.resolver = "3"`](https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions) in the Cargo.toml manifest file, or +[`resolver.incompatible-rust-versions = "fallback"`](https://doc.rust-lang.org/cargo/reference/config.html#resolverincompatible-rust-versions) in the Cargo configuration file. + +Read [the documentation](https://doc.rust-lang.org/cargo/reference/resolver.html#rust-version) for more details. + +### Migration to a 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: Clone` - hold, but is also used by many +other parts of the type system, such as normalization - figuring out the +underlying type of ` 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, including *globally* in not yet +written or visible code in downstream crates from the current compilation. + +This stabilization does include some breaking changes, primarily by fixing some +correctness issues with the old solver. Typically these will show up as new +"conflicting implementations of trait ..." errors that were not previously +reported. We expect instances of this to be rare based on evaluation of +available code through [Crater], as the soundness holes in the previous solving +engine used relatively esoteric code. It also improves our ability to detect +where impls do *not* overlap, allowing more code to be written in some cases. + +For more details, see a [previous blog post](https://blog.rust-lang.org/inside-rust/2024/12/04/trait-system-refactor-initiative.html) +and the [stabilization report](https://github.com/rust-lang/rust/pull/130654) + +[Crater]: https://github.com/rust-lang/crater/ + +### Strict provenance APIs + +In Rust, [pointers are not simply an “integer” or +“address”](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html). For +instance, it’s uncontroversial to say that a Use After Free is clearly +Undefined Behavior, even if you “get lucky” and the freed memory gets +reallocated before your read/write. It is also uncontroversial that 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](https://github.com/rust-lang/miri) and architectures like +[CHERI](https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/) that aim to +detect and diagnose pointer misuse. + +For more details, see the standard library [documentation on provenance](https://doc.rust-lang.org/std/ptr/index.html#provenance). + +### Stabilized APIs + +TODO, relnotes still in-progress for this section + +### Other changes + +Check out everything that changed in [Rust](https://github.com/rust-lang/rust/releases/tag/1.84.0), [Cargo](https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-184-2025-01-09), and [Clippy](https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-184). + +## Contributors to 1.84.0 + +Many people came together to create Rust 1.84.0. We couldn't have done it without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.84.0/)