Rename std::ptr::Shared to NonNull and stabilize it
This implements the changes proposed at https://github.com/rust-lang/rust/issues/27730#issuecomment-352800629:
> * Rename `Shared<T>` to `NonNull<T>` and stabilize it. (Being in the `ptr` module is enough to say that it’s a pointer. I’m not very attached to this specific name though.)
> * Rename `Box<T>` methods ~~`from_unique`~~/`into_unique` to ~~`from_nonnull`~~/`into_nonnull` (or whatever names are deemed appropriate), replace `Unique<T>` with `NonNull<T>` in their signatures, and stabilize them.
> * Replace `Unique<T>` with `NonNull<T>` in the signatures of methods of the `Alloc` trait.
> * Mark `Unique` “permanently-unstable” by replacing remaining occurrences of `#[unstable(feature = "unique", issue = "27730")]` with:
>
> ```rust
> #[unstable(feature = "ptr_internals", issue = "0", reason = "\
> use NonNull instead and consider PhantomData<T> (if you also use #[may_dangle]), \
> Send, and/or Sync")]
> ```
>
> (Maybe the `reason` string is only useful on the struct definition.) Ideally it would be made private to some crate instead, but it needs to be used in both liballoc and libstd.
> * (Leave `NonZero` and `Zeroable` unstable for now, and subject to future bikeshedding.)
Thew `_raw` prefix is included because the fact that `Box`’s ownership
semantics are "dissolved" or recreated seem more important than the exact
parameter type or return type.
- use consistent phrasing for expected and found arguments
- suggest changing arugments to tuple if possible
- suggest changing single tuple argument to arguments if possible
LLVM <= 4.0 used a non-standard interpretation of `DW_OP_plus`. In the
DWARF standard, this adds two items on the expressions stack. LLVM's
behavior was more like DWARF's `DW_OP_plus_uconst` -- adding a constant
that follows the op. The patch series starting with [D33892] switched
to the standard DWARF interpretation, so we need to follow.
[D33892]: https://reviews.llvm.org/D33892
Speed up leb128 encoding and decoding for unsigned values.
Make the implementation for some leb128 functions potentially faster.
@Mark-Simulacrum, could you please trigger a perf.rlo run?
This is a forward-port of:
* 9426dda83d7a928d6ced377345e14b84b0f11c21
* cbfb9858951da7aee22d82178405306fca9decb1
from the beta branch which is used to automatically calculate the beta number
based on the number of merges to the beta branch so far.
