Bootstrapping unstable code from a stable compiler

[brson]

The stable Rust compiler requires the nightly Rust compiler to build. This is no good for distros that want to bootstrap from their own toolchain and don't want to maintain a nightly toolchain just for building Rust. We'll teach the Rust makefiles to deal with bootstrapping off the stable compiler transparently (the stable compiler already contains nightly features, just inaccessible).

https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767

[brson]

@eddyb may have some ideas abut this

[eddyb]

If distros don't have anything against multiple packages, they can generate, e.g. rustc-unstable-1.5 which has only a tiny wrapper script setting the appropriate env var.

Otherwise, we could put an "unlocked" rustc in $prefix/lib/rustlib/$triple/bin/rustc_driver and then install a wrapper script as $prefix/bin/rustc for stable releases, which passes --disable-unstable (with no flag to re-enable unstable features).

Then our build system can look for a compatible $prefix/lib/rustlib/$triple/bin/rustc_driver, and check whether it's actually compatible, and if so, use it.

[cuviper]

If we just relax the bootstrap key a little, and make it a statically-known value instead of a "secret", then there would be no need for wrapper scripts. The build system could just export that value applicable to stage0 invocations too.

As the configure script says itself, that secret is just meant to be a mild deterrent. By default it's only a %H:%M:%S timestamp -- that's easily grepped from strings librustc-*.so for a determined user. I think it would still be a good enough deterrent to be something fixed like "unsupported-rustc-bootstrap-mode". (Now that I say it, I guess each distro could choose their own fixed CFG_BOOTSTRAP_KEY already.)

A statically-known bootstrap key is not that different from an unlocked rustc_driver, deterrent-wise.

Aside, it might be nice if the resulting UnstableFeatures value showed up in debuginfo somewhere, perhaps in DW_AT_producer.

[SimonSapin]

Would this include cross-compiling std and friends to a target not in http://static.rust-lang.org/dist/rust-std-*.tar.gz? Even if I wanted to use Nightly for that, I’d have to guess which nightly works for building e.g. 1.5.0 stable.