Skip to content

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

Open
@jieyouxu

Description

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

  • 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-hardCall for participation: Hard difficulty. Experience needed to fix: A lot.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions