The Rust team is happy to announce a new version of Rust, 1.80.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.80.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.80.0. get rustup detailed release notes for 1.80.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.80.0 stable LazyCell and LazyLock LazyCell LazyLock These "lazy" types delay the initialization of their data until first access. They are similar to the OnceCell and OnceLock types stabilized in 1.70, but with the initialization function included in the cell. This completes the stabilization of functionality adopted into the standard library from the popular lazy_static and once_cell crates. OnceCell OnceLock stabilized in 1.70 lazy_static once_cell LazyLock is the thread-safe option, making it suitable for places like static values. For example, both the spawn thread and the main scope will see the exact same duration below, since LAZY_TIME will be initialized once, by whichever ends up accessing the static first. Neither use has to know how to initialize it, unlike they would with OnceLock::get_or_init(). LazyLock static spawn scope LAZY_TIME how OnceLock::get_or_init() use std::sync::LazyLock;
use std::time::Instant;

static LAZY_TIME: LazyLock<Instant> = LazyLock::new(Instant::now);

fn main() {
    let start = Instant::now();
    std::thread::scope(|s| {
        s.spawn(|| {
            println!("Thread lazy time is {:?}", LAZY_TIME.duration_since(start));
        });
        println!("Main lazy time is {:?}", LAZY_TIME.duration_since(start));
    });
} use std::sync::LazyLock;
use std::time::Instant;

static LAZY_TIME: LazyLock<Instant> = LazyLock::new(Instant::now);

fn main() {
    let start = Instant::now();
    std::thread::scope(|s| {
        s.spawn(|| {
            println!("Thread lazy time is {:?}", LAZY_TIME.duration_since(start));
        });
        println!("Main lazy time is {:?}", LAZY_TIME.duration_since(start));
    });
} LazyCell does the same thing without thread synchronization, so it doesn't implement Sync, which is needed for static, but it can still be used in thread_local! statics (with distinct initialization per thread). Either type can also be used in other data structures as well, depending on thread-safety needs, so lazy initialization is available everywhere! LazyCell Sync static thread_local! Checked cfg names and values cfg In 1.79, rustc stabilized a --check-cfg flag, and now Cargo 1.80 is enabling those checks for all cfg names and values that it knows (in addition to the well known names and values from rustc). This includes feature names from Cargo.toml as well as new cargo::rustc-check-cfg output from build scripts. rustc --check-cfg cfg well known names and values rustc Cargo.toml cargo::rustc-check-cfg Unexpected cfgs are reported by the warn-by-default unexpected_cfgs lint, which is meant to catch typos or other misconfiguration. For example, in a project with an optional rayon dependency, this code is configured for the wrong feature value: unexpected_cfgs rayon feature fn main() {
    println!("Hello, world!");

    #[cfg(feature = "crayon")]
    rayon::join(
        || println!("Hello, Thing One!"),
        || println!("Hello, Thing Two!"),
    );
}


warning: unexpected `cfg` condition value: `crayon`
 --> src/main.rs:4:11
  |
4 |     #[cfg(feature = "crayon")]
  |           ^^^^^^^^^^--------
  |                     |
  |                     help: there is a expected value with a similar name: `"rayon"`
  |
  = note: expected values for `feature` are: `rayon`
  = help: consider adding `crayon` as a feature in `Cargo.toml`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: `#[warn(unexpected_cfgs)]` on by default fn main() {
    println!("Hello, world!");

    #[cfg(feature = "crayon")]
    rayon::join(
        || println!("Hello, Thing One!"),
        || println!("Hello, Thing Two!"),
    );
}


warning: unexpected `cfg` condition value: `crayon`
 --> src/main.rs:4:11
  |
4 |     #[cfg(feature = "crayon")]
  |           ^^^^^^^^^^--------
  |                     |
  |                     help: there is a expected value with a similar name: `"rayon"`
  |
  = note: expected values for `feature` are: `rayon`
  = help: consider adding `crayon` as a feature in `Cargo.toml`
  = note: see <https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html> for more information about checking conditional configuration
  = note: `#[warn(unexpected_cfgs)]` on by default The same warning is reported regardless of whether the actual rayon feature is enabled or not. rayon The [lints] table in the Cargo.toml manifest can also be used to extend the list of known names and values for custom cfg. rustc automatically provides the syntax to use in the warning. [lints] Cargo.toml cfg rustc the syntax [lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] } [lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] } You can read more about this feature in a previous blog post announcing the availability of the feature on nightly. previous blog post Exclusive ranges in patterns Rust ranged patterns can now use exclusive endpoints, written a..b or ..b similar to the Range and RangeTo expression types. For example, the following patterns can now use the same constants for the end of one pattern and the start of the next: a..b ..b Range RangeTo pub fn size_prefix(n: u32) -> &'static str {
    const K: u32 = 10u32.pow(3);
    const M: u32 = 10u32.pow(6);
    const G: u32 = 10u32.pow(9);
    match n {
        ..K => "",
        K..M => "k",
        M..G => "M",
        G.. => "G",
    }
} pub fn size_prefix(n: u32) -> &'static str {
    const K: u32 = 10u32.pow(3);
    const M: u32 = 10u32.pow(6);
    const G: u32 = 10u32.pow(9);
    match n {
        ..K => "",
        K..M => "k",
        M..G => "M",
        G.. => "G",
    }
} Previously, only inclusive (a..=b or ..=b) or open (a..) ranges were allowed in patterns, so code like this would require separate constants for inclusive endpoints like K - 1. a..=b ..=b a.. K - 1 Exclusive ranges have been implemented as an unstable feature for a long time, but the blocking concern was that they might add confusion and increase the chance of off-by-one errors in patterns. To that end, exhaustiveness checking has been enhanced to better detect gaps in pattern matching, and new lints non_contiguous_range_endpoints and overlapping_range_endpoints will help detect cases where you might want to switch exclusive patterns to inclusive, or vice versa. non_contiguous_range_endpoints overlapping_range_endpoints Stabilized APIs impl Default for Rc<CStr>
impl Default for Rc<str>
impl Default for Rc<[T]>
impl Default for Arc<str>
impl Default for Arc<CStr>
impl Default for Arc<[T]>
impl IntoIterator for Box<[T]>
impl FromIterator<String> for Box<str>
impl FromIterator<char> for Box<str>
LazyCell
LazyLock
Duration::div_duration_f32
Duration::div_duration_f64
Option::take_if
Seek::seek_relative
BinaryHeap::as_slice
NonNull::offset
NonNull::byte_offset
NonNull::add
NonNull::byte_add
NonNull::sub
NonNull::byte_sub
NonNull::offset_from
NonNull::byte_offset_from
NonNull::read
NonNull::read_volatile
NonNull::read_unaligned
NonNull::write
NonNull::write_volatile
NonNull::write_unaligned
NonNull::write_bytes
NonNull::copy_to
NonNull::copy_to_nonoverlapping
NonNull::copy_from
NonNull::copy_from_nonoverlapping
NonNull::replace
NonNull::swap
NonNull::drop_in_place
NonNull::align_offset
<[T]>::split_at_checked
<[T]>::split_at_mut_checked
str::split_at_checked
str::split_at_mut_checked
str::trim_ascii
str::trim_ascii_start
str::trim_ascii_end
<[u8]>::trim_ascii
<[u8]>::trim_ascii_start
<[u8]>::trim_ascii_end
Ipv4Addr::BITS
Ipv4Addr::to_bits
Ipv4Addr::from_bits
Ipv6Addr::BITS
Ipv6Addr::to_bits
Ipv6Addr::from_bits
Vec::<[T; N]>::into_flattened
<[[T; N]]>::as_flattened
<[[T; N]]>::as_flattened_mut impl Default for Rc<CStr> impl Default for Rc<CStr> impl Default for Rc<str> impl Default for Rc<str> impl Default for Rc<[T]> impl Default for Rc<[T]> impl Default for Arc<str> impl Default for Arc<str> impl Default for Arc<CStr> impl Default for Arc<CStr> impl Default for Arc<[T]> impl Default for Arc<[T]> impl IntoIterator for Box<[T]> impl IntoIterator for Box<[T]> impl FromIterator<String> for Box<str> impl FromIterator<String> for Box<str> impl FromIterator<char> for Box<str> impl FromIterator<char> for Box<str> LazyCell LazyCell LazyLock LazyLock Duration::div_duration_f32 Duration::div_duration_f32 Duration::div_duration_f64 Duration::div_duration_f64 Option::take_if Option::take_if Seek::seek_relative Seek::seek_relative BinaryHeap::as_slice BinaryHeap::as_slice NonNull::offset NonNull::offset NonNull::byte_offset NonNull::byte_offset NonNull::add NonNull::add NonNull::byte_add NonNull::byte_add NonNull::sub NonNull::sub NonNull::byte_sub NonNull::byte_sub NonNull::offset_from NonNull::offset_from NonNull::byte_offset_from NonNull::byte_offset_from NonNull::read NonNull::read NonNull::read_volatile NonNull::read_volatile NonNull::read_unaligned NonNull::read_unaligned NonNull::write NonNull::write NonNull::write_volatile NonNull::write_volatile NonNull::write_unaligned NonNull::write_unaligned NonNull::write_bytes NonNull::write_bytes NonNull::copy_to NonNull::copy_to NonNull::copy_to_nonoverlapping NonNull::copy_to_nonoverlapping NonNull::copy_from NonNull::copy_from NonNull::copy_from_nonoverlapping NonNull::copy_from_nonoverlapping NonNull::replace NonNull::replace NonNull::swap NonNull::swap NonNull::drop_in_place NonNull::drop_in_place NonNull::align_offset NonNull::align_offset <[T]>::split_at_checked <[T]>::split_at_checked <[T]>::split_at_mut_checked <[T]>::split_at_mut_checked str::split_at_checked str::split_at_checked str::split_at_mut_checked str::split_at_mut_checked str::trim_ascii str::trim_ascii str::trim_ascii_start str::trim_ascii_start str::trim_ascii_end str::trim_ascii_end <[u8]>::trim_ascii <[u8]>::trim_ascii <[u8]>::trim_ascii_start <[u8]>::trim_ascii_start <[u8]>::trim_ascii_end <[u8]>::trim_ascii_end Ipv4Addr::BITS Ipv4Addr::BITS Ipv4Addr::to_bits Ipv4Addr::to_bits Ipv4Addr::from_bits Ipv4Addr::from_bits Ipv6Addr::BITS Ipv6Addr::BITS Ipv6Addr::to_bits Ipv6Addr::to_bits Ipv6Addr::from_bits Ipv6Addr::from_bits Vec::<[T; N]>::into_flattened Vec::<[T; N]>::into_flattened <[[T; N]]>::as_flattened <[[T; N]]>::as_flattened <[[T; N]]>::as_flattened_mut <[[T; N]]>::as_flattened_mut These APIs are now stable in const contexts: <[T]>::last_chunk
BinaryHeap::new <[T]>::last_chunk <[T]>::last_chunk BinaryHeap::new BinaryHeap::new Other changes Check out everything that changed in Rust, Cargo, and Clippy. Rust Cargo Clippy Contributors to 1.80.0 Many people came together to create Rust 1.80.0. We couldn't have done it without all of you. Thanks! Thanks! The Rust Release Team Also published here here Photo by Lay Naik on Unsplash Lay Naik Unsplash

Unsplash

Rust 1.80.0: Exclusive Ranges in Patterns, Stabilized APIs, and More

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

All the Details and Changes That Came With Rust 1.82.0

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

All the Details and Changes That Came With Rust 1.82.0

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps