Announcing Rust 1.40.0

Suppose you’re a library author of a crate alpha, that has a pub struct Foo. You would like to make alpha::Foo’s fields pub as well, but you’re not sure whether you might be adding more fields to Foo in future releases. So now you have a dilemma: either you make the fields private, with the drawbacks that follow, or you risk users depending on the exact fields, breaking their code when you add a new one. Rust 1.40.0 introduces a way to break the logjam: #[non_exhaustive].

The attribute #[non_exhaustive], when attached to a struct or the variant of an enum, will prevent code outside of the crate defining it from constructing said struct or variant. To avoid future breakage, other crates are also prevented from exhaustively matching on the fields. The following example illustrates errors in beta which depends on alpha:

// alpha/lib.rs:

#[non_exhaustive]
struct Foo {
    pub a: bool,
}

enum Bar {
    #[non_exhaustive]
    Variant { b: u8 }
}

fn make_foo() -> Foo { ... }
fn make_bar() -> Bar { ... }

// beta/lib.rs:

let x = Foo { a: true }; //~ ERROR
let Foo { a } = make_foo(); //~ ERROR

// `beta` will still compile when more fields are added.
let Foo { a, .. } = make_foo(); //~ OK


let x = Bar::Variant { b: 42 }; //~ ERROR
let Bar::Variant { b } = make_bar(); //~ ERROR
let Bar::Variant { b, .. } = make_bar(); //~ OK
                   // -- `beta` will still compile...

What happens behind the scenes is that the visibility of the constructors for a #[non_exhaustive] struct or enum variant is lowered to pub(crate), preventing access outside the crate defining it.

A perhaps more important aspect of #[non_exhaustive] is that it can also be attached to enums themselves. An example, taken from the standard library, is Ordering:

#[non_exhaustive]
pub enum Ordering { Relaxed, Release, Acquire, AcqRel, SeqCst }

The purpose of #[non_exhaustive] in this context is to ensure that more variants can be added over time. This is achieved by preventing other crates from exhaustively pattern match-ing on Ordering. That is, the compiler would reject:

match ordering {
    // This is an error, since if a new variant is added,
    // this would suddenly break on an upgrade of the compiler.
    Relaxed | Release | Acquire | AcqRel | SeqCst => {
        /* logic */
    }
}

Instead, other crates need to account for the possibility of more variants by adding a wildcard arm using e.g. _:

match ordering {
    Relaxed | Release | Acquire | AcqRel | SeqCst => { /* ... */ }
    // OK; if more variants are added, nothing will break.
    _ => { /* logic */ }
}

For more details on the #[non_exhaustive] attribute, see the stabilization report.

In 1.40.0, we have introduced several improvements to macros and attributes, including:

• Calling procedural macros mac!() in type contexts.

  For example, you may write type Foo = expand_to_type!(bar); where expand_to_type would be a procedural macro.

• Macros in extern { ... } blocks.

  This includes bang!() macros, for example:

  macro_rules! make_item { ($name:ident) => { fn $name(); } }
  
  extern {
      make_item!(alpha);
      make_item!(beta);
  }
  

  Procedural macro attributes on items in extern { ... } blocks are now also supported:

  extern "C" {
      // Let's assume that this expands to `fn foo();`.
      #[my_identity_macro]
      fn foo();
  }
  

• Generating macro_rules! items in procedural macros.

  Function-like (mac!()) and attribute (#[mac]) macros can both now generate macro_rules! items. For details on hygiene, please refer to the attached stabilization report.

• The $m:meta matcher supports arbitrary token-stream values.

  That is, the following is now valid:

  macro_rules! accept_meta { ($m:meta) => {} }
  accept_meta!( my::path );
  accept_meta!( my::path = "lit" );
  accept_meta!( my::path ( a b c ) );
  accept_meta!( my::path [ a b c ] );
  accept_meta!( my::path { a b c } );
  

In the 1.35.0 release, we announced that NLL had come to Rust 2015 after first being released for the 2018 edition in Rust 1.31.

As we noted back then, the old borrow checker had some bugs which would allow memory unsafety, and the NLL borrow checker fixed them. As these fixes break some stable code, we decided to gradually phase in the errors, by checking if the old borrow checker would accept the program and the NLL checker would reject it. In those cases, the errors would be downgraded to warnings.

The previous release, Rust 1.39.0, changes these warnings into errors for code using the 2018 edition. Rust 1.40.0 applies the same change for users of the 2015 edition, closing those soundness holes for good. This also allows us to clean up the old code from the compiler.

If your build breaks due to this change, or you want to learn more, check out Niko Matsakis’s blog post.

With Rust 1.40.0, the following function became const fn:

• is_power_of_two for unsigned integers

In Rust 1.40.0 the following functions and macros were stabilized:

• todo!()

  A macro, which is a shorter, more memorable, and convenient version of unimplemented!().

• slice::repeat

  Creates a Vec<T> by repeating a slice n times.

• mem::take

  This function takes the value out of a mutable reference and replaces it with the type’s default. This is similar to Option::take and Cell::take and provides a convenient short-hand for mem::replace(&mut dst, Default::default()).

• BTreeMap::get_key_value and HashMap::get_key_value

  Returns the key-value pair corresponding to the supplied key.

• Option::as_deref, Option::as_deref_mut

  These work similarly to Option::as_ref and Option::as_mut but also use Deref and DerefMut respectively, so that opt_box.as_deref() and opt_box.as_deref_mut(), where opt_box: Option<Box<T>>, produce an Option<&T> and Option<&mut T> respectively.

• Option::flatten

  This function flattens an Option<Option<T>> to Option<T> producing Some(x) for Some(Some(x)) and None otherwise. The function is similar to Iterator::flatten.

• UdpSocket::peer_addr

  Returns the socket address of the remote peer this socket was connected to.

• {f32,f64}::to_be_bytes, {f32,f64}::to_le_bytes,{f32,f64}::to_ne_bytes, {f32,f64}::from_be_bytes, {f32,f64}::from_le_bytes, and {f32,f64}::from_ne_bytes

  Return the memory representation of the floating point number as a byte array in big-endian (network), little-endian, and native-endian byte order.