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 get rustup from the appropriate page on our website, and check out the detailed release notes for 1.66.0 on 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). Please report 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,
    D,
}

Here the Bar enum is guaranteed to have the same layout as u8. In addition, the Bar::C variant is guaranteed to have a discriminant of 42. Variants without explicitly-specified values will have discriminants that are automatically assigned according to their order in the source code, so Bar::A will have a discriminant of 0, Bar::B will have a discriminant of 1, and Bar::D will have a discriminant of 43. Without this feature, the only way to set the explicit value of Bar::C would be to add 41 unnecessary variants before it!

Note: whereas for field-less enums it is possible to inspect a discriminant via as casting (e.g. Bar::C as u8), Rust provides no language-level way to access the raw discriminant of an enum with fields. Instead, currently unsafe code must be used to inspect the discriminant of an enum with fields. Since this feature is intended for use with cross-language FFI where unsafe code is already necessary, this should hopefully not be too much of an extra burden. In the meantime, if all you need is an opaque handle to the discriminant, please see the std::mem::discriminant function.

`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 in Rust, 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!