Rust is een programmeertaal bedacht door Graydon Hoare en oorspronkelijk ontwikkeld door Mozilla. Het is deels geïnspireerd op de programmeertaal C, maar kent syntactische en semantische verschillen. Het focust op veiligheid en moet moderne computersystemen efficiënter benutten. Het wordt onder meer ingezet door Cloudflare, OVH, Mozilla, Deliveroo, Coursera, AppSignal en Threema. Versie 1.89 is uitgebracht en de releasenotes voor die uitgave kunnen hieronder worden gevonden.
Explicitly inferred arguments to const genericsRust now supports
_
as an argument to const generic parameters, inferring the value from surrounding context:pub fn all_false<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:Mismatched lifetime syntaxes lint// This is not allowed pub const fn all_false<const LEN: usize>() -> [bool; _] { [false; LEN] } // Neither is this pub const ALL_FALSE: [bool; _] = all_false::<10>();
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 // type to be the same as that of `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 theelided_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
- lifetime elision inference rules connect an input lifetime to an output lifetime
- 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 whilestd::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 theelided_named_lifetimes
lint, which did something similar for named lifetimes specifically.Future work on the
More x86 target featureselided_lifetimes_in_paths
lint intends to split it into more focused sub-lints with an eye to warning about a subset of them eventually.The
target_feature
attribute now supports thesha512
,sm3
,sm4
,kl
andwidekl
target features on x86. Additionally a number ofavx512
intrinsics and target features are also supported on x86:Cross-compiled doctests#[target_feature(enable = "avx512bw")] pub fn cool_simd_code(/* .. */) -> /* ... */ { /* ... */ }
Doctests will now be tested when running
cargo test --doc --target other_target
, this may result in some amount of breakage due to would-be-failing doctests now being tested.Failing tests can be disabled by annotating the doctest with
ignore-<target>
(docs):/// ```ignore-x86_64 /// panic!("something") /// ``` pub fn my_function() { }
i128
andu128
inextern "C"
functions
i128
andu128
no longer trigger theimproper_ctypes_definitions
lint, meaning these types may be used inextern "C"
functions without warning. This comes with some caveats:
- The Rust types are ABI- and layout-compatible with (unsigned)
__int128
in C when the type is available.- On platforms where
__int128
is not available,i128
andu128
do not necessarily align with any C type.i128
is not necessarily compatible with_BitInt(128)
on any platform, because_BitInt(128)
and__int128
may not have the same ABI (as is the case on x86-64).This is the last bit of follow up to the layout changes from last year: https://blog.rust-lang.org/2024/03/30/i128-layout-update.
Demotingx86_64-apple-darwin
to Tier 2 with host toolsGitHub will soon discontinue providing free macOS x86_64 runners for public repositories. Apple has also announced their plans for discontinuing support for the x86_64 architecture.
In accordance with these changes, the Rust project is in the process of demoting the
x86_64-apple-darwin
target from Tier 1 with host tools to Tier 2 with host tools. This means that the target, including tools likerustc
andcargo
, 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-apple-darwin
is a Tier 1 target.For users, this change will not immediately cause impact. Builds of both the standard library and the compiler will still be distributed by the Rust Project for use via
Standards Compliant C ABI on therustup
or alternative installation methods while the target remains at Tier 2. Over time, it's likely that reduced test coverage for this target will cause things to break or fall out of compatibility with no further announcements.wasm32-unknown-unknown
targetPlatform Support
extern "C"
functions on thewasm32-unknown-unknown
target now have a standards compliant ABI. See this blog post for more information: https://blog.rust-lang.org/2025/04/04/c-abi-changes-for-wasm32-unknown-unknown.
x86_64-apple-darwin
is in the process of being demoted to Tier 2 with host tools- Add new Tier-3 targets
loongarcb2-unknown-none
andloongarcb2-unknown-none-softfloat
Refer to Rust’s platform support page for more information on Rust’s tiered platform support.
Stabilized APIs
NonZero<char>
- Many intrinsics for x86, not enumerated here
File::lock
File::lock_shared
File::try_lock
File::try_lock_shared
File::unlock
NonNull::from_ref
NonNull::from_mut
NonNull::without_provenance
NonNull::with_exposed_provenance
NonNull::expose_provenance
OsString::leak
PathBuf::leak
Result::flatten
std::os::linux::net::TcpStreamExt::quickack
std::os::linux::net::TcpStreamExt::set_quickack
These previously stable APIs are now stable in const contexts:
Other changesCheck out everything that changed in Rust, Cargo, and Clippy.