Tracking Issue for unix_sigpipe

[Enselic]

The feature gate for the issue is #![feature(unix_sigpipe)].

A new fn main() attribute #[unix_sigpipe = "inherit|sig_ign|sig_dfl"] is added. The names sig_ign and sig_dfl comes from the signal handler names SIG_IGN and SIG_DFL.

Naming convention

The naming follows the convention used by #![windows_subsystem = "windows|console"] where the values "windows" and "console" have the same names as the actual linker flags: /SUBSYSTEM:WINDOWS and /SUBSYSTEM:CONSOLE.

Usage

Please refer to the unstable book section for more details. In short:

#[unix_sigpipe = "..."]	Behaviour
inherit	Leave SIGPIPE untounched before entering fn main(). Normally this means theSIGPIPE handler is SIG_DFL.
sig_dfl	Set SIGPIPE handler to SIG_DFL before invoking fn main().
sig_ign	Set SIGPIPE handler to SIG_IGN before invoking fn main(). Default behaviour since 2014.

SIGPIPE

The problem with the current SIGPIPE code in libstd as well as several other aspects of this problem is discussed extensively at these places:

• #62569
• #46016
• https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem

Steps

• Implement the feature. Initial implementation ready for review: #97802
• Start using this feature across Rust project and tools to get to know it in practice
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Can and should we alter the BrokenPipe error message and make it suggest to use the new attribute?
• Should we stabilize sig_dfl or is inherit and sig_ign sufficient?
• What is the long-term plan with regards to changing the default behaviour with regards to ignoring SIGPIPE, if we want to do it at all?
• Can we write the code in a way that allows lto to remove the _signal stub code completely? With a bool it works, with u8 we might need to do some tweaks.
• Does this have any impact on defining a stable ABI? Probably not, since we only change the ABI of fn lang_start(). And a stable Rust ABI is not even close (see rust-lang/rfcs#600).

Resolved Questions

• We don't want to change to a -Z unix_sigpipe flag instead, see https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Proposal.3A.20First.20step.20towards.20solving.20the.20SIGPIPE.20problem/near/285499895, at least not initially.
• Should we only have the third sigpipe: u8 argument to fn lang_start() on Unix platform via cfg? A: No, this is not allowed, see https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/pal.rs

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

@rustbot label +T-libs