Rust 1.72.0: The Latest Version Is Announced

  • Rust version 1.72.0 enhances the use of cfg-disabled items and improves developer feedback through the compiler.
  • What changes were made in Rust 1.72.0 to overcome the previous limitation on constant evaluation during compilation?
Rust 1.72.0 Update: New Features and Enhanced Stability

The dynamic world of programming welcomes a significant update as the Rust team introduces Rust version 1.72.0. Rust, renowned for fostering the creation of robust and high-performance software, continues to spearhead innovation in the programming language landscape.

The latest version introduces a groundbreaking feature that enhances the utility of cfg-disabled items. Conditionally activating Rust code through cfg has always been a pivotal technique for tailoring functions based on distinct crate features or specific platforms. Previously, components deactivated via this method remained unnoticed by the compiler, causing potential challenges for developers. The compiler now retains vital information, including item names and cfg conditions. This enables the compiler to provide insightful feedback, such as highlighting the unavailability of a function due to the necessity of enabling a specific crate feature. This empowers developers with clearer guidance and facilitates a more efficient coding experience. Rust new features cement its position as a prime choice for those striving to construct dependable and efficient software.

Compiling my-project v0.1.0 (/tmp/my-project)
error[E0432]: unresolved import `rustix::io_uring`
   --> src/
1   | use rustix::io_uring;
    |     ^^^^^^^^^^^^^^^^ no `io_uring` in the root
note: found an item that was configured out
   --> /home/username/.cargo/registry/src/
213 | pub mod io_uring;
    |         ^^^^^^^^
    = note: the item is gated behind the `io_uring` feature

For more information about this error, try `rustc --explain E0432`.
error: could not compile `my-project` (bin "my-project") due to previous error


Rust version 1.72.0 cements its position as a prime choice for those striving to construct dependable and efficient software.

In the past, Rust imposed a cap on the number of statements executed during user-provided constant evaluation. This constraint was intended to prevent scenarios where such evaluations might trigger infinite loops or excessively lengthy computations during compile time. However, this limitation occasionally resulted in compilation errors, particularly when intricate Rust code was involved. Additionally, the applicability of this constraint varied significantly based on the external libraries employed. If a library invoked by a user fragmented a statement within one of its functions, it could lead to compilation failures.

Presently, the Rust 1.72 update does not have a ceiling on the extent of const evaluation achievable during compile time. To prevent prolonged compilations lacking feedback, the compiler will issue a notification once the compile-time code has been executing for a certain duration. Subsequently, this notification will be reiterated at intervals that progressively double. By default, to identify potential infinite loops, the compiler will trigger a deny-by-default lint (const_eval_long_running) after a substantial number of steps. This aims to capture instances of const evaluation that appear to be excessively protracted. Nevertheless, it's possible to employ allow(const_eval_long_running) to grant permission for exceptionally lengthy const evaluations.

A number of lints previously found in Clippy have been incorporated into the rustc compiler:

When dealing with ManuallyDrop, the inner value is not dropped automatically. Invoking std::mem::drop on it has no effect. Instead, this lint now proposes using ManuallyDrop::into_inner as the primary option. Alternatively, the unsafe ManuallyDrop::drop can be used to invoke the destructor in place. By default, this lint is disallowed.

The first lint identifies instances where std::str::from_utf8_unchecked and std::str::from_utf8_unchecked_mut are used with invalid UTF-8 literals. Such usage violates their safety prerequisites, leading to undefined behavior. This lint is now categorically prohibited.

The second lint detects calls to std::str::from_utf8 and std::str::from_utf8_mut with malformed UTF-8 literals, which inevitably trigger errors. This lint now issues a warning by default.

This lint identifies comparisons involving f32::NAN or f64::NAN as operands. Since NaN lacks meaningful comparisons—even to itself—such comparisons are invariably evaluated as false. This lint now issues a warning, accompanied by a recommendation to use the is_nan() method.

This lint highlights instances where &T is cast to &mut T without leveraging interior mutability. Such actions result in immediate undefined behavior, regardless of whether the reference is employed. Although this lint currently permits such casting by default due to potential false positives, there are plans to alter this behavior. In version 1.73, after implementation enhancements, it is anticipated that this lint will be turned off by default.

Stable APIs now include:

The following APIs are now also stable within constant contexts:

How do you feel about the latest version? Let us know your thoughts in the comments below!

Tetiana Rafalovych
Tetiana Rafalovych
Professional author in IT Industry

Author of captivating articles and news for Atlasiko Inc. I consistently deliver engaging content that captivates readers and keeps them coming back for more. I try to ensure that every piece is well-researched and informative. Whether it's news, in-depth features, or insightful analysis, I have a knack for transforming complex information into narratives that resonate with audiences.

Share your thoughts in the comments below!

Have any ideas or suggestions about the article or website? Feel free to write it.

Any Questions?

Get in touch with us by simply filling up the form to start our fruitful cooperation right now.

Please check your email
Get a Free Estimate