The Rust team is happy to announce a new version of Rust, 1.86.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.86.0 with: $ rustup update stable If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.86.0. 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 any bugs you might come across! What's in 1.86.0 stable Trait upcasting This release includes a long awaited feature — the ability to upcast trait objects. If a trait has a supertrait you can coerce a reference to said trait object to a reference to a trait object of the supertrait: trait Trait: Supertrait {}
trait Supertrait {}

fn upcast(x: &dyn Trait) -> &dyn Supertrait {
    x
} The same would work with any other kind of (smart-)pointer, like Arc<dyn Trait> -> Arc<dyn Supertrait> or *const dyn Trait -> *const dyn Supertrait. Previously this would have required a workaround in the form of an upcast method in the Trait itself, for example fn as_supertrait(&self) -> &dyn Supertrait, and this would work only for one kind of reference/pointer. Such workarounds are not necessary anymore. Note that this means that raw pointers to trait objects carry a non-trivial invariant: "leaking" a raw pointer to a trait object with an invalid vtable into safe code may lead to undefined behavior. It is not decided yet whether creating such a raw pointer temporarily in well-controlled circumstances causes immediate undefined behavior, so code should refrain from creating such pointers under any conditions (and Miri enforces that). Trait upcasting may be especially useful with the Any trait, as it allows upcasting your trait object to dyn Any to call Any's downcast methods, without adding any trait methods or using external crates. use std::any::Any;

trait MyAny: Any {}

impl dyn MyAny {
    fn downcast_ref<T>(&self) -> Option<&T> {
        (self as &dyn Any).downcast_ref()
    }
} You can learn more about trait upcasting in the Rust reference. HashMaps and slices now support indexing multiple elements mutably The borrow checker prevents simultaneous usage of references obtained from repeated calls to get_mut methods. To safely support this pattern the standard library now provides a get_disjoint_mut helper on slices and HashMap to retrieve mutable references to multiple elements simultaneously. See the following example taken from the API docs of slice::get_disjoint_mut: let v = &mut [1, 2, 3];
if let Ok([a, b]) = v.get_disjoint_mut([0, 2]) {
    *a = 413;
    *b = 612;
}
assert_eq!(v, &[413, 2, 612]);

if let Ok([a, b]) = v.get_disjoint_mut([0..1, 1..3]) {
    a[0] = 8;
    b[0] = 88;
    b[1] = 888;
}
assert_eq!(v, &[8, 88, 888]);

if let Ok([a, b]) = v.get_disjoint_mut([1..=2, 0..=0]) {
    a[0] = 11;
    a[1] = 111;
    b[0] = 1;
}
assert_eq!(v, &[1, 11, 111]); Allow safe functions to be marked with the #[target_feature] attribute. Previously only unsafe functions could be marked with the #[target_feature] attribute as it is unsound to call such functions without the target feature being enabled. This release stabilizes the target_feature_11 feature, allowing safe functions to be marked with the #[target_feature] attribute. Safe functions marked with the target feature attribute can only be safely called from other functions marked with the target feature attribute. However, they cannot be passed to functions accepting generics bounded by the Fn* traits and only support being coerced to function pointers inside of functions marked with the target_feature attribute. Inside of functions not marked with the target feature attribute they can be called inside of an unsafe block, however it is the caller's responsibility to ensure that the target feature is available. #[target_feature(enable = "avx2")]
fn requires_avx2() {
    // ... snip
}

#[target_feature(enable = "avx2")]
fn safe_callsite() {
    // Calling `requires_avx2` here is safe as `safe_callsite`
    // requires the `avx2` feature itself.
    requires_avx2();
}

fn unsafe_callsite() {
    // Calling `requires_avx2` here is unsafe, as we must
    // ensure that the `avx2` feature is available first.
    if is_x86_feature_detected!("avx2") {
        unsafe { requires_avx2() };
    }
} You can check the target_features_11 RFC for more information. Debug assertions that pointers are non-null when required for soundness The compiler will now insert debug assertions that a pointer is not null upon non-zero-sized reads and writes, and also when the pointer is reborrowed into a reference. For example, the following code will now produce a non-unwinding panic when debug assertions are enabled: let _x = *std::ptr::null::<u8>();
let _x = &*std::ptr::null::<u8>(); Trivial examples like this have produced a warning since Rust 1.53.0, the new runtime check will detect these scenarios regardless of complexity. These assertions only take place when debug assertions are enabled which means that they must not be relied upon for soundness. This also means that dependencies which have been compiled with debug assertions disabled (e.g. the standard library) will not trigger the assertions even when called by code with debug assertions enabled. Make missing_abi lint warn by default Omitting the ABI in extern blocks and functions (e.g. extern {} and extern fn) will now result in a warning (via the missing_abi lint). Omitting the ABI after the extern keyword has always implicitly resulted in the "C" ABI. It is now recommended to explicitly specify the "C" ABI (e.g. extern "C" {} and extern "C" fn). You can check the Explicit Extern ABIs RFC for more information. Target deprecation warning for 1.87.0 The tier-2 target i586-pc-windows-msvc will be removed in the next version of Rust, 1.87.0. Its difference to the much more popular i686-pc-windows-msvc is that it does not require SSE2 instruction support, but Windows 10, the minimum required OS version of all windows targets (except the win7 targets), requires SSE2 instructions itself. All users currently targeting i586-pc-windows-msvc should migrate to i686-pc-windows-msvc before the 1.87.0 release. You can check the Major Change Proposal for more information. Stabilized APIs {float}::next_down
{float}::next_up
<[_]>::get_disjoint_mut
<[_]>::get_disjoint_unchecked_mut
slice::GetDisjointMutError
HashMap::get_disjoint_mut
HashMap::get_disjoint_unchecked_mut
NonZero::count_ones
Vec::pop_if
sync::Once::wait
sync::Once::wait_force
sync::OnceLock::wait These APIs are now stable in const contexts: hint::black_box
io::Cursor::get_mut
io::Cursor::set_position
str::is_char_boundary
str::split_at
str::split_at_checked
str::split_at_mut
str::split_at_mut_checked Other changes Check out everything that changed in Rust, Cargo, and Clippy. Contributors to 1.86.0 Many people came together to create Rust 1.86.0. We couldn't have done it without all of you. Thanks! Credits: The Rust Release Team Also published here Photo by Nik Shuliahin 💛💙 on Unsplash The Rust team is happy to announce a new version of Rust, 1.86.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.86.0 with: rustup $ rustup update stable $ rustup update stable If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.86.0 . get rustup detailed release notes for 1.86.0 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 any bugs you might come across! rustup default beta rustup default nightly report What's in 1.86.0 stable Trait upcasting This release includes a long awaited feature — the ability to upcast trait objects. If a trait has a supertrait you can coerce a reference to said trait object to a reference to a trait object of the supertrait: supertrait trait Trait: Supertrait {}
trait Supertrait {}

fn upcast(x: &dyn Trait) -> &dyn Supertrait {
    x
} trait Trait: Supertrait {}
trait Supertrait {}

fn upcast(x: &dyn Trait) -> &dyn Supertrait {
    x
} The same would work with any other kind of (smart-)pointer, like Arc<dyn Trait> -> Arc<dyn Supertrait> or *const dyn Trait -> *const dyn Supertrait . Arc<dyn Trait> -> Arc<dyn Supertrait> *const dyn Trait -> *const dyn Supertrait Previously this would have required a workaround in the form of an upcast method in the Trait itself, for example fn as_supertrait(&self) -> &dyn Supertrait , and this would work only for one kind of reference/pointer. Such workarounds are not necessary anymore. upcast Trait fn as_supertrait(&self) -> &dyn Supertrait Note that this means that raw pointers to trait objects carry a non-trivial invariant: "leaking" a raw pointer to a trait object with an invalid vtable into safe code may lead to undefined behavior. It is not decided yet whether creating such a raw pointer temporarily in well-controlled circumstances causes immediate undefined behavior, so code should refrain from creating such pointers under any conditions (and Miri enforces that). Trait upcasting may be especially useful with the Any trait, as it allows upcasting your trait object to dyn Any to call Any 's downcast methods, without adding any trait methods or using external crates. Any dyn Any Any use std::any::Any;

trait MyAny: Any {}

impl dyn MyAny {
    fn downcast_ref<T>(&self) -> Option<&T> {
        (self as &dyn Any).downcast_ref()
    }
} use std::any::Any;

trait MyAny: Any {}

impl dyn MyAny {
    fn downcast_ref<T>(&self) -> Option<&T> {
        (self as &dyn Any).downcast_ref()
    }
} You can learn more about trait upcasting in the Rust reference . learn more about trait upcasting in the Rust reference HashMap s and slices now support indexing multiple elements mutably HashMap The borrow checker prevents simultaneous usage of references obtained from repeated calls to get_mut methods. To safely support this pattern the standard library now provides a get_disjoint_mut helper on slices and HashMap to retrieve mutable references to multiple elements simultaneously. See the following example taken from the API docs of slice::get_disjoint_mut : get_mut get_disjoint_mut HashMap slice::get_disjoint_mut let v = &mut [1, 2, 3];
if let Ok([a, b]) = v.get_disjoint_mut([0, 2]) {
    *a = 413;
    *b = 612;
}
assert_eq!(v, &[413, 2, 612]);

if let Ok([a, b]) = v.get_disjoint_mut([0..1, 1..3]) {
    a[0] = 8;
    b[0] = 88;
    b[1] = 888;
}
assert_eq!(v, &[8, 88, 888]);

if let Ok([a, b]) = v.get_disjoint_mut([1..=2, 0..=0]) {
    a[0] = 11;
    a[1] = 111;
    b[0] = 1;
}
assert_eq!(v, &[1, 11, 111]); let v = &mut [1, 2, 3];
if let Ok([a, b]) = v.get_disjoint_mut([0, 2]) {
    *a = 413;
    *b = 612;
}
assert_eq!(v, &[413, 2, 612]);

if let Ok([a, b]) = v.get_disjoint_mut([0..1, 1..3]) {
    a[0] = 8;
    b[0] = 88;
    b[1] = 888;
}
assert_eq!(v, &[8, 88, 888]);

if let Ok([a, b]) = v.get_disjoint_mut([1..=2, 0..=0]) {
    a[0] = 11;
    a[1] = 111;
    b[0] = 1;
}
assert_eq!(v, &[1, 11, 111]); Allow safe functions to be marked with the #[target_feature] attribute. #[target_feature] Previously only unsafe functions could be marked with the #[target_feature] attribute as it is unsound to call such functions without the target feature being enabled. This release stabilizes the target_feature_11 feature, allowing safe functions to be marked with the #[target_feature] attribute. unsafe #[target_feature] target_feature_11 safe #[target_feature] Safe functions marked with the target feature attribute can only be safely called from other functions marked with the target feature attribute. However, they cannot be passed to functions accepting generics bounded by the Fn* traits and only support being coerced to function pointers inside of functions marked with the target_feature attribute. Fn* target_feature Inside of functions not marked with the target feature attribute they can be called inside of an unsafe block, however it is the caller's responsibility to ensure that the target feature is available. unsafe #[target_feature(enable = "avx2")]
fn requires_avx2() {
    // ... snip
}

#[target_feature(enable = "avx2")]
fn safe_callsite() {
    // Calling `requires_avx2` here is safe as `safe_callsite`
    // requires the `avx2` feature itself.
    requires_avx2();
}

fn unsafe_callsite() {
    // Calling `requires_avx2` here is unsafe, as we must
    // ensure that the `avx2` feature is available first.
    if is_x86_feature_detected!("avx2") {
        unsafe { requires_avx2() };
    }
} #[target_feature(enable = "avx2")]
fn requires_avx2() {
    // ... snip
}

#[target_feature(enable = "avx2")]
fn safe_callsite() {
    // Calling `requires_avx2` here is safe as `safe_callsite`
    // requires the `avx2` feature itself.
    requires_avx2();
}

fn unsafe_callsite() {
    // Calling `requires_avx2` here is unsafe, as we must
    // ensure that the `avx2` feature is available first.
    if is_x86_feature_detected!("avx2") {
        unsafe { requires_avx2() };
    }
} You can check the target_features_11 RFC for more information. target_features_11 Debug assertions that pointers are non-null when required for soundness The compiler will now insert debug assertions that a pointer is not null upon non-zero-sized reads and writes, and also when the pointer is reborrowed into a reference. For example, the following code will now produce a non-unwinding panic when debug assertions are enabled: let _x = *std::ptr::null::<u8>();
let _x = &*std::ptr::null::<u8>(); let _x = *std::ptr::null::<u8>();
let _x = &*std::ptr::null::<u8>(); Trivial examples like this have produced a warning since Rust 1.53.0, the new runtime check will detect these scenarios regardless of complexity. These assertions only take place when debug assertions are enabled which means that they must not be relied upon for soundness. This also means that dependencies which have been compiled with debug assertions disabled (e.g. the standard library) will not trigger the assertions even when called by code with debug assertions enabled. must not Make missing_abi lint warn by default missing_abi Omitting the ABI in extern blocks and functions (e.g. extern {} and extern fn ) will now result in a warning (via the missing_abi lint). Omitting the ABI after the extern keyword has always implicitly resulted in the "C" ABI. It is now recommended to explicitly specify the "C" ABI (e.g. extern "C" {} and extern "C" fn ). extern {} extern fn missing_abi extern "C" "C" extern "C" {} extern "C" fn You can check the Explicit Extern ABIs RFC for more information. Explicit Extern ABIs RFC Target deprecation warning for 1.87.0 The tier-2 target i586-pc-windows-msvc will be removed in the next version of Rust, 1.87.0. Its difference to the much more popular i686-pc-windows-msvc is that it does not require SSE2 instruction support, but Windows 10, the minimum required OS version of all windows targets (except the win7 targets), requires SSE2 instructions itself. i586-pc-windows-msvc i686-pc-windows-msvc windows win7 All users currently targeting i586-pc-windows-msvc should migrate to i686-pc-windows-msvc before the 1.87.0 release. i586-pc-windows-msvc i686-pc-windows-msvc 1.87.0 You can check the Major Change Proposal for more information. Major Change Proposal Stabilized APIs {float}::next_down {float}::next_up <[_]>::get_disjoint_mut <[_]>::get_disjoint_unchecked_mut slice::GetDisjointMutError HashMap::get_disjoint_mut HashMap::get_disjoint_unchecked_mut NonZero::count_ones Vec::pop_if sync::Once::wait sync::Once::wait_force sync::OnceLock::wait {float}::next_down {float}::next_down {float}::next_up {float}::next_up <[_]>::get_disjoint_mut <[_]>::get_disjoint_mut <[_]>::get_disjoint_unchecked_mut <[_]>::get_disjoint_unchecked_mut slice::GetDisjointMutError slice::GetDisjointMutError HashMap::get_disjoint_mut HashMap::get_disjoint_mut HashMap::get_disjoint_unchecked_mut HashMap::get_disjoint_unchecked_mut NonZero::count_ones NonZero::count_ones Vec::pop_if Vec::pop_if sync::Once::wait sync::Once::wait sync::Once::wait_force sync::Once::wait_force sync::OnceLock::wait sync::OnceLock::wait These APIs are now stable in const contexts: hint::black_box io::Cursor::get_mut io::Cursor::set_position str::is_char_boundary str::split_at str::split_at_checked str::split_at_mut str::split_at_mut_checked hint::black_box hint::black_box io::Cursor::get_mut io::Cursor::get_mut io::Cursor::set_position io::Cursor::set_position str::is_char_boundary str::is_char_boundary str::split_at str::split_at str::split_at_checked str::split_at_checked str::split_at_mut str::split_at_mut str::split_at_mut_checked str::split_at_mut_checked Other changes Check out everything that changed in Rust , Cargo , and Clippy . Rust Cargo Clippy Contributors to 1.86.0 Many people came together to create Rust 1.86.0. We couldn't have done it without all of you. Thanks! Thanks! Credits: The Rust Release Team Credits: The Rust Release Team Also published here Also published here here Photo by Nik Shuliahin 💛💙 on Unsplash Photo by Nik Shuliahin 💛💙 on Unsplash Nik Shuliahin 💛💙 Unsplash

Unsplash

Rust Is Adopting FLS: What Does This Mean for the Rust Reference?

wasm32-unknown-unknown - The C ABI Changes That You Need to Know About

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Introducing Rust 1.86.0: Trait Upcasting, HashMaps, and More

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

All the Details and Changes That Came With Rust 1.82.0

Building Secure Open Referral Systems: Harnessing HashMaps for Effective Fraud Prevention

How to use HashMap with Custom Keys (and Avoid Shooting Yourself in the Leg)

Learn How to Live with Immutable and Reliable Objects in Java

Some insights on Maps in Golang

All the Details and Changes That Came With Rust 1.82.0

Building Secure Open Referral Systems: Harnessing HashMaps for Effective Fraud Prevention

How to use HashMap with Custom Keys (and Avoid Shooting Yourself in the Leg)

Learn How to Live with Immutable and Reliable Objects in Java

Some insights on Maps in Golang

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps