The initial wording does not make sense due to an extra 'to'.

There are two potential candidates we can change this to:
 - 'you can import it into scope'
 - 'to import it into scope'

In keeping the changes minimal, we choose the first, as this is more in line with the grammar of the extended candidates help message.

Fix floating point fast-math intrinsics

The implementation did not handle the case where both operands were constants, which caused an llvm assertion:

```
rustc: //buildslave//rust-buildbot//slave//nightly-dist-rustc-musl-linux//build//src//llvm//include/llvm/Support/Casting.h:237:
typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Instruction; Y = llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Instruction*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
```

Change compare_exchange to return a Result<T, T>

As per the discussion in #31767

I also changed the feature name from `extended_compare_and_swap` to `compare_exchange`.

r? @alexcrichton

std: Revert addition of `into_ascii_*` methods

The addition of these methods in #31335 required adding impls of the trait for
the `String` and `Vec<T>` types. This unfortunately caused a regression (#32074)
in type inference for using these methods which the libs team has decided to not
push forward with. These methods were stabilized in #32020 which was intended to
get backported to beta, but the backport hasn't happened just yet. This commit
reverts both the addition and stabilization of these methods.

One proposed method of handling this, in #32076, was to move the methods to an
extra trait to avoid conflicts with type inference. After some discussion,
however, the libs team concluded that we probably want to reevaluate what we're
doing here, so discussion will continue on the tracking issue, #27809.

Closes #32074

Rollup of 14 pull requests

- Successful merges: #32265, #32269, #32271, #32288, #32308, #32316, #32319, #32321, #32327, #32329, #32332, #32337, #32342, #32347
- Failed merges:

Fix volatile stores of fat pointers

This was previously causing an LLVM assertion.

r? @EddyB

Use explicit -march flags in the i586 mk file

`-march` should definitely go last, after the environment `$C(XX)FLAGS`, or it's going to remain brittle.

This should fix cross-compilation issues on x86_64 (possibly x86 too on some newer distros) - it was far too assuming of me to expect you really had to want i586 using your own flags.

Update LLVM to include a backport to restore AA performance

cc #31435
r? @alexcrichton

liveness: substitute bound regions with free ones before normalizing the return type

Fixes #32323

r? @arielb1

Make AssertRecoverSafe's field public

It's basically the very definition of a newtype, so we might as well
make things easy on people and let them construct and access it
directly.

r? @aturon

Minor phrasing adjustment to book references-and-borrowing

rustbuild: Fix cross to netbsd from Linux

Apparently the NetBSD compiler-rt builds into the linux directory as well.
I'm... detecting a trend!

documentation fix in RELEASES.md

f32 should probably be denoted as 0.0 as it might improve readability.

docs: `let` introduces a statement

I changes *expression* to *statement* to make more accurate, because in Rust, `let` introduces a declaration statement.

Fix usability problem when browse document locally

You cannot use `history.replaceState` when you browse locally, it breaks the security policy of Chrome and perhaps other browsers.
Closes https://github.com/rust-lang/rust/issues/32307
Thank @crumblingstatue for the help!

docs: One typo

I think it's a mistake of spelling.

Add comment about opt-in nature of compiletest note/help messages.

The opt-in functionality was proposed and discussed in
https://github.com/rust-lang/rust/issues/21195

syntax: impl ToTokens for P<ast::ImplItem>

I'm working on updating zinc for latest rust, and it appears that I need this impl[0].

More generally, I realise that libsyntax is "Whatever the compiler team needs to build a compiler", but should I just open a PR fleshing this out for all types?

https://github.com/hackndev/zinc/blob/master/ioreg/src/builder/setter.rs#L194-L197

FreeBSD has already supported Cargo

Both Packages and Ports of FreeBSD have Cargo in present.

test: Fix missing call of function pointer

Also an unused variable warning was here.

Add intrinsics for float arithmetic with `fast` flag enabled

Add intrinsics for float arithmetic with `fast` flag enabled

`fast` a.k.a UnsafeAlgebra is the flag for enabling all "unsafe"
(according to llvm) float optimizations.

See LangRef for more information http://llvm.org/docs/LangRef.html#fast-math-flags

Providing these operations with less associativity rules (for example)
is useful to numerical applications.

For example, the summation loop:

    let sum = 0.;
    for element in data {
        sum += *element;
    }

Using the default floating point semantics, this loop expresses that the
floats must be added in a sequence, one after another. This constraint
is usually completely unintended, and it means that no auto-vectorization
is possible.

Add an impl for From trait

Converts a u8 slice to a Ipv4Addr
More discussion on this here: https://github.com/rust-lang/rfcs/pull/1498#issuecomment-191921655

`-march` should definitely go last, after the environment C(XX)FLAGS, or it's back to square one.
This fixes cross-compilation issues on x86_64.

derive: Avoid emitting provided PartialEq, PartialOrd methods for c-like enums

derive: Avoid emitting provided PartialEq, PartialOrd method for c-like enums

`ne` is completely symmetrical with the method `eq`, and we can save
rust code size and compilation time here if we only emit one of them
when possible.

One case where it's easy to recognize is when it's a C-like enum. Most
other cases can not omit ne, because any value field may have a custom
PartialEq implementation.

Change inherent overlap error to a warning for now, to ease the breakage

Closes #32247

r? @nikomatsakis

`fast` a.k.a UnsafeAlgebra is the flag for enabling all "unsafe"
(according to llvm) float optimizations.

See LangRef for more information http://llvm.org/docs/LangRef.html#fast-math-flags

Providing these operations with less precise associativity rules (for
example) is useful to numerical applications.

For example, the summation loop:

    let sum = 0.;
    for element in data {
        sum += *element;
    }

Using the default floating point semantics, this loop expresses the
floats must be added in a sequence, one after another. This constraint
is usually completely unintended, and it means that no autovectorization
is possible.

Adjustments to the panic hook API

Rename `set_handler` and `take_handler` to `set_hook` and `take_hook` since we're not actually "handling" (i.e. fixing) anything.

Also alter `set_hook` to take a `Box<Fn(&PanicInfo) + 'static + Sync + Send>` rather than a parameterized closure since there's otherwise no easy way to re-register a hook that came from `take_hook`.

cc #30449

r? @aturon

cc #31435

Refactor call & function handling in trans, enable MIR bootstrap.

Non-Rust and Rust ABIs were combined into a common codepath, which means:
* The ugly `__rust_abi` "clown shoes" shim for C->Rust FFI is gone, fixes #10116.
* Methods, *including virtual ones* support non-Rust ABIs, closes #30235.
* Non-Rust ABIs also pass fat pointers in two arguments; the result should be identical.
* Zero-sized types are never passed as arguments; again, behavior shouldn't change.

Additionally, MIR support for calling intrinsics (through old trans) was implemented.
Alongside assorted fixes, it enabled MIR to launch 🚀 and do a *complete* bootstrap.
To try it yourself, `./configure --enable-orbit` *or* `make RUSTFLAGS="-Z orbit"`.

Fixes #32323

Expose the key of Entry variants for HashMap and BTreeMap.

This PR addresses [issue 1541](https://github.com/rust-lang/rfcs/issues/1541) by exposing the key of `HashMap` and `BTreeMap` entry variants. Basic tests are provided.