Rust 1.34 release

Hi, Habr! I present to your attention the translation of the article "The Rust Release Team" Announcing Rust 1.34.0 " .

The Rust development team is pleased to announce the release of a new version of Rust, 1.34.0. Rust is a programming language that enables everyone to create reliable and efficient software.

If you have a previous version of Rust installed using rustup, then to update Rust to version 1.34.0, you just need to run:

$ rustup update stable

If you have not yet installed rustup, you can install it from the corresponding page of our website.

What is included in the stable version 1.34.0

The main improvement to this release is support for alternative cargo registries. Does the release also include support ? in documentation tests, some improvements in #[attribute(...)] and TryFrom stabilization. Read on for key points or see the detailed release notes for more information.

Alternative `cargo` registries

Even before version 1.0, Rust had a public registry, crates.io . People published crates with cargo publish and easily connected these crates in the [dependencies] section of Cargo.toml .

However, not everyone wants to publish their crates on crates.io. People supporting closed source projects could not use crates.io, and instead they had to specify git or path in dependencies. There is nothing like this for small projects, but if your large organization has a lot of closed-source crate, you lose the benefits of versioning support, which is in crates.io.

Starting with this release, Cargo may support alternative registries. These registries coexist with crates.io, so you can write programs that depend on crates.io and your registry. However, crates.io crates cannot depend on an external registry.

To use alternative registries, you must add the following lines to .cargo/config . This file can be in your home directory ( ~/.cargo/config ) or in a package directory.

 [registries] my-registry = { index = "https://my-intranet:8080/git/index" }

Add dependencies from an alternative registry is easy. When you specify a dependency in Cargo.toml , use the registry key so that Cargo knows that you want to receive the crate from an alternative registry:

 [dependencies] other-crate = { version = "1.0", registry = "my-registry" }

As the author of the crate, if you want to publish your crate in the alternative registry, the first thing you need to do is save the authentication token in ~/.cargo/credentials using the cargo login command:

 cargo login --registry=my-registry

Then you can use the --registry flag to specify the registry to which the crate will be published:

 cargo publish --registry=my-registry

How you can run your own registry, you can find in the documentation .

`?` in documentation tests

In RFC 1937, it was suggested to add support for using the operator ? in fn main() , #[test] functions and documentation tests, allowing them to return Option<T> or Result<T, E> where the error option results in a nonzero exit code in the case of fn main() or a dropped test in the case of tests .

Support in fn main() and #[test] was implemented a long time ago . However, support in documentation tests was limited to tests in which fn main() clearly present.

Does this release add full support ? in the documentation tests. Now you can write in your documentation tests:

 /// ```rust /// use std::io; /// let mut input = String::new(); /// io::stdin().read_line(&mut input)?; /// # Ok::<(), io:Error>(()) /// ``` fn my_func() {}

At the bottom of the documentation test, you still need to specify the type of error that will be used.

Support for arbitrary token flow in custom attributes

Procedural macros in Rust can define custom attributes that they use. Until now, these attributes were limited to path trees and literals according to the following syntax:

 #[foo(bar)] #[foo = "bar"] #[foo = 0] #[foo(bar = true)] #[foo(bar, baz(quux, foo = "bar"))]

Unlike procedural macros, these auxiliary attributes could not accept an arbitrary stream of tokens in the delimiter, which is why you could not write #[range(0..10)] or #[bound(T: MyTrait)] . The crate of procedural macros instead used strings for syntax like this, for example #[range("0..10")] .

With this release, custom attributes #[attr($tokens)] allow you to use arbitrary tokens in $tokens , aligning them with macros. If you are the author of the procedure macro crate, please check if the syntax of your user attributes is used in the syntax and can be replaced with a stream of tokens.

`TryFrom` and `TryInto`

The TryFrom and TryInto were stabilized to support type conversion errors.

For example, from_be_bytes and the associated methods of integer types get an array, but the data is often read through slices. Manual conversion between slices and arrays is tedious. With new traits, it is possible to do this in a single line with .try_into() .

 let num = u32::from_be_bytes(slice.try_into()?);

For conversions that cannot complete with an error, such as u8 to u32 , the type Infallible added. Due to this, TryFrom automatically implemented for everything that the From trait implements. In the future, we hope to make Infallible pseudonym for the ! (never) .

`fn before_exec` deprecated in favor of `unsafe fn pre_exec`

On Unix-like systems, the CommandExt::before_exec allowed you to schedule a closure before calling exec .

This closure was performed in the context of the child process after the fork. This means that resources, such as file descriptors and memory areas, could be duplicated. In other words, you could get a copy of the value of a non- Copy type in different processes, while the original would remain in the parent. This could lead to indefinite behavior and break down libraries implying no duplication .

Therefore, the before_exec function should be marked unsafe . In this issue, we have marked fn before_exec obsolete in favor of unsafe fn pre_exec . When calling CommandExt::pre_exec you need to make sure that the closure does not violate the library invariants by creating non-valid duplicates. If you are providing a library that is in a situation similar to before_exec , consider obsolescence and provide an alternative to unsafe .

Library Stabilization

In 1.34.0, the set of stable atomic integer signed and unsigned types is extended, starting with 8 bit ( AtomicU8 ) and ending with 64 bit.

Previously , nonzero unsigned integer numbers such as NonZeroU8 have been stabilized. Thanks to this, the Option<NonZeroU8> is the same size as the u8 . In this release, sign versions are stabilized, such as NonZeroI8 .

The functions iter::from_fn and iter::successors stabilized. The first allows you to create an iterator from FnMut() -> Option<T> . To iteratively get elements from a vector, you can now write from_fn(|| vec.pop()) . Meanwhile, the second function creates a new iterator, where each next element is calculated based on the previous one.

Additionally, the following APIs have been stabilized: