Stabilize `#[unix_sigpipe = "sig_dfl"]` on `fn main()` #120832

Enselic · 2024-02-09T08:38:27Z

I would like to propose that we stabilize #[unix_sigpipe = "sig_dfl"].
This PR does that.

By my estimation, merging this PR will close #46016.

Tracking issue is #97889.

Stabilization report

The #[unix_sigpipe = "sig_dfl"] attribute has been available in nightly since nightly-2022-09-04 (17 months).

It is being used by rustc and rustdoc themselves, and also by third party code (1, 2).

I have monitored the keyword sigpipe on rust-lang/rust during all this time, and no problems have been reported regarding the attribute. To the contrary. It's infrastructure was used to implement a bugfix in a backwards compatible way.

Summary and examples

Everything you need to know about the stabilized attribute should be documented in the reference. PR. Rendered.

Test cases

https://github.com/rust-lang/rust/tree/master/tests/ui/attributes/unix_sigpipe

Edge cases

None that I am aware of.

Note that using #[unix_sigpipe = "sig_dfl"] and receiving a SIGPIPE means destructors will not run since the process will be immediately killed. I documented this in The Reference.

Unresolved questions

None. See tracking issue.

Worth noting

This PR does NOT stabilize any other variant of the attribute, namely #[unix_sigpipe = "sig_ign"] and #[unix_sigpipe = "inherit"].

There are many reasons for this:

Avoids choice paralysis between leaving SIGPIPE be the default (SIG_IGN) and explicitly setting it to SIG_IGN with #[unix_sigpipe = "sig_ign"]
I have found no one using #[unix_sigpipe = "sig_ign"] nor #[unix_sigpipe = "inherit"] in the wild, so they are much less tested, and there seems to be no desire for them.
Stabilizing something means committing to its existence for all eternity, so we should not stabilize attributes that are not absolutely needed.
It leaves the door open to change fn lang_start() sigpipe arg from u8 to bool ("not set" or "set to sig_dfl"), enabling better lto. Only relevant if we end up deciding not to change the default, and not adding #[unix_sigpipe = "inherit"].
These variants have unresolved open questions. See tracking issue.

Potential future work

There is a discussion about changing the default SIGPIPE handler. See here. Changing the default would likely require us to also stabilize #[unix_sigpipe = "sig_ign"]. But doing that and discussing changing the default is out of scope of this PR.

Left to do

Update the unstable book page of unix_sigpipe if we merge this.

FCP

Since we can't close the tracking issue entirely yet, my hope is that we can do an FCP on this PR rather than on the tracking issue.

rustbot · 2024-02-09T08:38:35Z

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

davidtwco

Implementation looks good to me, will wait for the t-lang nomination.

joshtriplett · 2024-02-14T17:39:38Z

I do think we should stabilize "inherit". In particular, if we consider changing the default in a future edition, I'd propose changing the default to "inherit", not to "sig_dfl", so that we don't make the syscall at all.

kornelski · 2024-02-14T18:42:14Z

I've mentioned in the forum that I'm missing an option to ignore both the signal and panic-causing errors in println.

If this attribute wasn't so transparent with low-level unix jargon, maybe it could be used to set the third strategy?

Enselic · 2024-02-16T05:26:51Z

I do think we should stabilize "inherit". In particular, if we consider changing the default in a future edition, I'd propose changing the default to "inherit", not to "sig_dfl", so that we don't make the syscall at all.

I don't think we should stabilize #[unix_sigpipe = "inherit"], because if we change the default in a future edition to be to not touch SIGPIPE at all we would have

`fn main()`	`SIGPIPE`
`fn main()`	`SIGPIPE` not touched
`#[unix_sigpipe = "sig_ign"]` `fn main()`	`SIGPIPE` set to `SIG_IGN`
`#[unix_sigpipe = "sig_dfl"]` `fn main()`	`SIGPIPE` set to `SIG_DFL`

Maybe we don't even need #[unix_sigpipe = "sig_dfl"] at all in that case.

So maybe we need to make a decision on #62569 after all, before we can stabilize anything. Perhaps summarizing #62569 into an RFC is the best way forward here. I think it is, and I hope to get around to it in a not too distant future.

If this attribute wasn't so transparent with low-level unix jargon, maybe it could be used to set the third strategy?

I replied to your post in the forum. In short: I don't think #[unix_sigpipe = "..."] will be useful for this.

joshtriplett · 2024-02-16T13:32:47Z

@Enselic What's the harm in stabilizing inherit even if it subsequently becomes the default?

We allow people to write repr(Rust), or pub(self), even though those are the defaults.

bors · 2024-02-16T23:44:56Z

☔ The latest upstream changes (presumably #120881) made this pull request unmergeable. Please resolve the merge conflicts.

Enselic · 2024-02-17T06:46:35Z

@joshtriplett It is possible I am overestimating the harm of stabilizing an attribute that might not be needed long term. 10 years from now I just think it will be annoying to have to maintain an attribute variant that is not needed. It unnecessarily restricts us.

If we can find a way to turn sigpipe: u8 of fn lang_start() into a sigpipe: bool, we will achieve better lto. Meaning that the code for the call to libc::signal can more easily be removed entirely.

I also think that "no attribute used" is a good way to convey "no special code runs".

If we want to stabilize #[unix_sigpipe = "inherit"], I can't help but want to bikeshed the name a bit more. Looking at man 7 signal we can see that "inherit" happens during fork():

A child created via fork(2) inherits a copy of its parent's signal dispositions.

so I don't think "inherit" is a slam-dunk name to use in our case, because the "inherit" mechanism has already been applied when the Rust lang_start() code runs.

Maybe #[unix_sigpipe = "unchanged"] is a better name?

kornelski · 2024-02-17T11:53:14Z

Maybe change the default on edition boundary, and only support a Boolean attribute that restores the old behavior for cargo fix to use?

jstarks · 2024-02-18T02:29:54Z

If we stabilize inherit and skip stabilizing dfl, then people who want dfl can explicitly make the call in main themselves. And then you can remove the dfl option altogether and get your lto win.

If we don’t stabilize inherit, then people who want standard UNIX behavior have no way to get it, other than wait for an unspecified new edition, I guess? Which in reality is another 3 years away, at least?

joshtriplett · 2024-02-21T17:59:21Z

Discussed in today's @rust-lang/libs meeting: libs does not consider ourselves a blocker for this stabilization.

…r=davidtwco unix_sigpipe: Simple fixes and improvements in tests In rust-lang#120832 I included 5 preparatory commits. It will take a while before discussions there and in rust-lang#62569 is settled, so here is a PR that splits out 4 of the commits that are easy to review, to get them out of the way. r? `@davidtwco` who already approved these commits in rust-lang#120832 (but I have tweaked them a bit and rebased them since then). For the convenience of my reviewer, here are the full commit messages of the commits: <details> <summary>Click to expand</summary> ``` commit 948b1d6 (HEAD -> unix_sigpipe-tests-fixes, origin/unix_sigpipe-tests-fixes) Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 07:57:27 2024 +0100 tests: Add unix_sigpipe-different-duplicates.rs test variant To make sure that #[unix_sigpipe = "x"] #[unix_sigpipe = "y"] behaves like #[unix_sigpipe = "x"] #[unix_sigpipe = "x"] commit d14f158 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 08:47:47 2024 +0100 tests: Combine unix_sigpipe-not-used.rs and unix_sigpipe-only-feature.rs The only difference between the files is the presence/absence of #![feature(unix_sigpipe)] attribute. Avoid duplication by using revisions instead. commit a1cb3db Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 06:44:56 2024 +0100 tests: Rename unix_sigpipe.rs to unix_sigpipe-bare.rs for clarity The test is for the "bare" variant of the attribute that looks like this: #[unix_sigpipe] which is not allowed, because it must look like this: #[unix_sigpipe = "sig_ign"] commit e060274 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 05:48:24 2024 +0100 tests: Fix typo unix_sigpipe-error.rs -> unix_sigpipe-sig_ign.rs There is no error expected. It's simply the "regular" test for sig_ign. So rename it. ``` </details> Tracking issue: rust-lang#97889

…r=davidtwco unix_sigpipe: Simple fixes and improvements in tests In rust-lang#120832 I included 5 preparatory commits. It will take a while before discussions there and in rust-lang#62569 is settled, so here is a PR that splits out 4 of the commits that are easy to review, to get them out of the way. r? ``@davidtwco`` who already approved these commits in rust-lang#120832 (but I have tweaked them a bit and rebased them since then). For the convenience of my reviewer, here are the full commit messages of the commits: <details> <summary>Click to expand</summary> ``` commit 948b1d6 (HEAD -> unix_sigpipe-tests-fixes, origin/unix_sigpipe-tests-fixes) Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 07:57:27 2024 +0100 tests: Add unix_sigpipe-different-duplicates.rs test variant To make sure that #[unix_sigpipe = "x"] #[unix_sigpipe = "y"] behaves like #[unix_sigpipe = "x"] #[unix_sigpipe = "x"] commit d14f158 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 08:47:47 2024 +0100 tests: Combine unix_sigpipe-not-used.rs and unix_sigpipe-only-feature.rs The only difference between the files is the presence/absence of #![feature(unix_sigpipe)] attribute. Avoid duplication by using revisions instead. commit a1cb3db Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 06:44:56 2024 +0100 tests: Rename unix_sigpipe.rs to unix_sigpipe-bare.rs for clarity The test is for the "bare" variant of the attribute that looks like this: #[unix_sigpipe] which is not allowed, because it must look like this: #[unix_sigpipe = "sig_ign"] commit e060274 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 05:48:24 2024 +0100 tests: Fix typo unix_sigpipe-error.rs -> unix_sigpipe-sig_ign.rs There is no error expected. It's simply the "regular" test for sig_ign. So rename it. ``` </details> Tracking issue: rust-lang#97889

…r=davidtwco unix_sigpipe: Simple fixes and improvements in tests In rust-lang#120832 I included 5 preparatory commits. It will take a while before discussions there and in rust-lang#62569 is settled, so here is a PR that splits out 4 of the commits that are easy to review, to get them out of the way. r? ```@davidtwco``` who already approved these commits in rust-lang#120832 (but I have tweaked them a bit and rebased them since then). For the convenience of my reviewer, here are the full commit messages of the commits: <details> <summary>Click to expand</summary> ``` commit 948b1d6 (HEAD -> unix_sigpipe-tests-fixes, origin/unix_sigpipe-tests-fixes) Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 07:57:27 2024 +0100 tests: Add unix_sigpipe-different-duplicates.rs test variant To make sure that #[unix_sigpipe = "x"] #[unix_sigpipe = "y"] behaves like #[unix_sigpipe = "x"] #[unix_sigpipe = "x"] commit d14f158 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 08:47:47 2024 +0100 tests: Combine unix_sigpipe-not-used.rs and unix_sigpipe-only-feature.rs The only difference between the files is the presence/absence of #![feature(unix_sigpipe)] attribute. Avoid duplication by using revisions instead. commit a1cb3db Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 06:44:56 2024 +0100 tests: Rename unix_sigpipe.rs to unix_sigpipe-bare.rs for clarity The test is for the "bare" variant of the attribute that looks like this: #[unix_sigpipe] which is not allowed, because it must look like this: #[unix_sigpipe = "sig_ign"] commit e060274 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 05:48:24 2024 +0100 tests: Fix typo unix_sigpipe-error.rs -> unix_sigpipe-sig_ign.rs There is no error expected. It's simply the "regular" test for sig_ign. So rename it. ``` </details> Tracking issue: rust-lang#97889

…r=davidtwco unix_sigpipe: Simple fixes and improvements in tests In rust-lang#120832 I included 5 preparatory commits. It will take a while before discussions there and in rust-lang#62569 is settled, so here is a PR that splits out 4 of the commits that are easy to review, to get them out of the way. r? `@davidtwco` who already approved these commits in rust-lang#120832 (but I have tweaked them a bit and rebased them since then). For the convenience of my reviewer, here are the full commit messages of the commits: <details> <summary>Click to expand</summary> ``` commit 948b1d6 (HEAD -> unix_sigpipe-tests-fixes, origin/unix_sigpipe-tests-fixes) Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 07:57:27 2024 +0100 tests: Add unix_sigpipe-different-duplicates.rs test variant To make sure that #[unix_sigpipe = "x"] #[unix_sigpipe = "y"] behaves like #[unix_sigpipe = "x"] #[unix_sigpipe = "x"] commit d14f158 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 08:47:47 2024 +0100 tests: Combine unix_sigpipe-not-used.rs and unix_sigpipe-only-feature.rs The only difference between the files is the presence/absence of #![feature(unix_sigpipe)] attribute. Avoid duplication by using revisions instead. commit a1cb3db Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 06:44:56 2024 +0100 tests: Rename unix_sigpipe.rs to unix_sigpipe-bare.rs for clarity The test is for the "bare" variant of the attribute that looks like this: #[unix_sigpipe] which is not allowed, because it must look like this: #[unix_sigpipe = "sig_ign"] commit e060274 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 05:48:24 2024 +0100 tests: Fix typo unix_sigpipe-error.rs -> unix_sigpipe-sig_ign.rs There is no error expected. It's simply the "regular" test for sig_ign. So rename it. ``` </details> Tracking issue: rust-lang#97889

…r=davidtwco unix_sigpipe: Simple fixes and improvements in tests In rust-lang#120832 I included 5 preparatory commits. It will take a while before discussions there and in rust-lang#62569 is settled, so here is a PR that splits out 4 of the commits that are easy to review, to get them out of the way. r? ``@davidtwco`` who already approved these commits in rust-lang#120832 (but I have tweaked them a bit and rebased them since then). For the convenience of my reviewer, here are the full commit messages of the commits: <details> <summary>Click to expand</summary> ``` commit 948b1d6 (HEAD -> unix_sigpipe-tests-fixes, origin/unix_sigpipe-tests-fixes) Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 07:57:27 2024 +0100 tests: Add unix_sigpipe-different-duplicates.rs test variant To make sure that #[unix_sigpipe = "x"] #[unix_sigpipe = "y"] behaves like #[unix_sigpipe = "x"] #[unix_sigpipe = "x"] commit d14f158 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 08:47:47 2024 +0100 tests: Combine unix_sigpipe-not-used.rs and unix_sigpipe-only-feature.rs The only difference between the files is the presence/absence of #![feature(unix_sigpipe)] attribute. Avoid duplication by using revisions instead. commit a1cb3db Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 06:44:56 2024 +0100 tests: Rename unix_sigpipe.rs to unix_sigpipe-bare.rs for clarity The test is for the "bare" variant of the attribute that looks like this: #[unix_sigpipe] which is not allowed, because it must look like this: #[unix_sigpipe = "sig_ign"] commit e060274 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 05:48:24 2024 +0100 tests: Fix typo unix_sigpipe-error.rs -> unix_sigpipe-sig_ign.rs There is no error expected. It's simply the "regular" test for sig_ign. So rename it. ``` </details> Tracking issue: rust-lang#97889

Rollup merge of rust-lang#121527 - Enselic:unix_sigpipe-tests-fixes, r=davidtwco unix_sigpipe: Simple fixes and improvements in tests In rust-lang#120832 I included 5 preparatory commits. It will take a while before discussions there and in rust-lang#62569 is settled, so here is a PR that splits out 4 of the commits that are easy to review, to get them out of the way. r? ``@davidtwco`` who already approved these commits in rust-lang#120832 (but I have tweaked them a bit and rebased them since then). For the convenience of my reviewer, here are the full commit messages of the commits: <details> <summary>Click to expand</summary> ``` commit 948b1d6 (HEAD -> unix_sigpipe-tests-fixes, origin/unix_sigpipe-tests-fixes) Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 07:57:27 2024 +0100 tests: Add unix_sigpipe-different-duplicates.rs test variant To make sure that #[unix_sigpipe = "x"] #[unix_sigpipe = "y"] behaves like #[unix_sigpipe = "x"] #[unix_sigpipe = "x"] commit d14f158 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 08:47:47 2024 +0100 tests: Combine unix_sigpipe-not-used.rs and unix_sigpipe-only-feature.rs The only difference between the files is the presence/absence of #![feature(unix_sigpipe)] attribute. Avoid duplication by using revisions instead. commit a1cb3db Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 06:44:56 2024 +0100 tests: Rename unix_sigpipe.rs to unix_sigpipe-bare.rs for clarity The test is for the "bare" variant of the attribute that looks like this: #[unix_sigpipe] which is not allowed, because it must look like this: #[unix_sigpipe = "sig_ign"] commit e060274 Author: Martin Nordholts <[email protected]> Date: Fri Feb 9 05:48:24 2024 +0100 tests: Fix typo unix_sigpipe-error.rs -> unix_sigpipe-sig_ign.rs There is no error expected. It's simply the "regular" test for sig_ign. So rename it. ``` </details> Tracking issue: rust-lang#97889

That is the variant that has the highest potential to be stabilized, and we want to test it as much as possible.

The attribute is used like this: #[unix_sigpipe = "sig_dfl"] fn main() { // ... } When used, `SIGPIPE` will be set to `SIG_DFL` before `fn main()` is invoked, rather than being set to `SIG_IGN` which is the default. This commit does NOT stabilize `#[unix_sigpipe = "sig_ign"]` or `#[unix_sigpipe = "inherit"]`. See the PR for more info.

Enselic · 2024-03-09T14:45:35Z

Rebased to resolve conflicts. Current status:

If we decide not to change the default SIGPIPE disposition which is my recommendation, there are no blockers to merge this PR after an FCP so that #[unix_sigpipe = "sig_dfl"] is stabilized.

If we want to change the default SIGPIPE disposition to "inherit" over an edition boundary, we probably still want to stabilize #[unix_sigpipe = "sig_dfl"], but it is less of a slam dunk because in practice SIG_DFL will be the default.

We can't stabilize #[unix_sigpipe = "sig_ign"] yet because currently child processes get SIG_IGN, but arguably they should get SIG_DFL since that is what most programs assume, and we explicitly made it that way before. Note that we can implement this without running code right before exec, see #121578 for the trick. This open question is mentioned in the tracking issue now.

We can't stabilize #[unix_sigpipe = "inherit"] yet because we might want to rename it to e.g. #[unix_sigpipe = "unchanged"]. This open question is mentioned in the tracking issue now.

bstrie · 2024-03-09T20:36:32Z

On behalf of the Edition 2024 Working Group, even though our soft deadline for accepting editions changes has passed, we're still willing to entertain changing the SIGPIPE default in the 2024 edition, but the hard deadline for the edition cutoff is the end of May, so please make a decision promptly. :)

hypatian · 2024-03-09T22:14:34Z

As someone who writes a lot of software that works by connecting things up with pipes: I strongly encourage at least getting #[unix_sigpipe = "sig_dfl"] out of nightly.

After reading around in 62569, I understand better now some of the concerns around changing the Rust signal-handling default behavior. While as a UNIX-style command-line tool dev I'd much rather not have been surprised by this difference from other development environments on UNIX, it was not that hard to find out where the surprise was coming from and to resolve it.

Except, that is, for the fact that it's locked me into using nightly for basically all of my Rust development ever. That's really my only beef: it's been years, and I'm still using nightly just for this.

So change the default for edition 2024 or don't... but please, please, at least make it possible for developers of UNIX pipe-based tools to use stable instead of having to take on nightly just to get back to their operating system's default behavior.

Amanieu · 2024-03-10T00:28:34Z

As a completely separate concern from what to do about the default behavior, I have some concerns about the attribute syntax itself.

Currently, the attribute describes the syscall that is being performed (setting the signal disposition for SIGPIPE), but this is a very low-level API that may be confusing to people not familiar with the weeds of UNIX pipes. Additionally, #[unix_sigpipe = "sig_ign"] would be misleading if #121578 lands since we won't actually be using SIG_IGN at all in that case.

I believe that the attribute should instead describe what it is actually achieving: in this case, changing the behavior of the program when a pipe is broken. Proposed syntax: #[on_broken_pipe = "..."] or #[unix_on_broken_pipe = "..."].

Possible values for the attribute would be:

"inherit" to inherit the behavior from the parent process.
"kill" to kill the process with SIGPIPE.
"error" to have writes return an error (EPIPE).

bors · 2024-03-11T00:45:38Z

☔ The latest upstream changes (presumably #122312) made this pull request unmergeable. Please resolve the merge conflicts.

…idtwco unix_sigpipe: Replace `inherit` with `sig_dfl` in syntax tests The `sig_dfl` variant of the attribute is the most likely variant to be stabilized first, and thus to become the "most allowed" variant of the attribute. Because of this, it is the most appropriate variant to use in syntax tests, because even if the most allowed variant is used, the compiler shall still emit errors if it e.g. is used in the wrong places. r? `@davidtwco` who already [approved ](rust-lang#120832 (review)) this commit in rust-lang#120832. It would be nice to land the last preparatory commit of that PR before we begin to [rename ](rust-lang#120832 (comment)) things which will of course create a lot of code conflicts.

…idtwco unix_sigpipe: Replace `inherit` with `sig_dfl` in syntax tests The `sig_dfl` variant of the attribute is the most likely variant to be stabilized first, and thus to become the "most allowed" variant of the attribute. Because of this, it is the most appropriate variant to use in syntax tests, because even if the most allowed variant is used, the compiler shall still emit errors if it e.g. is used in the wrong places. r? ``@davidtwco`` who already [approved ](rust-lang#120832 (review)) this commit in rust-lang#120832. It would be nice to land the last preparatory commit of that PR before we begin to [rename ](rust-lang#120832 (comment)) things which will of course create a lot of code conflicts.

Rollup merge of rust-lang#122328 - Enselic:sig_dfl-not-inherit, r=davidtwco unix_sigpipe: Replace `inherit` with `sig_dfl` in syntax tests The `sig_dfl` variant of the attribute is the most likely variant to be stabilized first, and thus to become the "most allowed" variant of the attribute. Because of this, it is the most appropriate variant to use in syntax tests, because even if the most allowed variant is used, the compiler shall still emit errors if it e.g. is used in the wrong places. r? ``@davidtwco`` who already [approved ](rust-lang#120832 (review)) this commit in rust-lang#120832. It would be nice to land the last preparatory commit of that PR before we begin to [rename ](rust-lang#120832 (comment)) things which will of course create a lot of code conflicts.

unix_sigpipe: Replace `inherit` with `sig_dfl` in syntax tests The `sig_dfl` variant of the attribute is the most likely variant to be stabilized first, and thus to become the "most allowed" variant of the attribute. Because of this, it is the most appropriate variant to use in syntax tests, because even if the most allowed variant is used, the compiler shall still emit errors if it e.g. is used in the wrong places. r? ``@davidtwco`` who already [approved ](rust-lang/rust#120832 (review)) this commit in rust-lang/rust#120832. It would be nice to land the last preparatory commit of that PR before we begin to [rename ](rust-lang/rust#120832 (comment)) things which will of course create a lot of code conflicts.

m-ou-se · 2024-03-19T14:53:11Z

I'm worried that stabilizing this attribute makes std even more special than it already is. See my comment on the tracking issue: #97889 (comment)

Enselic · 2024-04-01T13:08:47Z

I will look into ways of removing the sigpipe arg on fn lang_start(). I will also look into renaming the attribute.

This means stabilization of this attribute will not happen near term, so I will close this PR for now. Thanks all for the feedback 👍

Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...` In the stabilization [attempt](rust-lang#120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](rust-lang#120832 (comment)) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward. So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature. Another point was [also raised](rust-lang#120832 (comment)), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization. Tracking issue: rust-lang#97889

Rollup merge of rust-lang#124480 - Enselic:on-broken-pipe, r=jieyouxu Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...` In the stabilization [attempt](rust-lang#120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](rust-lang#120832 (comment)) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward. So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature. Another point was [also raised](rust-lang#120832 (comment)), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization. Tracking issue: rust-lang#97889

Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...` In the stabilization [attempt](rust-lang/rust#120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](rust-lang/rust#120832 (comment)) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward. So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature. Another point was [also raised](rust-lang/rust#120832 (comment)), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization. Tracking issue: rust-lang/rust#97889

rustbot assigned davidtwco Feb 9, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Feb 9, 2024

This comment has been minimized.

Sign in to view

Noratrieb added the I-lang-nominated Nominated for discussion during a lang team meeting. label Feb 9, 2024

Enselic force-pushed the stabilize-unix_sigpipe-sig_dfl branch from 4be319b to 775ee4e Compare February 9, 2024 09:46

Enselic mentioned this pull request Feb 9, 2024

runtime.md: The #[unix_sigpipe = "sig_dfl"] attribute rust-lang/reference#1465

Closed

Enselic added T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Feb 9, 2024

Enselic mentioned this pull request Feb 11, 2024

Tracking Issue for unix_sigpipe #97889

Open

23 tasks

davidtwco approved these changes Feb 12, 2024

View reviewed changes

tryton-vanmeer mentioned this pull request Feb 17, 2024

CLICOLOR_FORCE Causes BrokenPipe tryton-vanmeer/Toshokan#5

Open

joshtriplett removed the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Feb 21, 2024

This was referenced Feb 23, 2024

Should Rust still ignore SIGPIPE by default? #62569

Open

unix_sigpipe: Simple fixes and improvements in tests #121527

Merged

Enselic added 2 commits March 9, 2024 11:33

unix_sigpipe: Use sig_dfl as much as possible in tests

fcc64f2

That is the variant that has the highest potential to be stabilized, and we want to test it as much as possible.

Enselic force-pushed the stabilize-unix_sigpipe-sig_dfl branch from 775ee4e to b6d7e9d Compare March 9, 2024 14:44

Enselic mentioned this pull request Mar 11, 2024

unix_sigpipe: Replace inherit with sig_dfl in syntax tests #122328

Merged

apiraino added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 28, 2024

Enselic closed this Apr 1, 2024

YaLTeR mentioned this pull request Apr 16, 2024

niri_ipc::NiriSocket; niri msg version; version checking on IPC YaLTeR/niri#278

Merged

Enselic mentioned this pull request Apr 28, 2024

Change SIGPIPE ui from #[unix_sigpipe = "..."] to -Zon-broken-pipe=... #124480

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize `#[unix_sigpipe = "sig_dfl"]` on `fn main()` #120832

Stabilize `#[unix_sigpipe = "sig_dfl"]` on `fn main()` #120832

Enselic commented Feb 9, 2024 •

edited

Loading

rustbot commented Feb 9, 2024

This comment has been minimized.

davidtwco left a comment

joshtriplett commented Feb 14, 2024 •

edited

Loading

kornelski commented Feb 14, 2024

Enselic commented Feb 16, 2024 •

edited

Loading

joshtriplett commented Feb 16, 2024

bors commented Feb 16, 2024

Enselic commented Feb 17, 2024 •

edited

Loading

kornelski commented Feb 17, 2024

jstarks commented Feb 18, 2024

joshtriplett commented Feb 21, 2024

Enselic commented Mar 9, 2024 •

edited

Loading

bstrie commented Mar 9, 2024

hypatian commented Mar 9, 2024

Amanieu commented Mar 10, 2024

bors commented Mar 11, 2024

m-ou-se commented Mar 19, 2024

Enselic commented Apr 1, 2024

Stabilize #[unix_sigpipe = "sig_dfl"] on fn main() #120832

Stabilize #[unix_sigpipe = "sig_dfl"] on fn main() #120832

Conversation

Enselic commented Feb 9, 2024 • edited Loading

Stabilization report

Summary and examples

Test cases

Edge cases

Unresolved questions

Worth noting

Potential future work

Left to do

FCP

rustbot commented Feb 9, 2024

This comment has been minimized.

davidtwco left a comment

Choose a reason for hiding this comment

joshtriplett commented Feb 14, 2024 • edited Loading

kornelski commented Feb 14, 2024

Enselic commented Feb 16, 2024 • edited Loading

joshtriplett commented Feb 16, 2024

bors commented Feb 16, 2024

Enselic commented Feb 17, 2024 • edited Loading

kornelski commented Feb 17, 2024

jstarks commented Feb 18, 2024

joshtriplett commented Feb 21, 2024

Enselic commented Mar 9, 2024 • edited Loading

bstrie commented Mar 9, 2024

hypatian commented Mar 9, 2024

Amanieu commented Mar 10, 2024

bors commented Mar 11, 2024

m-ou-se commented Mar 19, 2024

Enselic commented Apr 1, 2024

Stabilize `#[unix_sigpipe = "sig_dfl"]` on `fn main()` #120832

Stabilize `#[unix_sigpipe = "sig_dfl"]` on `fn main()` #120832

Enselic commented Feb 9, 2024 •

edited

Loading

joshtriplett commented Feb 14, 2024 •

edited

Loading

Enselic commented Feb 16, 2024 •

edited

Loading

Enselic commented Feb 17, 2024 •

edited

Loading

Enselic commented Mar 9, 2024 •

edited

Loading