The Rust team is happy to announce the latest version of Rust, 1.12.1. Rust is a systems programming language with a focus on reliability, performance, and concurrency.

As always, you can install Rust 1.12.1 from the appropriate page on our website, or install via rustup with rustup update stable.

What's in 1.12.1 stable

Wait... one-point-twelve-point... one?

In the release announcement for 1.12 a few weeks ago, we said:

The release of 1.12 might be one of the most significant Rust releases since 1.0.

It was true. One of the biggest changes was turning on a large compiler refactoring, MIR, which re-architects the internals of the compiler. The overall process went like this:

• Initial MIR support landed in nightlies back in Rust 1.6.
• While work was being done, a flag, --enable-orbit, was added so that people working on the compiler could try it out.
• Back in October, we would always attempt to build MIR, even though it was not being used.
• A flag was added, -Z orbit, to allow users on nightly to try and use MIR rather than the traditional compilation step ('trans').
• After substantial testing over months and months, for Rust 1.12, we enabled MIR by default.
• In Rust 1.13, MIR will be the only option.

A change of this magnitude is huge, and important. So it's also important to do it right, and do it carefully. This is why this process took so long; we regularly tested the compiler against every crate on crates.io, we asked people to try out -Z orbit on their private code, and after six weeks of beta, no significant problems appeared. So we made the decision to keep it on by default in 1.12.

But large changes still have an element of risk, even though we tried to reduce that risk as much as possible. And so, after release, 1.12 saw a fair number of regressions that we hadn't detected in our testing. Not all of them are directly MIR related, but when you change the compiler internals so much, it's bound to ripple outward through everything.

Why make a point release?

Now, given that we have a six-week release cycle, and we're halfway towards Rust 1.13, you may wonder why we're choosing to cut a patch version of Rust 1.12 rather than telling users to just wait for the next release. We have previously said something like "point releases should only happen in extreme situations, such as a security vulnerability in the standard library."

The Rust team cares deeply about the stability of Rust, and about our users' experience with it. We could have told you all to wait, but we want you to know how seriously we take this stuff. We think it's worth it to demonstrate our commitment to you by putting in the work of making a point release in this situation.

Furthermore, given that this is not security related, it's a good time to practice actually cutting a point release. We've never done it before, and the release process is semi-automated but still not completely so. Having a point release in the world will also shake out any bugs in dealing with point releases in other tooling as well, like rustup. Making sure that this all goes smoothly and getting some practice going through the motions will be useful if we ever need to cut some sort of emergency point release due to a security advisory or anything else.

This is the first Rust point release since Rust 0.3.1, all the way back in 2012, and marks 72 weeks since Rust 1.0, when we established our six week release cadence along with a commitment to aggressive stability guarantees. While we're disappointed that 1.12 had these regressions, we're really proud of Rust's stability and will to continue expanding our efforts to ensure that it's a platform you can rely on. We want Rust to be the most reliable programming platform in the world.

A note about testing on beta

One thing that you, as a user of Rust, can do to help us fix these issues sooner: test your code against the beta channel! Every beta release is a release candidate for the next stable release, so for the cost of an extra build in CI, you can help us know if there's going to be some sort of problem before it hits a stable release! It's really easy. For example, on Travis, you can use this as your .travis.yml:

language: rust
rust:
  - stable
  - beta

And you'll test against both. Furthermore, if you'd like to make it so that any beta failure doesn't fail your own build, do this:

matrix:
  allow_failures:
    - rust: beta

The beta build may go red, but your build will stay green.

Most other CI systems, such as AppVeyor, should support something similar. Check the documentation for your specific continuous integration product for full details.

Full details

There were nine issues fixed in 1.12.1, and all of those fixes have been backported to 1.13 beta as well.

• ICE: 'rustc' panicked at 'assertion failed: concrete_substs.is_normalized_for_trans()' #36381
• Confusion with double negation and booleans
• rustc 1.12.0 fails with SIGSEGV in release mode (syn crate 0.8.0)
• Rustc 1.12.0 Windows build of ethcore crate fails with LLVM error
• 1.12.0: High memory usage when linking in release mode with debug info
• Corrupted memory after updated to 1.12
• "Let NullaryConstructor = something;" causes internal compiler error: "tried to overwrite interned AdtDef"
• Fix ICE: inject bitcast if types mismatch for invokes/calls/stores
• debuginfo: Handle spread_arg case in MIR-trans in a more stable way.

In addition, there were four more regressions that we decided not to include in 1.12.1 for various reasons, but we'll be working on fixing those as soon as possible as well.

• ICE, possibly related to associated types of associated types?
• Compilation of a crate using a large static map fails on latest i686-pc-windows-gnu Beta
• Regression: "no method found" error when calling same method twice, with HRTB impl
• ICE: fictitious type sizing_type_of

You can see the full diff from 1.12.0 to 1.12.1 here.