Software-update: Rust 1.89.0

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 generics

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

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

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:

Code like this will now produce a warning by default:

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:

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:

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.

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:

Cross-compiled doctests

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):

i128 and u128 in extern "C" functions

i128 and u128 no longer trigger the improper_ctypes_definitions lint, meaning these types may be used in extern "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 and u128 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).

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 and u128 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.

Demoting x86_64-apple-darwin to Tier 2 with host tools

GitHub 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 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-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 rustup 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.

Standards Compliant C ABI on the wasm32-unknown-unknown target

extern "C" functions on the wasm32-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.

Platform Support

x86_64-apple-darwin is in the process of being demoted to Tier 2 with host toolsAdd new Tier-3 targets loongarcb2-unknown-none and loongarcb2-unknown-none-softfloat

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 and loongarcb2-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 hereAVX512 intrinsicsSHA512, SM3 and SM4 intrinsicsFile::lockFile::lock_sharedFile::try_lockFile::try_lock_sharedFile::unlockNonNull::from_refNonNull::from_mutNonNull::without_provenanceNonNull::with_exposed_provenanceNonNull::expose_provenanceOsString::leakPathBuf::leakResult::flattenstd::os::linux::net::TcpStreamExt::quickackstd::os::linux::net::TcpStreamExt::set_quickack

NonZero<char>

Many intrinsics for x86, not enumerated hereAVX512 intrinsicsSHA512, SM3 and SM4 intrinsics

AVX512 intrinsicsSHA512, SM3 and SM4 intrinsics

AVX512 intrinsics

SHA512, SM3 and SM4 intrinsics

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:

<[T; N]>::as_mut_slice<[u8]>::eq_ignore_ascii_casestr::eq_ignore_ascii_case

<[T; N]>::as_mut_slice

<[u8]>::eq_ignore_ascii_case

str::eq_ignore_ascii_case

Other changes

Check out everything that changed in Rust, Cargo, and Clippy.

Source: Tweakers.net