Enable bootstrapping from previous-previous release

[brson]

Today rustc bootstraps from the previous release, and also from the current release. It would be useful though if it could bootstrap from the previous-previous release (e.g. 1.13 can be built from 1.11).

Consider that on a Linux distro that is keeping up with Rust releases, if you have their rustc package installed, you cannot build the Rust master branch with it.

It is not trivial to do this since bootstrapping requires unstable features, and those unstable features change periodically. It would probably require at least the following modifications:

• Changes to the build system to detect the previous-previous version and set the bootstrap key as appropriate
• New cfg values that indicate this scenario in order to get through the stage0 build
• New CI builders that tested this configuration explicitly

cc @glandium @alexcrichton

[nagisa]

This restricts compiler from using unstable features available in beta but not stable, which is sure to cause extra pain when developing certain advanced stuff.

[glandium]

Please note that the current scheme, where you need beta to build master, is equivalent to requiring llvm/clang >= 4 to build llvm 4.0 (as of writing, clang/llvm 3.9 was released two weeks ago).

As I've seen the argument here and there, I'll also debunk this one: sure, Go only guarantees version V can be built with version V - 1, but by the time version V is released, V - 1 is at least 6 months old, not 6 weeks old.

I guess the core problem is:

This is not trivial to do this since bootstrapping requires unstable features

[glandium]

Also note that the reason I was trying to build master with stable in the first place (and failed) was that I had a small issue (that, in the end, turned out to be already fixed anyways), and wanted to give it a shot. That was my first attempt to build the compiler at all (even though I actually contributed a patch already, but that was for jemalloc, I didn't need to build the compiler), and somehow I was expecting it would be easier. Although arguably, I shot myself in the foot trying to use --enable-local-rust, but I don't like that a build system downloads stuff (stage0) and runs it (without asking).

[brson]

This restricts compiler from using unstable features available in beta but not stable, which is sure to cause extra pain when developing certain advanced stuff.

Only in stage0 though.

[arielb1]

The problem is that the standard library is pretty specific to the compiler version. This would force it to have #[cfg(rustc_version = "1.11")] and #[cfg(rustc_version = "1.12")] instead of #[cfg(stage0)].

Maybe that is a good thing, through.

rustc itself is pretty compiler-independent - it should compile on every reasonably-modern rustc.

[alexcrichton]

I'd feel a little uneasy about having two sets of #[cfg] in the standard library for bootstrapping (one for each of the two previous releases we'd claim to bootstrap from). That implies yet more CI coverage for what seems to be marginal benefit?

[alexcrichton]

Done!

[alexcrichton]

Oh wait, misread