
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 cargo
registries
Before version 1.0, Rust had a public registry, crates.io . People published racks with help cargo publish
and easily connected these racks in section [dependencies]
c 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 organization has a lot of closed source crates, you lose the benefits of versioning support, which is available 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, the crates.io 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.
[registries]
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 registry
so that Cargo knows that you want to receive the crate from the 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 ~/.cargo/credentials
using the command cargo login
:
cargo login --registry=my-registry
Next, you can use the flag --registry
to 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.Option
Result
fn 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 = "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 TryFrom
and TryInto
have been stabilized to support type conversion errors.
For example, the from_be_bytes
associated 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 u8
in u32
, a type is added Infallible
. Due to this, it is TryFrom
automatically implemented for everything that implements the trait From
. In the future, we hope to Infallible
alias типа !
(never) .
fn before_exec
deprecated in favor unsafe fn pre_exec
On Unix-like systems, the function CommandExt::before_exec
allowed 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- Copy
type 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_exec
must be marked unsafe
. In this release, we have marked fn before_exec
obsolete in favor unsafe fn pre_exec
. When CommandExt::pre_exec
you 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_exec
situation, 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 .Option
u8
NonZeroI8
Stabilized functions iter::from_fn
and 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() -> Option
from_fn(|| vec.pop())
Additionally, the following APIs have been stabilized:
- Any :: type_id
- Error :: type_id
- slice :: sort_by_cached_key
- str :: escape_debug
- str :: escape_default
- str :: escape_unicode
- str :: split_ascii_whitespace
- Instant :: checked_add
- Instant :: checked_sub
- SystemTime :: checked_add
- SystemTime :: checked_sub
See the detailed release notes for more details .