Editor: Zhang Handong

Rust 1.54 is a stable release

Rust 1.54 doesn’t update many features, but it’s worth noting that:

  1. Incremental compilation is enabled again by default.
  2. There is an extra OutOfMemory type in ErrorKind.

Blog.rust-lang.org/2021/07/29/…

task::ready! Macro will be stable at 1.56

Futures – core ready! The () macro has been around for a few years and can reduce a lot of template code when dealing with futures.

ready! The () macro will be stabilized later in the STD ::task module.

Github.com/rust-lang/r…

Rust 2021 is in public beta

Rust 2021 is in public beta. All of the planned features of this release are now available to experience first in the Nightly release. It also provides a convenient migration method to quickly migrate code from Rust 2018 to Rust 2021.

  • Install the nearest Nightly toolchain:rustup update nightly 。
  • runcargo +nightly fix --edition 。
  • The editorCargo.tomlThat will becargo-features = ["edition2021"]At the top (at[package]Above) and willeditionInstead ofedition = "2021" .
  • runcargo +nightly checkTo see if it works on the new version.

The Datafuse team is currently experimenting with Rust 2021 migration. For more information, see github.com/datafuselab…

Rust 2021 Public Testing Period: blog.rust-lang.org/2021/07/21/…

The Nightly Version of Rust Edition Guide: doc.rust-lang.org/nightly/edi

The MCP for rustc_codegen_gcc has been accepted

Rust will have an additional GCC back end in the near future.

Similar projects include gCC-RS, a GCC front-end that reimplements Rustc with Cpp.

Why is gCC-RS a project?

  1. Want to support more CPU architectures
  2. Cross-language LTOS. The GCC-RS FAQ lists Linux as an incentive example. Ironically, Linux supports LTVM but not GCC!
  3. The Rust Bootstrap chain is long because you need to go from C to OCAML and then compile the pre-release Rust to compile Rust 1.0 to compile Rust 1.1, 1.2, etc until you capture up to 1.53 (or the latest version). So you can save some time if you can compile 1.53 directly with the Rust compiler written in C++.
  4. Reuse GCC plug-ins

But the author of Rustc_codegen_gcc thinks that gCC-RS does not solve these problems well.

The rustc_codegen_gcc project can achieve these goals simply by plugging GCC into the existing Rust compiler as the code generation back end.

The main goal of the project is to be able to compile Rust code on platforms not supported by LLVM. The secondary goal is to check whether any compile-speed improvements are provided using the GCC back end.

Now that rustc_codegen_gcc has been accepted, where does gcc-RS go from here?

Related: Rust with open source | problems caused by the GPL license

Will GAT (Generic Associated Types) be stable this year? Ok for me.

Four days ago, someone replied under GAT Tracking Issues:

excerpts

I expect we will have stabilisation probably around October; But it does depend on the 1-3 month testing period. If the test ends relatively error-free, it should go well. If some serious errors, design flaws, etc. are found, this may be delayed by a few months, but it still provides some leeway for the end of the year.

I encourage you to test the features.

Details: github.com/rust-lang/r…

Progress report of the error handling Working Group

The Official Error Handling Working Group has released a new article describing the main challenge that needs to be addressed in current error handling: the tendency to lose context.

Here are some excerpts:

use std::fmt;

// A configuration file needs to be loaded and the configuration load is always expected to be successful.
fn main() {
    let _config = load_config()
        .expect("config is always valid and exists");
}

// Here we implement an example where loading a configuration file is always an error because the error diagnosis information is displayed
fn load_config() - >Result<(), Error> {
    Err(Error(SourceError))
}

// We have an error type, just print "invalid Config"
// And has a print-only source error "Config file does not exist"
#[derive(Debug)]
struct Error(SourceError);

impl fmt::Display for Error {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.write_str("invalid config")}}impl std::error::Error for Error {
    fn source(&self) - >Option"The & (dyn std::error::Error + 'static) > {Some(&self.0)}}#[derive(Debug)]
struct SourceError;

impl fmt::Display for SourceError {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.write_str("config file does not exist")}}impl std::error::Error for SourceError {}
Copy the code

The error message we want to get is as follows:

$ cargo run
thread 'main' panicked at 'config is always valid and exists', src/main.rs:4:33

Error:
    0: invalid config
    1: config file does not exist

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Copy the code

With this information, we can see that the program exits because a panic occurred. We can see that there are two causes of panic that violate 0 and 1, and we can locate where the panic is occurring.

But the current actual output is:

$ cargo run
thread 'main' panicked at 'config is always valid and exists: Error(SourceError)', main.rs:4:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Copy the code

Rust’s panic infrastructure does not provide a way to convert Error types to panic, it only supports converting Debug types to PANIC, which we feel is a big problem. Similarly, the language does not provide a convenient tool to print error messages for an error and all of its sources.

When we deal with Result:

fn main() {
    let result = load_config();
    let _config = match result {
        Ok(config) => config,
        Err(error) => {
            println!("Error: {}", error);
            return; }}; }Copy the code

We hope to obtain:

$ cargo run
Error: invalid config: config file does not exist
Copy the code

But the actual output:

$ cargo run
Error: invalid config
Copy the code

By default, all error information from the source is lost. This is because we use Display as the interface for a single error message. If we could go back in time, we would currently recommend adding the FN message(&self, f: &mut FMT ::Formatter<‘_>) -> FMT ::Result to the Error trait, but for now that ship has sailed.

Today, the solution to this problem in libraries is to abuse Debug traits. Types such as Eyre, Anyhow, and sometimes even custom error enumerations use their Debug output to print all the error chains in the human-readable report.

The benefit of this is that it makes it easy to print full error reports, and that unwrap, Expect, and the return from main all print full error reports. But doing so prevents us from accessing the wrong Derive Debug format, potentially hiding the internal details that debugging might require, but which are not part of the error message for the user to read.

The future of error handling

Ultimately, we want the default tools you use for Error handling in Rust to do the right thing and take full advantage of the Error trait design. Unwrap a type that implements the Error trait will retain the original Error as a dynamic Error, which can then be used in panic hooks. Printing a full error report would be easy and obvious. With these changes, it is hoped that it will be difficult to accidentally discard information when an error is reported.

To achieve this goal, there is a two-step plan:

  1. Integrate Error Trait and Panic Runtime.

    A. Move the Error trait to core b. Add an interface to create a panic from the Error type, such as the panic_error function. This is similar to the panic_any function already available in STD. This function will let the panic handler access the Error via dyn Error. C. Update the default panic hook provided by STD to actually report panic via the Error trait. It should traverse the source and print the tracebacks caught by the error itself, if any, or perhaps catch one itself. D. Finally, we need special treatment for Expect and unwrap to use these new error-panicked interfaces for types unwrap that implement the Error trait. To do this, we first need to solve the health problem of professionalizing trait Impls for lifetime-based conditions, but fortunately we have a good solution.

  2. Implement a basic error reporting tool.

    We can’t quite get there because we use Display to handle individual error messages, and we can’t change this in a backwards compatible way, but we’d like to add a handy way to print the full error chain and some clever prose to take most of the pressure off.

    We plan to solve this problem by adding a Report type to the library that wraps an &dyn Error and implements Display so that it prints each source as required. We wanted the output of Report’s display method to support the most common style of error concatenation in the Rust ecosystem.

    println!("Error: {}", Report::from(error));

// Outputs:
// Error: outermost error: second error: root error

println!("Error: {:#}", Report::from(error))

// Outputs:
// Error: outermost error
//
// Caused by:
// 0: second error
// 1: root error

// The report method looks something like this
fn report(&self) - >impl Display + '_
where
    Self: Sized,
{
    Report::from(self)}Copy the code

  3. The Error handling Working Group recently created a guideline on how to implement Display:: FMT and Error::source. This advice only applies to error types that are exposed as part of the library’s API. Internal bugs in a library or application can do whatever they want, but once they need to be integrated into other sections by third-party users, it’s important that bugs follow a consistent style. If you’re interested in our reasoning or have any comments, please check out our Github question on this topic: Rust-lang/ project-Error-Handling #27.

That’s the plan at the moment, it’s not a complete plan of all the changes we want to make, but we think it’s the best first step.

Disclaimer: This article is a combination of plans and wishes. There are some technical challenges that need to be addressed, so the end result may be very different from what we originally imagined, so please don’t assume that these are all final results.

Blog.rust-lang.org/inside-rust…

Cargo – Supply-Chain: A new tool released by the Official Security Code Working Group

Function:

Collect authors, contributors, and publishers crate data in the dependency package diagram.

Usage scenario:

  • Find people and groups to support.
  • Identify risks in dependency diagrams.
  • Analyze all the contributors you implicitly trust by building their software. This can have a sobering and humbling effect.

Cargo – Supply – Chain itself provides an output sample: Publishers, Crates, JSON.

Usage:

cargo install cargo-supply-chain
Copy the code

There is another tool within the organization: Freight-Geiger. You can detect the use of Unsafe rust in Crate and its dependency. Also available is the Rust item’s security check ratio.

Related links:

  • Secure Code Working Group website
  • Secure Code Workgroup organized at GitHub
  • cargo-supply-chain
  • cargo-geiger

Float types have been incorporated into the Rust Core library to make Rust resolve faster

The authors proposed how Rust resolves float faster and more securely two years ago, but these changes were recently incorporated into libcore.

This means that when you parse a large number of float types, you get a dramatic performance boost.

Such as:

  • 0.06, 0.13, 0.25, 0.38, 0.44, 0.44, 0.38, 0.44, 0.5, 0.56 the figures will probably increase 2 times.

  • 65.613616999999977, 43.420273000000009, 65.619720000000029, 43.418052999999986, 65.625, 43.421379000000059 this data will enhance about 10 times Performance.

  • 8.988465674311580536566680 e307 this data will probably improve the ascension of 1600 ~ 10000 times.

  • Github.com/rust-lang/r…

  • Correlation Algorithm

RFC 3128: I/O Safety

Rust now has an adopted I/O secure RFC. This RFC handles the lifecycle of file operators, sockets, etc. This makes it possible to write lower-level secure system objects.

Github.com/rust-lang/r…

Rustc_codegen_gcc Progress Report #2

Rustc_codegen_gcc is the GCC code for RustC, which means it can be loaded by the existing RustC front-end, benefiting GCC by supporting more architectures and GCC optimizations.

Current state: Antoyo implements popCount manually (because GCC produces a call to some function, which would not work in no-STD). In addition, fixes were made to make it easier to add this GCC code in Godbolt and to incorporate this PR of Antoyo into RustC.

For details of report #2, see The link to Antoyo’s blog, blog.antoyo.xyz/rustc_codeg…