rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
97.72k stars 12.64k forks source link

Tracking Issue for gracefully handling broken pipes in the compiler #131436

Open jieyouxu opened 1 week ago

jieyouxu commented 1 week ago

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:

Steps

RalfJung commented 5 days ago

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 commented 5 days ago

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.