Repository navigation
x.py fails if both --verbose and --incremental options are used #42907
Description
Running
x.py build --verbose --incremental --stage 1
fails with an error message like the following:
...
error: Could not compile `rustc_back`.
Caused by:
failed to parse process output: `/home/ed/tmp/rust/build/bootstrap/debug/rustc --crate-name rustc_back src/librustc_back/lib.rs --error-format json --crate-type dylib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 --cfg feature="jemalloc" -C metadata=65e32f1bbc857eb6 -C extra-filename=-65e32f1bbc857eb6 --out-dir /home/ed/tmp/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/home/ed/tmp/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/ed/tmp/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps --extern syntax=/home/ed/tmp/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libsyntax-f9f4ca8739c9e54f.so --extern serialize=/home/ed/tmp/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-d8a8039e1b670a9d.so --extern serialize=/home/ed/tmp/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-d8a8039e1b670a9d.rlib --extern log=/home/ed/tmp/rust/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/liblog-065dbad889dc18a2.rlib` (exit code: 0)
--- stdout
incremental: 89103 nodes in dep-graph
incremental: 298837 edges in dep-graph
incremental: 31879 nodes in reduced dep-graph
incremental: 189075 edges in serialized dep-graph
incremental: 10194 hashes in serialized dep-graph
incremental: re-using 0 out of 141 modules
Caused by:
compiler stdout is not empty: `incremental: 89103 nodes in dep-graph`
...
It seems like the messages that incremental (verbose) compiling prints about the dep-graph are confusing something that expects stdout to be empty?
Activity
Mark-Simulacrum commentedon Jun 26, 2017
I believe this should be fixed if you pull down master, but if not, we may have to backport #42821 to beta, not sure. cc @alexcrichton
alexcrichton commentedon Jun 26, 2017
I think
--incrementalis unstable enough we probably don't want to backport, but yes this should be fixed on master.edmccard commentedon Jun 26, 2017
This happened to me using a fresh clone of Rust that I made yesterday (at commit bc9822), and #42821 seems to be from 4 days ago -- do I also need to have the latest nightly installed when building Rust? I thought the bootstrap process used its own stage0 (separate from any normal rust installation) to build stage1?
Mark-Simulacrum commentedon Jun 26, 2017
We normally use the last beta (currently 2017-06-15) to bootstrap. However, you can configure using
cargo =andrustc =to, for example, nightly versions of the compiler. That's mostly recommended anyway since nightly is likely to have (over time, anyway, if not currently to my knowledge) slightly better incremental.edmccard commentedon Jun 26, 2017
It works when specifying nightly cargo and rustc in config.toml, so I'll close.