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/main.rs:1:5
|
1 | use rustix::io_uring;
| ^^^^^^^^^^^^^^^^ no `io_uring` in the root
|
note: found an item that was configured out
--> /home/username/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustix-0.38.8/src/lib.rs:213:9
|
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:
-
clippy::undropped_manually_dropschanged toundropped_manually_dropswith deny level;
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.
-
clippy::invalid_utf8_in_uncheckedrenamed toinvalid_from_utf8_uncheckedwith deny level andinvalid_from_utf8with warn level;
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.
-
clippy::cmp_nanconverted toinvalid_nan_comparisonswith warn level;
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.
-
clippy::cast_ref_to_mutupdated toinvalid_reference_castingwith allow level;
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:
-
impl<T:Send>Syncformpsc::Sender<T> -
implTryFrom<OsStr>for str -
String::leak
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!
