Announcing Rust 1.16

The Rust team is happy to announce the latest version of Rust, 1.16.0. Rust is a systems programming language focused on safety, speed, and concurrency.

If you have a previous version of Rust installed, getting Rust 1.16 is as easy as:

$ rustup update stable

If you don’t have it already, you can
get rustup

from the appropriate page on our website, and check out the detailed release notes for 1.16.0
on GitHub.

What’s in 1.16.0 stable

The largest addition to Rust 1.16 is cargo check
. This new subcommand should speed up the development workflow in many cases.

What does it do? Let’s take a step back and talk about how rustc
compiles your code. Compilation has many “passes”, that is, there are many distinct steps that the compiler takes on the road from your source code to producing the final binary. You can see each of these steps (and how much time and memory they take) by passing -Z time-passes
to a nightly compiler:

rustc -Z time-passes
time: 0.003; rss: 16MB  parsing
time: 0.000; rss: 16MB  recursion limit
time: 0.000; rss: 16MB  crate injection
time: 0.000; rss: 16MB  plugin loading
time: 0.000; rss: 16MB  plugin registration
time: 0.049; rss: 34MB  expansion

There’s a lot of them. However, you can think of this process in two big steps: first, rustc
does all of its safety checks, makes sure your syntax is correct, all that stuff. Second, once it’s satisfied that everything is in order, it produces the actual binary code that you end up executing.

It turns out that that second step takes a lot of time. And most of the time, it’s not neccesary. That is, when you’re working on some Rust code, many developers will get into a workflow like this:

  1. Write some code.
  2. Run cargo build
    to make sure it compiles.
  3. Repeat 1-2 as needed.
  4. Run cargo test
    to make sure your tests pass.
  5. GOTO 1.

In step two, you never actually run your code. You’re looking for feedback from the compiler, not to actually run the binary. cargo check
supports exactly this use-case: it runs all of the compiler’s checks, but doesn’t produce the final binary.

So how much speedup do you actually get? Like most performance related questions, the answer is “it depends.” Here are some very un-scientific benchmarks:

initial build initial check speedup secondary build secondary check speedup
thanks 134.75s 50.88s 2.648 15.97s 2.9s 5.506
cargo 236.78s 148.52s 1.594 64.34s 9.29s 6.925
diesel 15.27s 12.81s 0.015 13.54s 12.3s 1.100

The ‘initial’ categories are the first build after cloning down a project. The ‘secondary’ categories involved adding one blank line to the top of
and running the command again. That’s why the initial ones are more dramatic; they involve also doing this for all dependencies, as well as the crate itself. As you can see, larger projects with many dependencies see a big improvement, but smaller ones see much more modest gains.

We are still working on improving compile-times generally as well, though we don’t have anything in particular to highlight at this time.

Other improvements

To support cargo check
, rustc
has learned to emit
a new kind of file: .rmeta
. This file will contain only the metadata about a particular crate. cargo check
needs this for your dependencies, to let the compiler check types and such from them. It’s also useful for the Rust Language Server
, and possibly more tools in the future.

Another large change is the removal of a long-standing diagnostic: consider using an explicit lifetime parameter
. This diagnostic would kick in whenever you had an incorrect lifetime annotation, and the compiler thought that you might have meant something else. Consider this code:

use std::str::FromStr;

pub struct Name {
    name: &'a str,

impl FromStr for Name {
    type Err = ();

    fn from_str(s: &str) -> Result {
        Ok(Name { name: s })

Here, Rust isn’t sure what to do with the lifetimes; as written, the code doesn’t guarantee that s
will live as long as Name
, which is required for Name
to be valid. Let’s try to compile this code with Rust 1.15.1:

> rustc +1.15.1 --crate-type=lib
error[E0495]: cannot infer an appropriate lifetime for lifetime parameter in generic type due to conflicting requirements
10 |       fn from_str(s: &str) -> Result {
   |  _____^ starting here...
11 | |         Ok(Name { name: s })
12 | |     }
   | |_____^ ...ending here
help: consider using an explicit lifetime parameter as shown: fn from_str(s: &'a str) -> Result
10 |       fn from_str(s: &str) -> Result {
   |  _____^ starting here...
11 | |         Ok(Name { name: s })
12 | |     }
   | |_____^ ...ending here

The compiler explains the issue, and gives a helpful suggestion. So let’s try it: modify the code to add in the 'a
, and compile again:

> rustc +1.15.1 --crate-type=lib
error[E0308]: method not compatible with trait
10 |       fn from_str(s: &'a str) -> Result {
   |  _____^ starting here...
11 | |         Ok(Name { name: s })
12 | |     }
   | |_____^ ...ending here: lifetime mismatch

help: consider using an explicit lifetime parameter as shown: fn from_str(s: &'a str) -> Result<name, ()>
10 |       fn from_str(s: &'a str) -> Result {
   |  _____^ starting here...
11 | |         Ok(Name { name: s })
12 | |     }
   | |_____^ ...ending here</name

It still doesn’t work. That help message was not actually helpful. It does suggest adding another lifetime, this time on Name
. If we do that…

> rustc +1.15.1 --crate-type=lib

help: consider using an explicit lifetime parameter as shown: fn from_str(s: &'a str) -> Result<name, ()>

… that’s what we already have, compiler!

This diagnostic was well-intentioned, but when it’s wrong, it was very
wrong, as you can see here. Sometimes it wouldn’t even suggest valid Rust syntax! Furthermore, more advanced Rust users didn’t really need the suggestion, but new Rustaceans would take them to heart, and then be led down this bad path. As such, we decided that for now, we should remove the help message entirely
. We may bring it back in the future, but only if we can limit false positives.

In other diagnostic changes, previous versions of Rust would helpfully attempt to suggest fixes for typos:

let foo = 5;

println!("{}", ffo);

Would give this error:

error[E0425]: cannot find value `ffo` in this scope
4 |     println!("{}", ffo);
  |                    ^^^ did you mean `foo`?

However, this would only happen in certain circumstances: sometimes in local variables, and for fields in structs. This now happens nearly everywhere
. When combined with some other related improvements
, this results in a significant improvement in these sorts of diagnostics.

See the detailed release notes
for more.

Library stabilizations

21 new bits of API were stabilized this release:

In addition, a number of small improvements to existing functions landed. For example
now has a single-argument form

, just like println!
has. This ends up writing only a newline, but is a nice bit of symmetry.

All structs in the standard library
now implement Debug


When slicing a &str
, you’ll see better errors
. For example, this code:


Is incorrect. It generates this error:

thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not
a char boundary; it is inside 'α' (bytes 3..5) of `abcαβγ`'

The part after the ;
is new.

See the detailed release notes
for more.

Cargo features

In addition to cargo check
, Cargo and have some new polish added. For example,
cargo build

cargo doc

now take a --all
flag for building and documenting every crate in your workspace with one command.

Cargo now has a
--version --verbose

, mirroring rustc
. now can show off your TravisCI or AppVeyor badges
on your crate’s page.

In addition, both Cargo and understand categories
. Unlike keywords, which are free-form, categories are curated. In addition, keywords are used for searching, but categories are not. In other words, categories are intended to assist browsing, and keywords are intended to assist searching.

You can browse crates by category here

See the detailed release notes
for more.

Contributors to 1.16.0

Last release, we We have been doing some behind-the-scenes refactoring work to allow for more projects than only Rust itself; we’re hoping to introduce that in the next release.

We had 137 individuals contribute to Rust 1.16.Thanks!

The Rust Programming Lang Blog稿源:The Rust Programming Lang Blog (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合编程 » Announcing Rust 1.16

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录


忘记密码 ?