Skip to content

Announce Rust 1.89.0 #1666

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
+80 −0
Open

Announce Rust 1.89.0 #1666

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e065861
Announcing Rust 1.89.0
BoxyUwU Jul 24, 2025
1ebc7da
Explicitly clarify const items' types for gai
BoxyUwU Jul 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 80 additions & 0 deletions content/Rust-1.89.0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
+++
path = "2025/08/07/Rust-1.89.0"
title = "Announcing Rust 1.89.0"
authors = ["The Rust Release Team"]
aliases = ["releases/1.89.0"]

[extra]
release = true
+++

The Rust team is happy to announce a new version of Rust, 1.89.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.89.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.89.0](https://doc.rust-lang.org/stable/releases.html#version-1890-2025-08-07).

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.89.0 stable

### Explicitly inferred arguments to const generics

Rust now supports `_` as an argument to const generic parameters, inferring the value from surrounding context:

```rust
pub fn make_bitset<const LEN: usize>() -> [bool; LEN] {
[false; _]
}
```

Similar to the rules for when `_` is permitted as a type, `_` is not permitted as an argument to const generics when in a signature:

```rust
// This is not allowed
pub const fn make_bitset<const LEN: usize>() -> [bool; _] {
[false; LEN]
}
// Neither is this
pub const MY_BITSET: [bool; _] = make_bitset::<10>();
```

### Mismatched lifetimes syntax lint

TC/LANG to write this
Comment on lines +46 to +48
Copy link
Member

@shepmaster shepmaster Jul 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mismatched lifetime syntaxes lint

Lifetime elision in function signatures is an ergonomic aspect of the Rust language, but it can also be a stumbling point for newcomers and experts alike. This is especially true when lifetimes are inferred in types where it isn't syntactically obvious that a lifetime is even present:

// The returned type `std::slice::Iter` has a lifetime, 
// but there's no visual indication of that.
//
// Lifetime elision infers the lifetime of the return 
// value to be the same as the argument `scores`.
fn items(scores: &[u8]) -> std::slice::Iter<u8> {
   scores.iter()
}

Code like this will now produce a warning by default:

warning: hiding a lifetime that's elided elsewhere is confusing
 --> src/lib.rs:1:18
  |
1 | fn items(scores: &[u8]) -> std::slice::Iter<u8> {
  |                  ^^^^^     -------------------- the same lifetime is hidden here
  |                  |
  |                  the lifetime is elided here
  |
  = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
  = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
  |
1 | fn items(scores: &[u8]) -> std::slice::Iter<'_, u8> {
  |                                             +++

We first attempted to improve this situation back in 2018 as part of the rust_2018_idioms lint group, but strong feedback about the elided_lifetimes_in_paths lint showed that it was too blunt of a hammer as it warns about lifetimes which don't matter to understand the function:

use std::fmt;

struct Greeting;

impl fmt::Display for Greeting {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        //                -----^^^^^^^^^ expected lifetime parameter
        // Knowing that `Formatter` has a lifetime does not help the programmer
        "howdy".fmt(f)
    }
}

We then realized that the confusion we want to eliminate occurs when both

  1. lifetime elision inference rules connect an input lifetime to an output lifetime
  2. it's not syntactically obvious that a lifetime exists

There are two pieces of Rust syntax that indicate that a lifetime exists: & and ', with ' being subdivided into the inferred lifetime '_ and named lifetimes 'a. When a type uses a named lifetime, lifetime elision will not infer a lifetime for that type. Using these criteria, we can construct three groups:

Self-evident it has a lifetime Allow lifetime elision to infer a lifetime Examples
No Yes ContainsLifetime
Yes Yes &T, &'_ T, ContainsLifetime<'_>
Yes No &'a T, ContainsLifetime<'a>

The mismatched_lifetime_syntaxes lint checks that the inputs and outputs of a function belong to the same group. For the initial motivating example above, &[u8] falls into the second group while std::slice::Iter<u8> falls into the first group. We say that the lifetimes in the first group are hidden.

Because the input and output lifetimes belong to different groups, the lint will warn about this function, reducing confusion about when a value has a meaningful lifetime that isn't visually obvious.

The mismatched_lifetime_syntaxes lint supersedes the elided_named_lifetimes lint, which did something similar for named lifetimes specifically.

Future work on the elided_lifetimes_in_paths lint intends to split it into more focused sub-lints with an eye to warning about a subset of them eventually.

Copy link
Contributor

@traviscross traviscross Jul 28, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's great. Thanks for writing that up.

One thing that I would like us to get in there somewhere is that we consider the lifetime in ContainsLifetime to be hidden. We don't need to get into whether that's a subtype of elided or a separate category or whatnot -- that's not important. But that when it's not self-evident (as you so well put it) that a type path has a lifetime, that the lifetime is "hidden" is nomenclature we adopted deliberately and should introduce in the narrative.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we consider the lifetime in ContainsLifetime to be hidden

I took a stab at that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the compiler output above seems to have lost = note:#[warn(mismatched_lifetime_syntaxes)] on by default -- I think we should keep that, to make it very clear this is a lint that can be disabled if the user wants to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I took that out because it comes and goes (is it the first warning, is it set on the command line, etc.) I can add it back if you think it’s useful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth keeping, yes.


### More x86 target features

The `target_feature` attribute now supports the `sha512`, `sm3`, `sm4`, `kl` and `widekl` target features on x86. Additionally a number of `avx512` intrinsics and target features are also supported on x86:

```rust
#[target_feature(enable = "avx512bw")]
pub fn cool_simd_code(/* .. */) -> /* ... */ {
/* ... */
}

```
Comment on lines +52 to +60
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @Amanieu @sayantn :3 I don't know much about this

Copy link

@sayantn sayantn Jul 25, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also specify that all avx512 intrinsics in std::arch::{x86,x86_64} are stable now (same for the other target features).

Edit: nvm I didn't see it right


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're playing a little fast and loose with the timing of this announcement, but the "worst" case is that we extend support one more release, which people are unlikely to be unhappy about.

Suggested change
### Demoting `x86_64-apple-darwin` to Tier 2 with host tools
GitHub will soon [discontinue][gha-sunset] providing free macOS x86\_64 runners for public repositories. Apple has also announced their [plans][apple] for discontinuing support for the x86\_86 architecture.
In accordance with these changes, the Rust project is in the [process of demoting the `x86_64-apple-darwin` target][rfc] from Tier 1 to Tier 2 with host tools. This means that the target, including tools like `rustc` and `cargo`, will be guaranteed to build but is not guaranteed to pass our automated test suite.
We expect that the RFC for the demotion to Tier 2 with host tools will be accepted between the releases of Rust 1.89 and 1.90, which means that Rust 1.89 will be the last release of Rust where x86\_64 macOS is a Tier 1 target.
For users, nothing will change. Builds of both the standard library and the compiler will still be distributed by the Rust Project for use via `rustup` or alternative installation methods.
[apple]: https://en.wikipedia.org/wiki/Mac_transition_to_Apple_silicon#Timeline
[gha-sunset]: https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/#macos-13-is-closing-down
[rfc]: https://github.com/rust-lang/rfcs/pull/3841

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe s/x86_64 macOS/x86_64-apple-darwin/.

### Platform Support

- [Add new Tier-3 targets `loongarch32-unknown-none` and `loongarch32-unknown-none-softfloat`](https://github.com/rust-lang/rust/pull/142053)

Refer to Rust’s [platform support page][platform_support_page] for more information on Rust’s tiered platform support.

### Stabilized APIs

TODO

### Other changes

Check out everything that changed in [Rust](https://github.com/rust-lang/rust/releases/tag/1.89.0), [Cargo](https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-189-2025-08-07), and [Clippy](https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-189).

## Contributors to 1.89.0

Many people came together to create Rust 1.89.0. We couldn't have done it without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.89.0/)

[platform_support_page]: https://doc.rust-lang.org/rustc/platform-support.html