Skip to content
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

Merged
merged 1 commit into from May 4, 2024

Conversation

Enselic
Copy link
Member

@Enselic Enselic commented Apr 28, 2024

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

@rustbot
Copy link
Collaborator

rustbot commented Apr 28, 2024

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

@rustbot rustbot added O-unix Operating system: Unix-like S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Apr 28, 2024
@rustbot
Copy link
Collaborator

rustbot commented Apr 28, 2024

The Miri subtree was changed

cc @rust-lang/miri

These commits modify compiler targets.
(See the Target Tier Policy.)

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

@lnicola
Copy link
Member

lnicola commented Apr 28, 2024

LGTM from the rust-analyzer side.

@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@jieyouxu jieyouxu left a 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.

src/doc/unstable-book/src/compiler-flags/on-broken-pipe.md Outdated Show resolved Hide resolved
@jieyouxu
Copy link
Contributor

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

@rustbot rustbot assigned Amanieu and unassigned jieyouxu Apr 28, 2024
@bors
Copy link
Contributor

bors commented Apr 29, 2024

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

@Enselic
Copy link
Member Author

Enselic commented Apr 29, 2024

I have addressed comments and rebased (because of a smalll conflict with master).

diff of diff

FWIW, 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

Copy link
Member

@Amanieu Amanieu left a 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

compiler/rustc_passes/src/entry.rs Outdated Show resolved Hide resolved
…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.
@Amanieu
Copy link
Member

Amanieu commented May 2, 2024

@bors r=jieyouxu

@bors
Copy link
Contributor

bors commented May 2, 2024

📌 Commit cde0cde has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 2, 2024
compiler-errors added a commit to compiler-errors/rust that referenced this pull request May 4, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request May 4, 2024
…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
compiler-errors added a commit to compiler-errors/rust that referenced this pull request May 4, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request May 4, 2024
…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
@bors bors merged commit 9dfd527 into rust-lang:master May 4, 2024
6 checks passed
@rustbot rustbot added this to the 1.80.0 milestone May 4, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 4, 2024
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
@Enselic Enselic deleted the on-broken-pipe branch May 4, 2024 08:27
@Enselic Enselic mentioned this pull request May 4, 2024
23 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-unix Operating system: Unix-like S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants