Focus on official Rust activities and news
Rust 1.56.0 and Rust 2021 are released, marching towards the journey of widespread application of Rust
Upgrade or installation of Rust 1.56.0 and Rust 2021
If you already have an earlier version of Rust installed through Rustup, updating to Rust 1.56.0 is fairly easy:
$ rustup update stable
Copy the code
If you have not already installed Rust, you can obtain Rustup from the Rust website page.
New features
Rust 1.56.0 and Rust 2021 are minor upgrades, with the following new features:
- Closure capture improvements: Refer directly to the following example.
// 2015 or 2018 edition code
let a = SomeStruct::new();
// Move out of one field of the struct
drop(a.x);
// Ok: Still use another field of the struct
println!("{}", a.y);
// Error: Before 2021 edition, tries to capture all of `a`
let c = || println!("{}", a.y);
c();
Copy the code
- Array iterator
IntoIterator
:array.into_iter()
It is now iterated by item value instead of by reference. - Or mode in macros 即
:pat
In theA|B
. - Cargo’s new default parsing feature, ResolverThe default is now 2. That is, after Rust 1.51.0, explicitly set to
Cargo.toml
In theresolver = "2"
, can be deleted. - The prelude of the collection: Added by default
TryInto
,TryFrom
, as well asFromIterator
. - Panic macroThe expected output is in string format, as in
println! (a)
. - The reserved grammar:
ident#
,ident"..."
, as well asident'... '
. - warnings -> errors: Mainly involved
bare_trait_objects
和ellipsis_inclusive_range_patterns
.
Migrate existing projects to Rust 2021
- run
cargo fix --edition
- The editor
Cargo.toml
Set,edition = "2021"
. Such as:
[package]
name = "..."
version = "0.0.1".edition = "2021".Copy the code
Blog.rust-lang.org/2021/10/21/…
New members focus | : why do you want to join the Rust Rust foundation foundation
Here are excerpts from regular interviews with new members of the Rust Foundation.
See: new members focus | : why do you want to join the Rust Rust foundation foundation
A practical Rustdoc improvement has just been incorporated in NIGHTLY
#[CFG ()] information will now appear in the document (#[doc(CFG ())]! Is no longer required by default).
Github.com/rust-lang/r…
P.S. Rustdoc Team leader Guillaume Gomez will share at RustChinaConf 2021
Rust Lang Team updated in October
This week the Lang team held a planning meeting for October, which covered the following:
-
Async, which plans to stabilize MVP versions of asynchronous functions in traits.
-
The Impl trait, type Foo = Impl trait feature has made some progress
-
Dyn Upcasting is making good progress and needs to resolve a soundness issue before merging.
-
Generic association types are also making some progress.
-
other
-
Blog.rust-lang.org/inside-rust…
Sustainable growth and visibility of Rust ecology
The long-term health of the Rust ecosystem is important, and ensuring it requires us not only to grow over time, but also to ensure that we can scale appropriately. Achieving this goal means ensuring that key parts of our ecosystem are “staffed” and self-sustaining, and that no maintenance staff is burned out.
Crucially, people are not computers. For one person, that unacceptable commitment can quickly drain their energy, while others may thrive on it. Different code bases have different requirements for what “in health” means. But having more information and specific numbers to guide us to more targeted questions will help us spot burnout early and help us spot problems (and things that are going well!) earlier. .
So the official tool Optopodi was created. Optopodi is a pilot project to begin collecting metrics about the Github organization and repository.
The goal is to understand various “open source health” style metrics such as:
- Which repositories are most active?
- Who is contributing to them?
- How long does it take to get a review?
Ultimately, we want to use this data to help projects and contributors achieve greater success.
Official long-term goals:
Is to make the tool a fully automated service for the common dashboard. I want to be able to examine the state of the ecosystem at a glance and have everyone see the same data I’m looking at. I want to be able to know when contributors are at risk of burnout and prevent it. I wanted to make sure that the contributors’ “quality of service” was high, if it wasn’t resolved, and to be able to verify that our changes were having the desired effect. I hope we can see clearly the effects of our actions. I hope we don’t have any doubts about whether we’re doing the right thing. I hope we have concrete evidence.
Having this information not only allows the project to guide our work, but also allows us to do it early, because we can spot potential problems before the maintainer feels them. Increasing the number of knowledge contributors participating in key libraries helps each contributor to these projects. Pr and issues will have a faster turnaround time. Making this information public also allows others to independently assess our health.
Estebank. Making. IO/sustainable…