Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of
`Option<T>` one can guarantee are optimised to a single pointer.

Co-authored-by: Ralf Jung <[email protected]>

Co-authored-by: Ralf Jung <[email protected]>

…stead of whole format string

0.4.2 -> 0.4.3

- Suggest `x.py setup` if config.toml doesn't exist yet (twice, once
before and once after the build)
- Prompt for a profile if not given on the command line
- Print the configuration file that will be used
- Print helpful starting commands after setup
- Link to the dev-guide after finishing
- Note that distro maintainers will see the changelog warning

The (internal) std::io::lazy::Lazy was used to lazily initialize the
stdout and stdin buffers (and mutexes). It uses atexit() to register a
destructor to flush the streams on exit, and mark the streams as
'closed'. Using the stream afterwards would result in a panic.

Stdout uses a LineWriter which contains a BufWriter that will flush the
buffer on drop. This one is important to be executed during shutdown,
to make sure no buffered output is lost. It also forbids access to
stdout afterwards, since the buffer is already flushed and gone.

Stdin uses a BufReader, which does not implement Drop. It simply forgets
any previously read data that was not read from the buffer yet. This
means that in the case of stdin, the atexit() function's only effect is
making stdin inaccessible to the program, such that later accesses
result in a panic. This is uncessary, as it'd have been safe to access
stdin during shutdown of the program.

---

This change removes the entire io::lazy module in favour of
SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic
operation) than locking a sys_common::Mutex on every access like Lazy
did.

However, SyncOnceCell does not use atexit() to drop the contained object
during shutdown.

As noted above, this is not a problem for stdin. It simply means stdin
is now usable during shutdown.

The atexit() call for stdout is moved to the stdio module. Unlike the
now-removed Lazy struct, SyncOnceCell does not have a 'gone and
unusable' state that panics. Instead of adding this again, this simply
replaces the buffer with one with zero capacity. This effectively
flushes the old buffer *and* makes any writes afterwards pass through
directly without touching a buffer, making print!() available during
shutdown without panicking.

The main use case of TrustedLen is allowing APIs to specialize on it,
but no use of it uses that specialization. Instead, only the .len()
function provided by ExactSizeIterator is used, which is already
required to be accurate.

Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.

The syscalls returning a new file descriptors generally use
lowest-numbered file descriptor not currently opened, without any
exceptions for those corresponding to the standard streams.

Previously when any of standard streams has been closed before starting
the application, operations on std::io::{stderr,stdin,stdout} objects
were likely to operate on other logically unrelated file resources
opened afterwards.

Avoid the issue by reopening the standard streams when they are closed.

It's called `span` elsewhere in the compiler and `span` is also less
surprising. `whence` is whimsical, but not super clear :)

Reopen standard file descriptors when they are missing on Unix

The syscalls returning a new file descriptors generally return lowest-numbered
file descriptor not currently opened, without any exceptions for those
corresponding to stdin, sdout, or stderr.

Previously when any of standard file descriptors has been closed before starting
the application, operations on std::io::{stderr,stdin,stdout} were likely to
either succeed while being performed on unrelated file descriptor, or fail with
EBADF which is silently ignored.

Avoid the issue by using /dev/null as a replacement when the standard file
descriptors are missing.

The implementation is based on the one found in musl. It was selected among a
few others on the basis of the lowest overhead in the case when all descriptors
are already present (measured on GNU/Linux).

Closes #57728.
Closes #46981.
Closes #60447.

Benefits:
* Makes applications robust in the absence of standard file descriptors.
* Upholds IntoRawFd / FromRawFd safety contract (which was broken previously).

Drawbacks:
* Additional syscall during startup.
* The standard descriptors might have been closed intentionally.
* Requires /dev/null.

Alternatives:
* Check if stdin, stdout, stderr are opened and provide no-op substitutes in std::io::{stdin,stdout,stderr} without reopening them directly.
* Leave the status quo, expect robust applications to reopen them manually.

…lnay

Explicitly document the size guarantees that Option makes.

Triggered by a discussion on wg-unsafe-code-guidelines about which layouts of `Option<T>` one can guarantee are optimised to a single pointer.

CC @RalfJung

Point at named argument not found when using `format_args_capture` instead of whole format string

Add `x.py setup`

Closes #76503.

- Suggest `x.py setup` if config.toml doesn't exist yet
- Prompt for a profile if not given on the command line
- Print the configuration that will be used
- Print helpful starting commands after setup
- Link to the dev-guide after finishing

Add accessors to Command.

This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](https://github.com/rust-lang/cargo/blob/13b73cdaf76b2d9182515c9cf26a8f68342d08ef/src/cargo/util/process_builder.rs#L105-L134) in Cargo.

Possible concerns about the API:
- Values with NULs on Unix will be returned as `"<string-with-nul>"`. I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept in `Command`.
- Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it, it can be added to `CommandExt` as a separate method.
- Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone.
- Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return a `Option<Option<&OsStr>>`?).
- `get_envs` could skip "cleared" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't display `None` entries. I erred on the side of providing extra information, but I suspect many situations will just filter out the `None`s.
- Could implement more iterator stuff (like `DoubleEndedIterator`).

I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed.

cc #44434

…ter, r=Dylan-DPC

Add missing code examples on slice iter types

r? @Dylan-DPC

Update mdBook

0.4.2 -> 0.4.3

Also updated version requirement in `Cargo.toml` from 0.4.0 to 0.4.3.

Update cargo

7 commits in 8777a6b1e8834899f51b7e09cc9b8d85b2417110..05c611ae3c4255b7a2bcf4fcfa65b20286a07839
2020-09-15 19:11:03 +0000 to 2020-09-23 23:10:38 +0000
- --workspace flag for locate-project to find the workspace root (rust-lang/cargo#8712)
- Remove some badges documentation. (rust-lang/cargo#8727)
- Add plain message format for locate-project (rust-lang/cargo#8707)
- Add a term option to configure the progress bar (rust-lang/cargo#8165)
- Replace d_as_f64 with as_secs_f64 (rust-lang/cargo#8721)
- Add cross check to filters_target test. (rust-lang/cargo#8713)
- Add test for whitespace behavior in env flags. (rust-lang/cargo#8706)

Remove std::io::lazy::Lazy in favour of SyncOnceCell

The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit, and mark the streams as 'closed'. Using the stream afterwards would result in a panic.

Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown, to make sure no buffered output is lost. It also forbids access to stdout afterwards, since the buffer is already flushed and gone.

Stdin uses a BufReader, which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin, the atexit() function's only effect is making stdin inaccessible to the program, such that later accesses result in a panic. This is uncessary, as it'd have been safe to access stdin during shutdown of the program.

---

This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did.

However, SyncOnceCell does not use atexit() to drop the contained object during shutdown.

As noted above, this is not a problem for stdin. It simply means stdin is now usable during shutdown.

The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct, SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again, this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer, making print!() available during shutdown without panicking.

---

In addition, because the contents of the SyncOnceCell are no longer dropped, we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()`, since Lazy effectively stored a `Box<Arc<T>>`, and SyncOnceCell stores the `T` directly.

Remove TrustedLen requirement from BuilderMethods::switch

The main use case of TrustedLen is allowing APIs to specialize on it,
but no use of it uses that specialization. Instead, only the .len()
function provided by ExactSizeIterator is used, which is already
required to be accurate.

Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.

update Miri

Fixes #77130

Remove stray word from `ClosureKind::extends` docs

Rename `whence` to `span`

It's called `span` elsewhere in the compiler and `span` is also less
surprising. `whence` is whimsical, but not super clear :)

See [this Discord conversation](https://discord.com/channels/442252698964721669/459149231702278154/758731658689511444) for more.

r? @jyn514