rustc-1.27.1 build fails with extended = true

[djc]

With this configuration:

[llvm]
optimize = true
release-debuginfo = false
assertions = false
targets = "X86"
[build]
build = "x86_64-unknown-linux-gnu"
host = ["x86_64-unknown-linux-gnu"]
target = ["x86_64-unknown-linux-gnu"]
cargo = "/var/tmp/portage/dev-lang/rust-1.27.1/work/rust-stage0/bin/cargo"
rustc = "/var/tmp/portage/dev-lang/rust-1.27.1/work/rust-stage0/bin/rustc"
docs = false
submodules = false
python = "python3.5"
locked-deps = true
vendor = true
verbose = 2
extended = true
tools = ["rustfmt","cargo",]
[install]
prefix = "/usr"
libdir = "lib64"
docdir = "share/doc/rust-1.27.1"
mandir = "share/rust-1.27.1/man"
[rust]
optimize = true
debuginfo = false
debug-assertions = false
use-jemalloc = true
default-linker = "x86_64-pc-linux-gnu-gcc"
rpath = false
lld = false
[target.x86_64-unknown-linux-gnu]
cc = "x86_64-pc-linux-gnu-gcc"
cxx = "x86_64-pc-linux-gnu-g++"
linker = "x86_64-pc-linux-gnu-gcc"
ar = "x86_64-pc-linux-gnu-ar"

Which fails like this:

error[E0432]: unresolved import `syntax::abi`
--
  | --> tools/miri/miri/fn_call.rs:7:13
  | \|
  | 7 \| use syntax::abi::Abi;
  | \|             ^^^ Could not find `abi` in `syntax`
  |  
  | error[E0616]: field `start` of struct `std::ops::RangeInclusive` is private
  | --> tools/miri/miri/fn_call.rs:52:57
  | \|
  | 52 \|                     let niche_value = ((variant_index - niche_variants.start) as u128)
  | \|                                                         ^^^^^^^^^^^^^^^^^^^^
  | \|
  | = note: a method `start` also exists, perhaps you wish to call it
  |  
  | error[E0308]: match arms have incompatible types
  | --> tools/miri/miri/fn_call.rs:178:25
  | \|
  | 178 \|           let link_name = match attr::first_attr_value_str_by_name(&attrs, "link_name") {
  | \|  _________________________^
  | 179 \| \|             Some(name) => name.as_str(),
  | 180 \| \|             None => self.tcx.item_name(def_id),
  | \| \|                     -------------------------- match arm with an incompatible type
  | 181 \| \|         };
  | \| \|_________^ expected struct `syntax::symbol::LocalInternedString`, found struct `syntax::symbol::InternedString`
  | \|
  | = note: expected type `syntax::symbol::LocalInternedString`
  | found type `syntax::symbol::InternedString`
  |  
  | error[E0608]: cannot index into a value of type `syntax::symbol::InternedString`
  | --> tools/miri/miri/intrinsic.rs:32:31
  | \|
  | 32 \|         let intrinsic_name = &self.tcx.item_name(instance.def_id())[..];
  | \|                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |  
  | error[E0599]: no variant named `OverflowingMath` found for type `rustc::mir::interpret::EvalErrorKind<'_, _>` in the current scope
  | --> tools/miri/miri/helpers.rs:66:13
  | \|
  | 66 \|             err!(OverflowingMath)
  | \|             ^^^^^^^^^^^^^^^^^^^^^ variant not found in `rustc::mir::interpret::EvalErrorKind<'_, _>`
  | \|
  | = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
  |  
  | error[E0026]: variant `rustc::ty::layout::Variants::Tagged` does not have a field named `discr`
  | --> tools/miri/miri/validation.rs:458:40
  | \|
  | 458 \|                     Variants::Tagged { ref discr, .. } \|
  | \|                                        ^^^^^^^^^ variant `rustc::ty::layout::Variants::Tagged` does not have this field
  |  
  | error: aborting due to 6 previous errors
  |  
  | Some errors occurred: E0026, E0308, E0432, E0599, E0608, E0616.
  | For more information about an error, try `rustc --explain E0026`.
  | error: Could not compile `miri`.
  |  
  | Caused by:
  | process didn't exit successfully: `/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/bootstrap/debug/rustc --crate-name miri tools/miri/miri/lib.rs --error-format json --crate-type lib --emit=dep-info,link -C opt-level=3 -C metadata=3cbebf35d5e2e591 -C extra-filename=-3cbebf35d5e2e591 --out-dir /var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps -L dependency=/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/release/deps --extern regex=/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/libregex-65029f25a27e378d.rlib --extern byteorder=/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/libbyteorder-62fdd4f3dd91d4df.rlib --extern lazy_static=/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/liblazy_static-4add5af5c933865c.rlib --extern env_logger=/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/libenv_logger-706259616e96fef3.rlib --extern log=/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/liblog-0dac61128b7a7326.rlib` (exit code: 101)
  | command did not execute successfully: "/var/tmp/portage/dev-lang/rust-1.27.1/work/rust-stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "8" "-v" "--release" "--locked" "--frozen" "--manifest-path" "/var/tmp/portage/dev-lang/rust-1.27.1/work/rustc-1.27.1-src/src/tools/miri/Cargo.toml" "--features" "" "--message-format" "json"
  | expected success, got: exit code: 101

@Mark-Simulacrum mentioned on Discord that this might be fixed by passing --exclude src/tools/miri, which is correct. Still, it would be nice if the build system worked correctly here.

One option would be to use the tools config not just to toggle installation, but also compilation.

[cuviper]

Are you sure that was a fatal error? On Fedora, I got such failed builds for both clippy and miri -- neither of which are shipped -- and the overall build was still successful.
https://kojipkgs.fedoraproject.org//packages/rust/1.27.1/2.fc29/data/logs/x86_64/build.log

There's also a problem with the installer, #51650, that would come later if your stage0 is also 1.27.

[djc]

@cuviper ah, you are correct. I was thrown off because the error is all noisy with colors and then the final line is an understated white on black unindented or otherwise -adorned Build completed successfully in 0:39:45.

[cuviper]

We could have rustbuild write a prominent message after these optional tool failures, "but we don't care, continuing...", and then highlight the overall completion message too.

[djc]

Those are nice improvements and probably low-hanging fruit, but what do you think of the suggestion to let tools or some other variable in the build config drive what components get built and installed?

We might even remove the extended variable and have sane defaults for tools.

[cuviper]

That also sounds good to better control which tools attempt to build.

[Mark-Simulacrum]

I'm pretty sure this was fixed relatively recently (we reworked extended/tools handling), so going to go ahead and close. Feel free to reopen if something like this arises again.