Rust Blog: Post

Rust Blog

Announcing Rust 1.66.0

The Rust team is happy to announce a new version of Rust, 1.66.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.66.0 with:

rustup update stable

If you don't have it already, you can getrustup from the appropriate page on our website, and check out the detailed release notes for 1.66.0on GitHub.

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). Pleasereport any bugs you might come across!

What's in 1.66.0 stable

Explicit discriminants on enums with fields

Enums with integer representations can now use explicit discriminants, even when they have fields.

#[repr(u8)]
enum Foo {
    A(u8),
    B(i8),
    C(bool) = 42,
}

Previously, you could use explicit discriminants on enums with representations, but only if none of their variants had fields. Explicit discriminants are useful when passing values across language boundaries where the representation of the enum needs to match in both languages. For example,

#[repr(u8)]
enum Bar {
    A,
    B,
    C = 42,
}

Here the Bar enum is guaranteed to have the same layout as u8. Each variant will use either the specified discriminant value or default to starting with 0.

assert_eq!(0, Bar::A as u8);
assert_eq!(1, Bar::B as u8);
assert_eq!(42, Bar::C as u8);

You could even add fields to enums with #[repr(Int)], and they would be laid out in a predictable way. Previously, however, you could not use these features together. That meant that making Foo::C's discriminant equal to 42 as above would be harder to achieve. You would need to add 41 hidden variants in between as a workaround with implicit discriminants!

Starting in Rust 1.66.0, the above example compiles, allowing you to use explicit discriminants on any enum with a #[repr(Int)] attribute.

core::hint::black_box

When benchmarking or examining the machine code produced by a compiler, it's often useful to prevent optimizations from occurring in certain places. In the following example, the function push_cap executes Vec::push 4 times in a loop:

fn push_cap(v: &mut Vec<i32>) {
    for i in 0..4 {
        v.push(i);
    }
}

pub fn bench_push() -> Duration { 
    let mut v = Vec::with_capacity(4);
    let now = Instant::now();
    push_cap(&mut v);
    now.elapsed()
}

If you inspect the optimized output of the compiler on x86_64, you'll notice that it looks rather short:

example::bench_push:
  sub rsp, 24
  call qword ptr [rip + std::time::Instant::now@GOTPCREL]
  lea rdi, [rsp + 8]
  mov qword ptr [rsp + 8], rax
  mov dword ptr [rsp + 16], edx
  call qword ptr [rip + std::time::Instant::elapsed@GOTPCREL]
  add rsp, 24
  ret

In fact, the entire function push_cap we wanted to benchmark has been optimized away!

We can work around this using the newly stabilized black_box function. Functionally, black_box is not very interesting: it takes the value you pass it and passes it right back. Internally, however, the compiler treats black_box as a function that could do anything with its input and return any value (as its name implies).

This is very useful for disabling optimizations like the one we see above. For example, we can hint to the compiler that the vector will actually be used for something after every iteration of the for loop.

use std::hint::black_box;

fn push_cap(v: &mut Vec<i32>) {
    for i in 0..4 {
        v.push(i);
        black_box(v.as_ptr());
    }
}

Now we can find the unrolled for loop in our optimized assembly output:

  mov dword ptr [rbx], 0
  mov qword ptr [rsp + 8], rbx
  mov dword ptr [rbx + 4], 1
  mov qword ptr [rsp + 8], rbx
  mov dword ptr [rbx + 8], 2
  mov qword ptr [rsp + 8], rbx
  mov dword ptr [rbx + 12], 3
  mov qword ptr [rsp + 8], rbx

You can also see a side effect of calling black_box in this assembly output. The instruction mov qword ptr [rsp + 8], rbx is uselessly repeated after every iteration. This instruction writes the address v.as_ptr() as the first argument of the function, which is never actually called.

Notice that the generated code is not at all concerned with the possibility of allocations introduced by the push call. This is because the compiler is still using the fact that we called Vec::with_capacity(4) in the bench_push function. You can play around with the placement of black_box, or try using it in multiple places, to see its effects on compiler optimizations.

cargo remove

In Rust 1.62.0 we introduced cargo add, a command line utility to add dependencies to your project. Now you can use cargo remove to remove dependencies.

Stabilized APIs

Other changes

There are other changes in the Rust 1.66 release, including:

  • You can now use ..=X ranges in patterns.
  • Linux builds now optimize the rustc frontend and LLVM backend with LTO and BOLT, respectively, improving both runtime performance and memory usage.

Check out everything that changed inRust,Cargo, and Clippy.

Contributors to 1.66.0

Many people came together to create Rust 1.66.0. We couldn't have done it without all of you.Thanks!

Continue Reading…