Tracking Issue for gracefully handling broken pipes in the compiler

[jieyouxu]

Context

std print! and println! by default will panic on a broken pipe if -Zon-broken-pipe=kill is not set when building rustc itself and left as default. If such a panic occurs and is not otherwise caught, it will manifest as an ICE. In bootstrap we build rustc with -Zon-broken-pipe=kill which terminates rustc to paper over issues like rustc --print=sysroot | false ICEing from the I/O panic from a broken pipe, but this is not always the desirabled behavior. As Nora said:

rustc --print=target-list | head -n5 should definitely work as expected and print only 5 targets and exit successfully, ICEing or erroring are not acceptable imo
so kill should still be passed
and rustc --print=target-list >/dev/full emitting an error instead of crashing would be neat too

See https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Internal.20lint.20for.20raw.20.60print!.60.20and.20.60println!.60.3F for a timeline of how we ended up with the -Zon-broken-pipe=kill paper.

Prior Art

Cargo denies print{,ln}! usages via clippy::print_std{err,out}:

See:

• https://github.com/rust-lang/cargo/blob/15fbd2f607d4defc87053b8b76bf5038f2483cf4/Cargo.toml#L125-L126
• https://github.com/rust-lang/cargo/blob/15fbd2f607d4defc87053b8b76bf5038f2483cf4/src/doc/contrib/src/implementation/console.md?plain=1#L3-L5

Steps

• Survey current usages of print{,ln}! macro usages in rustc.
• Classify desired behavior if we do handle I/O errors if we use some safe_print{,ln} alternative instead of panicking like print{,ln} (some might want to exit with success, some might want to error, but we probably never want to ICE).
• Open an MCP to propose migrating print{,ln}! macro usages to properly handle errors and adding an internal lint to deny (in CI, but allow locally to still allow printf debugging) raw usages of print{,ln}!.
• Fix existing print{,ln}! macro usages to properly handle errors.
• Drop -Zon-broken-pipe=kill when building rustc.
• Update tests/run-make/broken-pipe-no-ice/rmake.rs regression test.
• Implement the internal lint.
• Add documentation about print{,ln}! macro usages in the dev-guide.

[RalfJung]

Isn't this more of a t-libs-api issue? Surely the Rust compiler is not the only project that has a need for a more graceful handling of broken pipes.

[jieyouxu]

Well yes, but this is specifically about the rustc binary itself. For rustc itself, we may have different desired behaviors if we do encounter (different kinds of) I/O errors with print/println macro usages and not simply error/terminate. Other programs (not necessarily unix cli binaries) may have different requirements like servers and such.