Change:
See . Unfortunately the "fix" to that bug breaks the build when building using 1.31.0 and you have to unapply the patch to make it work against 1.31.0. e.g. from : ~ The problem here is that if stage0 is 1.31.0 then the patch MUST be unapplied, if stage0 is 1.32.0 then the patch MUST be applied. Obviously we can't do both at once. However in both Debian and Fedora we occasionally use either the current or the previous version of rustc to build a given version of rustc, and both of these versions should work. cc
Doing things this way (using stage2) would also have ensured that was detected early, and never made it into a release.
We would prefer to build tools such as compiletest with the bootstrap compiler because stage1, stage2 compilers take a long time to build. I think largely we just can't at this point support building with multiple compilers -- i.e., the bootstrap compiler should be the same one we use in tree. We just don't have the CI budget and resources to test and support multiple versions of the compiler for crates using unstable features. As such, I think the only resolution here will be to close this... cc and though since this is somewhat of a policy type decision (and we don't have a firm policy AFAIK).
As a matter of policy, we do need such rebuild-bootstrapping to continue to be supported to some extent, even if it's only a "tier-2" use case. That is, fixing these sort of issues reactively is still better than nothing.
Is conditional compilation based on the compiler version possible in Rust today? That could be an alternative solution, instead of always using stage2. The language is a bit technical and I couldn't figure it out.
I guess for now, I could hack that sort of logic into the Debian build script manually in an ad-hoc way - applying the patch vs not, based on the stage0 compiler version.
I think if we wanted to solve this issue the best way to do it would be to: Require compiles on stable, except for the dependency on the crate Have depend on std/test in-tree binaries, so we always build them (with the stage0 compiler) That way works with rebuild-bootstraping and normal use cases because it's not using anything unstable except libtest, which is built from source to link against and already solves this problem otherwise.
I think in general a policy of unstable tools/dependencies having the requirement of being in-tree deps instead of beta is reasonable, yeah. I can try to make a patch that makes compiletest (and if there are any other such tools) do this sometime this week.
Same issue with 1.40.0 again, when using itself as stage0: ~ CC AFAICT you do not have a patch that fixes this on Fedora either.
For 1.40.0 the relevant commit to conditionally-apply or not is . For the upcoming 1.41.0 (or is it 1.42.0) stable release it seems we will have to do the same thing for .

Discussion:
macro_rules! bootstrap_tool { ($( $name:ident, $path:expr, $tool_name:expr <del> $(,llvm_tools = $llvm:expr)* </del> $(,is_external_tool = $external:expr)* <ins> $(,is_unstable_tool = $unstable:expr)* </ins> $(,features = $features:expr)* ; )+) => {

)+ } <del> impl Tool { /// Whether this tool requires LLVM to run pub fn uses_llvm_tools(&self) -> bool { match self { $(Tool::$name => false $(|| $llvm)*,)+ } } } </del> impl<'a> Builder<'a> { pub fn tool_exe(&self, tool: Tool) -> PathBuf { match tool {

compiler: self.compiler, target: self.target, tool: $tool_name, <del> mode: Mode::ToolBootstrap, </del> <ins> mode: if false $(|| $unstable)* { // use in-tree libraries for unstable features Mode::ToolStd } else { Mode::ToolBootstrap }, </ins> path: $path, is_optional_tool: false, source_type: if false $(|| $external)* {

Tidy, "src/tools/tidy", "tidy"; Linkchecker, "src/tools/linkchecker", "linkchecker"; CargoTest, "src/tools/cargotest", "cargotest"; <del> Compiletest, "src/tools/compiletest", "compiletest", llvm_tools = true; </del> <ins> Compiletest, "src/tools/compiletest", "compiletest", is_unstable_tool = true; </ins> BuildManifest, "src/tools/build-manifest", "build-manifest"; RemoteTestClient, "src/tools/remote-test-client", "remote-test-client"; RustInstaller, "src/tools/rust-installer", "fabricate", is_external_tool = true;

#![crate_name = "compiletest"] <del> #![feature(test)] </del> #![deny(warnings)] <ins> // The `test` crate is the only unstable feature // allowed here, just to share similar code. #![feature(test)] </ins> extern crate test;