bootstrap: artifacts are not moved to build/:target/stage1 on `x.py build --stage 0`

[jyn514]

I've lost so much of my life to this.

$ xpy build --stage 0
Updating only changed submodules
Submodules updated in 0.01 seconds
    Finished dev [unoptimized] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized + debuginfo] target(s) in 0.11s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized + debuginfo] target(s) in 0.12s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Build completed successfully in 0:00:01
$ rustc +stage1 -Z unpretty=everybody_loops priv-in-pub.rs 
error: 'rustc' is not installed for the toolchain 'stage1'
To install, run `rustup component add rustc --toolchain stage1`
$ xpy build --stage 1
Updating only changed submodules
Submodules updated in 0.01 seconds
    Finished dev [unoptimized] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized + debuginfo] target(s) in 0.11s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized + debuginfo] target(s) in 0.12s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
   Compiling cc v1.0.54
   Compiling core v0.0.0 (/home/joshua/src/rust/src/libcore)
   Compiling libc v0.2.71
   Compiling autocfg v0.1.7
   Compiling std v0.0.0 (/home/joshua/src/rust/src/libstd)
   Compiling hashbrown v0.6.2
^C  Building [=====>                                                    ] 4/35: ...
Build completed unsuccessfully in 0:00:02
$ rustc +stage1 -Z unpretty=everybody_loops priv-in-pub.rs 
#![no_std]
// ... expected output follows ...
$ rustup toolchain list -v
stage1	/home/joshua/src/rust/build/x86_64-unknown-linux-gnu/stage1

It looks like the critical missing line is Assembling stage1 compiler (x86_64-unknown-linux-gnu). I would expect this to happen whenever I pass build --stage 0.

[jyn514]

The part of bootstrap emitting Assembling ... is Assemble, which is called by bootstrap/builder.rs:compiler_for. The bit emitting 'Copy ...' is RustcLink. Notably, RustcLink does not call Assemble.

[jyn514]

This does not fix the issue and I'm not sure why:

$ git diff src/bootstrap/
diff --git a/src/bootstrap/compile.rs b/src/bootstrap/compile.rs
index c09b73b0420..630f9ecbe25 100644
--- a/src/bootstrap/compile.rs
+++ b/src/bootstrap/compile.rs
@@ -589,6 +589,7 @@ impl Step for RustcLink {
             &builder.sysroot_libdir(target_compiler, compiler.host),
             &librustc_stamp(builder, compiler, target),
         );
+        builder.ensure(Assemble { target_compiler });
     }
 }

[jyn514]

It looks like bootstrap mistakenly thinks that the compiler has been linked and is cached.

c Assemble { target_compiler: Compiler { stage: 0, host: "x86_64-unknown-linux-gnu" } }

[jyn514]

So this is still a bug, but it turns out it wouldn't do what I want anyway because it doesn't build libcore. So it would only be able to build crates with #![no_core] (basically nothing).

[Mark-Simulacrum]

Yeah you want something like build --stage 1 src/libcore (though we don't support separate crate builds currently, but we could).

I think it's not possible today to get bootstrap to copy the compiler but not build anything with it - the compiler itself isn't considered an artifact in some sense.

[jyn514]

I think it's not possible today to get bootstrap to copy the compiler but not build anything with it - the compiler itself isn't considered an artifact in some sense.

Right, this issue is asking that to change. I think this would still be useful for what I'm doing now which is only printing the AST and not even doing name resolution (-Z unpretty=everybody_loops).