Rust 1.34 Release

Hello, Habr! I present to you 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 upgrade Rust to version 1.34.0 you just need to do:

$ rustup update stable

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

What is included in the stable version 1.34.0

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

Alternative cargoregistries

Before version 1.0, Rust had a public registry, . People published racks with help cargo publishand easily connected these racks in section [dependencies]c Cargo.toml.

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

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

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

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

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

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 ~/.cargo/credentialsusing the command cargo login:

cargo login --registry=my-registry

Next, you can use the flag --registryto specify the registry in which the rack will be published:

cargo publish --registry=my-registry

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

? in documentation tests

In RFC 1937 it was proposed to add support for the use of the operator ?in fn main(), #[test]features and documentation testing, allowing them to recover or wherein the variant with an error leads to a non-zero exit code in the case or in the case of a fallen test test.OptionResultfn main()

Support in fn main()and has #[test]been implemented for a long time . However, support for documentation tests was limited to tests that were clearly present fn main().

This release adds full support ?for documentation tests. Now you can write this 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 indicate the type of error that will be used.

Support for custom token stream in user attributes

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

#[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)]. Racks 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, matching them according to macros. If you are the author of a procedural macro crate, please check if the lines are used in the syntax of your user attributes and whether they can be replaced with a stream of tokens.

TryFrom and TryInto

Traits TryFromand TryIntohave been stabilized to support type conversion errors.

For example, the from_be_bytesassociated methods of integer types receive an array, but the data is often read through slices. Manual conversion between slices and arrays is tedious. With new traits, this can be done on the same line as .try_into().

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

For conversions that cannot fail, such as u8in u32, a type is added Infallible. Due to this, it is TryFromautomatically implemented for everything that implements the trait From. In the future, we hope to Infalliblealias типа !(never) .

fn before_exec deprecated in favor unsafe fn pre_exec

On Unix-like systems, the function CommandExt::before_execallowed you to schedule a closure before a call 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 non- Copytype value in different processes, while the original would remain in the parent. This could lead to undefined behavior and break libraries that suggest the absence of duplication .

Therefore, the function before_execmust be marked unsafe. In this release, we have marked fn before_execobsolete in favor unsafe fn pre_exec. When CommandExt::pre_execyou call, you need to make sure that the closure does not violate the library invariants by creating invalid duplicates. If you provide a library that is in a similar before_execsituation, consider obsolescence and provide an alternative with unsafe.

Library stabilization

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

Nonzero unsigned integers, such as, were previously stabilized NonZeroU8. Due to this, it has the same size as . In this release, iconic versions are stabilized, for example .Optionu8NonZeroI8

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

Additionally, the following APIs have been stabilized:

See the detailed release notes for more details .

Also popular now: