Currently, on Nightly, this panics:

```
use std::process::ExitStatus;
use std::os::unix::process::ExitStatusExt;

fn main() {
    let st = ExitStatus::from_raw(0x007f);
    println!("st = {}", st);
}
```

This is because the impl of Display assumes that if .code() is None,
.signal() must be Some.  That was a false assumption, although it was
true with buggy code before
  5b1316f
  unix ExitStatus: Do not treat WIFSTOPPED as WIFSIGNALED

This is not likely to have affected many people in practice, because
`Command` will never produce such a wait status (`ExitStatus`).

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

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

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: Ian Jackson <ijackson@chiark.greenend.org.uk>

MacOS uses a different representation.

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

If different unices have different bit patterns for WIFSTOPPED and
WIFCONTINUED then simply being glibc is probably not good enough for
this rather ad-hoc test to work.  Do it on Linux only.

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

I strongly disagree with tidy in this case but AIUI there is no way to
override it.

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

Add powerpc-unknown-openbsd target

* Fix missing abi::endian crate
* Missing platform-support.md

Rustdoc almost never needs a full stage 2 compiler, and requiring
rustdoc tests to be in run-make-fulldeps adds a lot of compile time for
no reason.

…itionally

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

LLVM requires at least cmake 3.13.4 and cmake is only required to build
LLVM.

Also closes rust-lang#42555

I'm still not totally sure if this is the right way to implement the memcpy, but that portion
compiles correctly now. Now to fix the compile errors everywhere else :).

This updates all places where match branches check on StatementKind or UseContext.
This doesn't properly implement them, but adds TODOs where they are, and also adds some best
guesses to what they should be in some cases.

Changed to various implementations, copying the style of prior function calls in places I was
unsure of.

Also one minor style nit.

Fixes copy_non_overlapping codegen_ssa to properly handle pointees,
and use bytes instead of elem count

This replaces where it was previously being constructed in intrinsics, with direct construction
of the Statement.

It was suggested to lower this in MIR instead of ssa, so do that instead.

Instead of looking for `std::prelude::v1`, this changes it to look for
`std::prelude::<anything>`.

Also add some span_bugs where it is unreachable

Add StatementKind::CopyNonOverlapping

Implements rust-lang/compiler-team#348

r? `@nagisa`

…_unsafe_fn, r=nikomatsakis

Stabilize `unsafe_op_in_unsafe_fn` lint

This makes it possible to override the level of the `unsafe_op_in_unsafe_fn`, as proposed in rust-lang#71668 (comment).

Tracking issue: rust-lang#71668
r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung```

# Stabilization report

This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`.

## Summary

Currently, the body of unsafe functions is an unsafe block, i.e. you can perform unsafe operations inside.

The `unsafe_op_in_unsafe_fn` lint, stabilized here, can be used to change this behavior, so performing unsafe operations in unsafe functions requires an unsafe block.

For now, the lint is allow-by-default, which means that this PR does not change anything without overriding the lint level.

For more information, see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md)

### Example

```rust
// An `unsafe fn` for demonstration purposes.
// Calling this is an unsafe operation.
unsafe fn unsf() {}

// #[allow(unsafe_op_in_unsafe_fn)] by default,
// the behavior of `unsafe fn` is unchanged
unsafe fn allowed() {
    // Here, no `unsafe` block is needed to
    // perform unsafe operations...
    unsf();

    // ...and any `unsafe` block is considered
    // unused and is warned on by the compiler.
    unsafe {
        unsf();
    }
}

#[warn(unsafe_op_in_unsafe_fn)]
unsafe fn warned() {
    // Removing this `unsafe` block will
    // cause the compiler to emit a warning.
    // (Also, no "unused unsafe" warning will be emitted here.)
    unsafe {
        unsf();
    }
}

#[deny(unsafe_op_in_unsafe_fn)]
unsafe fn denied() {
    // Removing this `unsafe` block will
    // cause a compilation error.
    // (Also, no "unused unsafe" warning will be emitted here.)
    unsafe {
        unsf();
    }
}
```

Fixes to ExitStatus and its docs

* On Unix, properly display every possible wait status (and don't panic on weird values)
* In the documentation, be clear and consistent about "exit status" vs "wait status".

Add powerpc-unknown-openbsd target

…rk-Simulacrum

Build rustdoc for run-make tests, not just run-make-fulldeps

Rustdoc almost never needs a full stage 2 compiler, and requiring
rustdoc tests to be in run-make-fulldeps adds a lot of compile time for
no reason.

This is the same change from rust-lang#81197, but separated into its own PR. I ran into this again today while working on rust-lang/docs.rs#1302.
r? ```@Mark-Simulacrum```

…=joshtriplett

Add Option::get_or_default

Tracking issue: rust-lang#82901

The original issue is rust-lang#55042, which was closed, but for an invalid reason (see discussion there). Opening this to reconsider (I hope that's okay). It seems like the only gap for `Option` being "entry-like".

I ran into a need for this method where I had a `Vec<Option<MyData>>` and wanted to do `vec[n].get_or_default().my_data_method()`. Using an `Option` as an inner component of a data structure is probably where the need for this will normally arise.

…=jonas-schievink

⬆️ rust-analyzer

…_readme, r=Mark-Simulacrum

Update README.md to use the correct cmake version number

LLVM requires at least cmake 3.13.4 and cmake is only required to build
LLVM.

https://www.llvm.org/docs/CMake.html

Also closes rust-lang#42555

…imulacrum

Bump tracing-tree dependency

This bump fixes two small rendering things that were annoying me:

* The first level didn't have an opening line
* When wraparound happens, there was no warning, the levels just disappeared. Now there is a line that shows that wraparound is happening

See https://github.com/davidbarsky/tracing-tree/pull/31/files for how the look changes

…de-v1, r=estebank

Don't hardcode the `v1` prelude in diagnostics, to allow for new preludes.

Instead of looking for `std::prelude::v1`, this changes the two places where that was hardcoded to look for `std::prelude::<anything>` instead.

This is needed for rust-lang#82217.

r? `@estebank`