x.py fails if both `--verbose` and `--incremental` options are used

[edmccard]

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?

[Mark-Simulacrum]

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]

I think --incremental is unstable enough we probably don't want to backport, but yes this should be fixed on master.

[edmccard]

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]

We normally use the last beta (currently 2017-06-15) to bootstrap. However, you can configure using cargo = and rustc = 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]

It works when specifying nightly cargo and rustc in config.toml, so I'll close.