Release Rust 1.12.1

We are pleased to introduce the new version of Rust 1.12.1. Rust is a system programming language aimed at the safe work with memory, speed and parallel code execution.

As usual, you can install Rust 1.12.1 from the corresponding page of the official site, or with the help of rustup by running the command rustup update stable .

What is included in the stable version 1.12.1

Wait a second ... one-point-twelve-point ... one?

A few weeks ago, in the announcement of version 1.12 , we said:

Release 1.12 is possibly the most significant since release 1.0.

And it is true. One of the important changes was a massive compiler refactoring. The new MIR backend has changed its architecture and some implementation details. In general, the modernization process was as follows:

• Initial MIR support appeared in the Rust 1.6 nightly builds.
• When the work was completed, the --enable-orbit compilation flag was added,
  so that the compiler developers could experience the new backend.
• Since October , we have always performed the MIR assembly, even if
  it was not used.
• The -Z orbit command line option has been added to allow users of nightly
  assemblies could try and use MIR instead of the compilation step 'trans'.
• After a long test for several months, for the version
  Rust 1.12, we made MIR the default backend .
• In Rust 1.13, only MIR will be available .

Such global changes are not easy and very important. Therefore, it is important to do everything correctly and carefully. That is why this process takes so long. We regularly test the compiler with each of the packages on crates.io, we ask users to check -Z orbit on their sources, and after six weeks of beta testing, there were no significant problems. Therefore, we decided to use the default MIR in version 1.12.

But big changes are always a risk, even though we tried to keep it to a minimum. And so, after the release of 1.12, regressions were found that we could not find during testing. Not all of them are related to MIR, simply, with such large-scale changes, errors are easily manifested in other places.

Why make an intermediate release?

Given that we have a six-week release cycle, and we are halfway to Rust 1.13, why did we decide to release a fix to version 1.12, and not to suggest users just wait for the next release? Earlier we said something similar: "intermediate releases will occur only in extreme cases, such as a vulnerability in the standard library."

We care not only about stability, but also about the usability of the language. We could tell all of you to wait, but we want you to know how serious we are. The release of the intermediate release, in this situation, is also a way to show our desire to correct errors as quickly as possible.

In addition, since we are not talking about security issues, this is a good reason to practice the release of intermediate releases. We have never done this before, and although the process of releasing a new version is partially automated , but not completely. The presence of an intermediate release will allow you to identify errors among other tools, such as rustup . And also make sure that everything goes according to plan, if we ever need it, to issue an emergency release due to security problems or for any other reason.

This is the first intermediate release of Rust after the release of Rust 0.3.1 , which happened in 2012, it marks 72 weeks since the release of Rust 1.0, when we adopted our six-week release cycle with strict guarantees of stability. And although we are very sorry that there are regressions in 1.12, we are proud of the stability of Rust and we will make every effort to make it a platform that we can rely on.

We want Rust to be the most reliable software development platform in the world.

Beta Testing Note

There is something that you, as a Rust user, can do to help us correct errors as early as possible: check your code using beta versions! Each beta release is a release candidate of the next stable version, so let's use continuous integration tools. So you can tell us about the problems before they get into a stable release! It is not difficult at all. For example, if you use Travis , add this to your .travis.yml :

 language: rust rust: - stable - beta 

And your tests will be executed for two versions of the compiler. In addition, if you do not want an error in the beta version to cause an error of the entire assembly, add this:

 matrix: allow_failures: - rust: beta 

A beta build may turn red, but your stable build will remain green.

Most other continuous integration systems, such as AppVeyor , should have this capability . Consult your system documentation.

Details

In version 1.12.1, nine errors were fixed; naturally, all these fixes were transferred to beta version 1.13.

• ICE: 'rustc' panicked with the message 'assertion failed: concrete_substs.is_normalized_for_trans ()' # 36381
• Confusion with double negation and logical variables
• rustc 1.12.0 ended with SIGSEGV when building a release for a syn 0.8.0 package
• Rustc 1.12.0 The Windows build of the ethcore package was interrupted with an LLVM error
• 1.12.0: A lot of memory was used when linking the release version with debug information
• Memory corruption after switching to 1.12
• "Let NullaryConstructor = something;" results in an internal compiler error: "tried to overwrite interned AdtDef"
• Fix ICE: inject bitcast if types mismatch for invokes / calls / stores
• debuginfo: Better spread_arg handling in MIR-trans.

In addition, there are four more regressions. We decided not to include them in 1.12.1 for various reasons, but we will try to eliminate them as soon as possible.

• Is ICE possibly associated with types of associated types?
• Error compiling a package using large static phf :: Map, on i686-pc-windows-gnu Beta
• Regression: error "no method found" when calling a method twice, with HRTB impl
• ICE: dummy sizing_type_of

The full list of changes between versions 1.12.0 and 1.12.1 is here .