added rust 1.84 draft

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<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, 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/)