this commit adds 4 new target definitions to the compiler for easier
cross compilation to ARM Cortex-M devices.

- `thumbv6m-none-eabi`
  - For the Cortex-M0, Cortex-M0+ and Cortex-M1
  - This architecture doesn't have hardware support (instructions) for
    atomics. Hence, the `Atomic*` structs are not available for this
    target.
- `thumbv7m-none-eabi`
  - For the Cortex-M3
- `thumbv7em-none-eabi`
  - For the FPU-less variants of the Cortex-M4 and Cortex-M7
  - On this target, all the floating point operations will be lowered
    software routines (intrinsics)
- `thumbv7em-none-eabihf`
  - For the variants of the Cortex-M4 and Cortex-M7 that do have a FPU.
  - On this target, all the floating point operations will be lowered
    to hardware instructions

No binary releases of standard crates, like `core`, are planned for
these targets because Cargo, in the future, will compile e.g. the `core`
crate on the fly as part of the `cargo build` process. In the meantime,
you'll have to compile the `core` crate yourself. [Xargo] is the easiest
way to do that as in handles the compilation of `core` automatically and
can be used just like Cargo: `xargo build --target thumbv6m-none-eabi`
is all that's needed.

[Xargo]: https://crates.io/crates/xargo

Documentation change to macros.rs for `includes!`

I'm not sure if this documentation is clear or extensive enough, but this is just to get started on the problem, fixes issue #36387.

Update E0220 error format

@jonathandturner
Part of #35233 .
Fixes #35385.

fix out-of-tree rustbuild

See https://github.com/rust-lang/rust/pull/36456#issuecomment-250589906

r? @alexcrichton

Test Case for Incr. Comp. Hash for enums #36674.

Fixes #36674
Part of #36350

r? @michaelwoerister

Update src/compiler-rt to incoporate fix for UB in floatsidf.

Update src/compiler-rt to incoporate fix for UB in floatsidf.

Fix #36518

Rollup of 6 pull requests

- Successful merges: #36865, #36872, #36873, #36877, #36880, #36882
- Failed merges:

Syntax breaking batch

None

 First step for #34761

 Contains a syntax-[breaking-change] as a separate commit (cc #31645).nnAlso renames slice patterns from `PatKind::Vec` to `PatKind::Slice`.

 This commit makes the return type of AstBuilder.stmt_let_typed match the return type of other AstBuilder.stmt* functions. This avoids unnecessary boxing/unboxing whenever Stmt's are stored in a Vec, which is the default use case.nnThis is a potentially plugin breaking change.

resolve: fix incorrect code in `module_to_string`

Fixes #36881.
r? @nrc or @EddyB

impl Debug for raw pointers to unsized data

`?Sized` was missing from these impls for seemingly no reason.

Fixes #36870.

Fix RUSTC_VERSION for 'documenting' build stage.

Previously the `env!("RUSTC_VERSION")` requirement would break the "Documenting rustc_metadata" stage of the rustc build, since that environment variable is only defined during the main build.

r? @EddyB

Update E0035, E0036 and E0370 to new error format

Fixes #35634.
Fixes #35206.
Fixes #35207.

r? @jonathandturner

A couple refactorings in librustdoc.

None

Haiku: Fix target triplet delimiter

SO_NOSIGPIPE and MSG_NOSIGNAL (rebased #36426)

I'm not sure what happened when I pushed a rebased branch on #36426 , github closed it...

Working asmjs and wasm targets

This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.

It does a few things:

- Updates LLVM with the emscripten [fastcomp](https://github.com/rust-lang/llvm/pull/50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
- Teaches rustbuild to correctly link C code with emscripten
- Updates gcc-rs to work correctly with emscripten
- Teaches rustbuild to run crate tests for emscripten with node
- Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
- Modifies libtest to run in single-threaded mode for emscripten
- Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
- Updates libc with wasm32 definitions (presently the same as asmjs)
- Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm

Notes and caveats:

- This is only known to work with `--enable-rustbuild`.
- The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node https://github.com/kripken/emscripten/issues/4542, but hello.rs does seem to work when run on node via the binaryen interpreter
- This requires an up to date installation of the emscripten sdk from its incoming branch
- Unwinding is very broken
- When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host

Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.

https://github.com/rust-lang/rust/issues/36317 tracks work on this.

Fixes https://github.com/rust-lang/rust/issues/36515
Fixes https://github.com/rust-lang/rust/issues/36515
Fixes https://github.com/rust-lang/rust/issues/36356

rustc: More fixes for arch-independent hashing

In another attempt to fix #36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.

Closes #36793 (hopefully)

Previously the `env!("RUSTC_VERSION")` requirement would break the
"Documenting rustc_metadata" stage of the rustc build, since that
environment variable is only defined during the main build.

In another attempt to fix #36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.

Closes #36793 (hopefully)

This is a hack to support building targets that don't support jemalloc
alongside hosts that do. The jemalloc build is controlled by a feature
of the std crate, and if that feature changes between targets, it
invalidates the fingerprint of std's build script (this is a cargo
bug); so we must ensure that the feature set used by std is the same
across all targets, which means we have to build the alloc_jemalloc
crate for targets like emscripten, even if we don't use it.

Doing this step for the target results in the build system
trying to build rustc for asmjs, which doesn't work.