Cargo build ICE when run with closed STDIN

[ooprala]

How to reproduce

cargo new any_project
cd any_project
cargo build <&-
# the &- syntax (valid in bash and zsh AFAIK)
# tells your shell to fork cargo with STDIN *closed*

Actual Result

thread '<unnamed>' panicked at 'failed to acquire jobserver token: early EOF on jobserver pipe', error: failed to acquire jobserver token: early EOF on jobserver pipe
src/librustc_codegen_ssa/back/write.rs:1406:29

note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error

error: Could not compile `any_project`.

To learn more, run the command again with --verbose.

Actual Result with full backtrace

thread '<unnamed>' panicked at 'failed to acquire jobserver token: early EOF on jobserver pipe', src/librustc_codegen_ssa/back/write.rs:1406:29
error: failed to acquire jobserver token: early EOF on jobserver pipe

stack backtrace:
   0:     0x7fa5eca1ce63 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::hc7b76c57e25c7d91
                               at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1:     0x7fa5eca1556b - std::sys_common::backtrace::_print::h203699a8f1b8b948
                               at src/libstd/sys_common/backtrace.rs:70
   2:     0x7fa5eca190c6 - std::panicking::default_hook::{{closure}}::h74fcb67c61dc8b92
                               at src/libstd/sys_common/backtrace.rs:58
                               at src/libstd/panicking.rs:200
   3:     0x7fa5eca18e44 - std::panicking::default_hook::hb2e06978a2102930
                               at src/libstd/panicking.rs:215
   4:     0x7fa5e8bb03df - rustc::util::common::panic_hook::h9fd4a470400ba35c
   5:     0x7fa5eca198b8 - std::panicking::rust_panic_with_hook::h4ac0b487eb7e54da
                               at src/libstd/panicking.rs:482
   6:     0x7fa5eca19351 - std::panicking::continue_panic_fmt::h23ca3ed77b25f368
                               at src/libstd/panicking.rs:385
   7:     0x7fa5eca1929e - std::panicking::begin_panic_fmt::he14137966dec33cc
                               at src/libstd/panicking.rs:340
   8:     0x7fa5e310477b - std::sys_common::backtrace::__rust_begin_short_backtrace::h6be5ab22ff539cca
   9:     0x7fa5e3146cad - std::panicking::try::do_call::hb93197db26b32ea9
  10:     0x7fa5eca2ab29 - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:87
  11:     0x7fa5e31105f8 - <F as alloc::boxed::FnBox<A>>::call_box::haaff0e1f36b63d07
  12:     0x7fa5eca2986d - std::sys::unix::thread::Thread::new::thread_start::h7fc2d82a3b91bc88
                               at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/liballoc/boxed.rs:759
                               at src/libstd/sys_common/thread.rs:14
                               at src/libstd/sys/unix/thread.rs:81
  13:     0x7fa5ec960a91 - start_thread
  14:     0x7fa5ec87fcd2 - __clone
  15:                0x0 - <unknown>
query stack during panic:
end of query stack
error: aborting due to previous error

error: Could not compile `any_project`.

To learn more, run the command again with --verbose.

rustc --version --verbose

rustc 1.34.1 (fc50f328b 2019-04-24)
binary: rustc
commit-hash: fc50f328b0353b285421b8ff5d4100966387a997
commit-date: 2019-04-24
host: x86_64-unknown-linux-gnu
release: 1.34.1
LLVM version: 8.0

Expected result

   Compiling any_project v0.1.0 (/tmp/any_project)
   Finished dev [unoptimized + debuginfo] target(s) in 0.33s

Additional details
Please note that the issue will go away once you succeed in building the project (probably thanks due to some compiler caching, sorry, not sure here).
A touch is enough to get the error back :)

touch src/main.rs

Thank you.

[pnkfelix]

triage: P-medium due to niche nature of bug. Leaving nominated to try to increase its visibility in short term in case T-compiler members want to attack it.

[ooprala]

@pnkfelix I'm not asking you to re-prio. I'd just like to say I don't think the issue is so niche, as cargo run seems to exhibit the very same behaviour, and I can easily see myself trying:

cargo run <&-

Thank you and @Centril again for looking at the ticket 👍

[pnkfelix]

discussed briefly at T-compiler meeting. un-nominating.

[CleanCut]

I inadvertently ran into this bug today when trying to do cargo run with my project with stdin closed to see how my project would behave. I wasted quite a bit of time trying to find the ICE by reducing my program down...and then I found this issue. 😢

[Elinvynia]

I am unable to reproduce this anymore
#1 SMP Debian 4.19.98-1 (2020-01-26)

rustc 1.45.0-nightly (bad3bf622 2020-05-09)
binary: rustc
commit-hash: bad3bf622bded50a97c0a54e29350eada2a3a169
commit-date: 2020-05-09
host: x86_64-unknown-linux-gnu
release: 1.45.0-nightly
LLVM version: 9.0

and WSL:

rustc 1.45.0-nightly (7ebd87a7a 2020-05-08)
binary: rustc
commit-hash: 7ebd87a7a1e0e21767422e115c9455ef6e6d4bee
commit-date: 2020-05-08
host: x86_64-unknown-linux-gnu
release: 1.45.0-nightly
LLVM version: 9.0

[CleanCut]

The problem is still present for me on macOS even on nightly:

rustc 1.45.0-nightly (7ebd87a7a 2020-05-08)
binary: rustc
commit-hash: 7ebd87a7a1e0e21767422e115c9455ef6e6d4bee
commit-date: 2020-05-08
host: x86_64-apple-darwin
release: 1.45.0-nightly
LLVM version: 9.0

[theastrallyforged]

I wonder if this is related to #57728? By the way, for that reason, don't run Rust things with <&-.