New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change SIGPIPE
ui from #[unix_sigpipe = "..."]
to -Zon-broken-pipe=...
#124480
Conversation
The Miri subtree was changed cc @rust-lang/miri These commits modify compiler targets. rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead. cc @rust-lang/rust-analyzer |
LGTM from the rust-analyzer side. |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good to me on the compiler side. I'll roll a libs reviewer for the library part of this PR.
Rolling a libs reviewer for the libs part of this PR. If the changes also look good from the libs side, feel free to r=me. r? libs |
☔ The latest upstream changes (presumably #124505) made this pull request unmergeable. Please resolve the merge conflicts. |
I have addressed comments and rebased (because of a smalll conflict with master). diff of diffFWIW, here is the diff of the reviewed diff and the rebased and updated diff: $ git range-diff c4109eb^- 03dcde0^-
1: c4109eb191a ! 1: 03dcde080e7 Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`
@@ Commit message
libstd. Having a special language attribute in that case becomes
awkward.
- So as a first step towards stabilization, this PR changes the
- `#[unix_sigpipe = "..."]` attribute to a compiler flag
- `-Zon-broken-pipe=...`, to remove that concern, since now the language
+ So as a first step towards 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, namely that the ui should not leak
@@ src/doc/unstable-book/src/compiler-flags/on-broken-pipe.md (new)
+
+---
+
-+The `-Zon-broken-pipe=...` compiler flag can be used to specify how libstd shall setup `SIGPIPE` on Unix platforms before invoking `fn main()`. This flag is ignored on non-Unix targets. There are three variants:
-+* `-Zon-broken-pipe=inherit`
-+* `-Zon-broken-pipe=kill`
-+* `-Zon-broken-pipe=error`
+
-+## `-Zon-broken-pipe=inherit`
++## Overview
++
++The `-Zon-broken-pipe=...` compiler flag can be used to specify how libstd shall setup `SIGPIPE` on Unix platforms before invoking `fn main()`. This flag is ignored on non-Unix targets. The flag can be used with three different values or be omitted entirely. It affects `SIGPIPE` before `fn main()` and before children get `exec()`'ed:
++
++| Compiler flag | `SIGPIPE` before `fn main()` | `SIGPIPE` before child `exec()` |
++|----------------------------|------------------------------|---------------------------------|
++| not used | `SIG_DFL` | `SIG_DFL` |
++| `-Zon-broken-pipe=kill` | `SIG_DFL` | not touched |
++| `-Zon-broken-pipe=error` | `SIG_IGN` | not touched |
++| `-Zon-broken-pipe=inherit` | not touched | not touched |
++
++
++## `-Zon-broken-pipe` not used
++
++If `-Zon-broken-pipe` is not used, libstd will behave in the manner it has since 2014, before Rust 1.0. `SIGPIPE` will be set to `SIG_IGN` before `fn main()` and result in `EPIPE` errors which are converted to `std::io::ErrorKind::BrokenPipe`.
++
++When spawning child processes, `SIGPIPE` will be set to `SIG_DFL` before doing the underlying `exec()` syscall.
+
-+Leave `SIGPIPE` untouched before entering `fn main()`. Unless the parent process has changed the default `SIGPIPE` handler from `SIG_DFL` to something else, this will behave the same as `-Zon-broken-pipe=kill`.
+
+## `-Zon-broken-pipe=kill`
+
-+Set the `SIGPIPE` handler to `SIG_DFL`. This will result in your program getting killed if it tries to write to a closed pipe. This is normally what you want if your program produces textual output.
++Set the `SIGPIPE` handler to `SIG_DFL` before invoking `fn main()`. This will result in your program getting killed if it tries to write to a closed pipe. This is normally what you want if your program produces textual output.
++
++When spawning child processes, `SIGPIPE` will not be touched. This normally means child processes inherit `SIG_DFL` for `SIGPIPE`.
+
+### Example
+
@@ src/doc/unstable-book/src/compiler-flags/on-broken-pipe.md (new)
+
+Set the `SIGPIPE` handler to `SIG_IGN` before invoking `fn main()`. This will result in `ErrorKind::BrokenPipe` errors if you program tries to write to a closed pipe. This is normally what you want if you for example write socket servers, socket clients, or pipe peers.
+
-+This is what libstd has done by default since 2014. (However, see the note on child processes below.)
++When spawning child processes, `SIGPIPE` will not be touched. This normally means child processes inherit `SIG_IGN` for `SIGPIPE`.
+
+### Example
+
@@ src/doc/unstable-book/src/compiler-flags/on-broken-pipe.md (new)
+note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
+```
+
-+### Note on child processes
++## `-Zon-broken-pipe=inherit`
+
-+When spawning child processes, the legacy Rust behavior if `-Zon-broken-pipe=...` is not specified is to reset `SIGPIPE` to `SIG_DFL` first.
++Leave `SIGPIPE` untouched before entering `fn main()`. Unless the parent process has changed the default `SIGPIPE` handler from `SIG_DFL` to something else, this will behave the same as `-Zon-broken-pipe=kill`.
+
-+If `-Zon-broken-pipe=...` is specified, no matter what its value is, the signal disposition of `SIGPIPE` is no longer reset. This means that the child inherits the parent's `SIGPIPE` behavior.
++When spawning child processes, `SIGPIPE` will not be touched. This normally means child processes inherit `SIG_DFL` for `SIGPIPE`.
## src/doc/unstable-book/src/language-features/unix-sigpipe.md (deleted) ##
@@
@@ src/tools/miri/src/eval.rs: pub fn create_ecx<'mir, 'tcx: 'mir>(
// Always using DEFAULT is okay since we don't support signals in Miri anyway.
- // (This means we are effectively ignoring `#[unix_sigpipe]`.)
-+ // (This means we are effectively ignoring `SIGPIPE`.)
++ // (This means we are effectively ignoring `-Zon-broken-pipe`.)
let sigpipe = rustc_session::config::sigpipe::DEFAULT;
ecx.call_function(
@@ tests/ui/attributes/unix_sigpipe/unix_sigpipe-inherit.rs => tests/ui/runtime/on-
extern crate libc;
- // By default the Rust runtime resets SIGPIPE to SIG_DFL before exec:ing child
+ // By default the Rust runtime resets SIGPIPE to SIG_DFL before exec'ing child
-// processes so opt-out of that with `#[unix_sigpipe = "sig_dfl"]`. See
+// processes so opt-out of that with `-Zon-broken-pipe=kill`. See
// https://github.com/rust-lang/rust/blob/bf4de3a874753bbee3323081c8b0c133444fed2d/library/std/src/sys/pal/unix/process/process_unix.rs#L359-L384 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me for the library part
…pe=...` In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern was raised 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 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, 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.
@bors 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
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#124293 (Let miri and const eval execute intrinsics' fallback bodies) - rust-lang#124418 (Use a proof tree visitor to refine the `Obligation` for error reporting in new solver) - rust-lang#124480 (Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`) - rust-lang#124648 (Trim crate graph) - rust-lang#124656 (release notes 1.78: add link to interior-mut breaking change) - rust-lang#124658 (Migrate `run-make/doctests-keep-binaries` to new rmake.rs format) - rust-lang#124681 (zkvm: fix run_tests) - rust-lang#124687 (Make `Bounds.clauses` private) r? `@ghost` `@rustbot` modify labels: rollup
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
…mpiler-errors Rollup of 8 pull requests Successful merges: - rust-lang#124418 (Use a proof tree visitor to refine the `Obligation` for error reporting in new solver) - rust-lang#124480 (Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`) - rust-lang#124648 (Trim crate graph) - rust-lang#124656 (release notes 1.78: add link to interior-mut breaking change) - rust-lang#124658 (Migrate `run-make/doctests-keep-binaries` to new rmake.rs format) - rust-lang#124678 (Stabilize `split_at_checked`) - rust-lang#124681 (zkvm: fix run_tests) - rust-lang#124687 (Make `Bounds.clauses` private) r? `@ghost` `@rustbot` modify labels: rollup
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
In the stabilization attempt of
#[unix_sigpipe = "sig_dfl"]
, a concern was raised related to using a language attribute for the feature: Long term, we wantfn 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, 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: #97889