There is discussion of this in #40230 which requests clarification.
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

In the docs for intrinsics::abort():

 * Strengthen the recommendation by to use process::abort instead.
 * Document the fact that it (ab)uses an LLVM debug trap and what the
   likely consequences are.
 * State that the precise behaviour is unstable.

In the docs for process::abort():

 * Promise that we have the same behaviour as C `abort()`.
 * Document the likely consequences, including, specifically, the
   consequences on Unix.

In the internal comment for unix::abort_internal:

 * Refer to the public docs for the public API functions.
 * Correct and expand the description of libc::abort.  Specifically:
 * Do not claim that abort() unregisters signal handlers.  It doesn't;
   it honours the SIGABRT handler.
 * Discuss, extensively, the issue with abort() flushing stdio buffers.
 * Describe the glibc behaviour in some detail.
Co-authored-by: NMark Wooding <mdw@distorted.org.uk>
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

Now that arrays implement `IntoIterator`, using
`&` is no longer necessary. This makes examples
easier to understand.

Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

Co-authored-by: NJane Lusby <jlusby@yaah.dev>

Co-authored-by: NJosh Triplett <josh@joshtriplett.org>

It is unergnomic to have to say things like
   bad.into_status().signal()

Implementing `ExitStatusExt` for `ExitStatusError` fixes this.
Unfortunately it does mean making a previously-infallible method
capable of panicing, although of course the existing impl remains
infallible.

The alternative would be a whole new `ExitStatusErrorExt` trait.

`<ExitStatus as ExitStatusExt>::into_raw()` is not particularly
ergonomic to call because of the often-required type annotation.
See for example the code in the test case in
  library/std/src/sys/unix/process/process_unix/tests.rs

Perhaps we should provide equivalent free functions for `ExitStatus`
and `ExitStatusExt` in std::os::unix::process and maybe deprecate this
trait method.  But I think that is for the future.
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

Closes #73125

This is in pursuance of
  Issue #73127 Consider adding #[must_use] to std::process::ExitStatus

In
  MR #81452 Add #[must_use] to [...] process::ExitStatus
we concluded that the existing arrangements in are too awkward
so adding that #[must_use] is blocked on improving the ergonomics.

I wrote a mini-RFC-style discusion of the approach in
  https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

It's possible to create a deadlock with stdin/stdout I/O on a single thread:

* the child process may fill its stdout buffer, and have to wait for the parent process to read it,
* but the parent process may be waiting until its stdin write finishes before reading the stdout.

Therefore, the parent process should use separate threads for writing and reading.

The use of `ExitStatus` as the Rust type name for a Unix *wait
status*, not an *exit status*, is very confusing, but sadly probably
too late to change.

This area is confusing enough in Unix already (and many programmers
are already confuxed).  We can at least document it.

I chose *not* to mention the way shells like to exit with signal
numbers, thus turning signal numbers into exit statuses.  This is only
relevant for Rust programs using `std::process` if they run shells.
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

Co-authored-by: NMara Bos <m-ou.se@m-ou.se>

Co-authored-by: NDavid Tolnay <dtolnay@gmail.com>

Fixes #73836

Also doing fmt inplace as requested.

As a relative beginner, it took a while for me to figure out I could just steal the references to avoid partially moving the child and thus retain ability to call functions on it (and store it in structs etc).

These links were broken before.

When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.

Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594

This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd *that are not involved in any currently open PR* to
minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8

With the list of files from the script in outstanding_files, the
relevant commands were:

    $ find src/libstd -name '*.rs' \
        | xargs rustfmt --edition=2018 --unstable-features --skip-children
    $ rg libstd outstanding_files | xargs git checkout --

Repeating this process several months apart should get us coverage of
most of the rest of libstd.

To confirm no funny business:

    $ git checkout $THIS_COMMIT^
    $ git show --pretty= --name-only $THIS_COMMIT \
        | xargs rustfmt --edition=2018 --unstable-features --skip-children
    $ git diff $THIS_COMMIT  # there should be no difference