Fixes #31207

by removing abort_if_new_errors

This target covers MIPS devices that run the trunk version of OpenWRT.

The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.

As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.

r? @alexcrichton

fixes failed test (std::os::raw::tests::unix) in x86_64-musl target

r? @steveklabnik

cf #31303

This is a PR for #21195. It changes the way unspecified `help` and `ǹote` messages are handled in compile-fail tests as suggested by @oli-obk in the issue: if there are some `note` or `help` annotations, there must be annotations for all `help` or `note` messages of this test. Maybe it makes also sense to add an option to specify that the this test should fail if there are unspecified `help` or `note` messages.

With this change, the following tests fail:

    [compile-fail] compile-fail/changing-crates.rs
    [compile-fail] compile-fail/default_ty_param_conflict_cross_crate.rs
    [compile-fail] compile-fail/lifetime-inference-give-expl-lifetime-param.rs
    [compile-fail] compile-fail/privacy1.rs
    [compile-fail] compile-fail/svh-change-lit.rs
    [compile-fail] compile-fail/svh-change-significant-cfg.rs
    [compile-fail] compile-fail/svh-change-trait-bound.rs
    [compile-fail] compile-fail/svh-change-type-arg.rs
    [compile-fail] compile-fail/svh-change-type-ret.rs
    [compile-fail] compile-fail/svh-change-type-static.rs
    [compile-fail] compile-fail/svh-use-trait.rs

I'll add the missing annotations if we decide to accept this change.

the previous code generated a temporary of the inner type and assigned the box-memory to it. So if you did `let x: Box<usize> = box 5;` you got a

```rust
let var0: Box<usize>; // x
let mut tmp0: Box<usize>;
let mut tmp1: usize;
...
tmp1 = Box(usize);
(*tmp1) = const 5;
tmp0 = tmp1;
var0 = tmp0;
```

r? @nagisa

I don't believe these test cases have served any purpose in years.

The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.

r? @nikomatsakis

- Successful merges: #31099, #31244, #31280, #31290, #31292, #31294, #31295, #31296
- Failed merges:

Rustdoc will automatically wrap things in main, but this doesn't work
here.

Fixes #31249

These are free functions in the text, but methods in the standard
library.

Fixes #31266

This code was refactored, but the words were not

Fixes #31284

This test has been deadlocking and causing problems on the bots basically since
its inception. Some memory safety issues were fixed in 987dc84b, but the
deadlocks remained afterwards unfortunately.

After some investigation, I've concluded that this is just a situation where OSX
is not guaranteed to run destructors. The fix in 987dc84b observed that OSX was
rewriting the backing TLS memory to its initial state during destruction while
we weren't looking, and this would have the effect of canceling the destructors
of any other initialized TLS slots.

While very difficult to pin down, this is basically what I assume is happening
here, so there doesn't seem to really be anythig we can do to ensure the test
robustly passes on OSX, so just ignore it for now.

We forgot to pass down the `-m64` flag to gcc, so we were actually compiling
powerpc code which would then later fail to link!

Perhaps, it makes more sense to link straight to [Installing on Linux or Mac](https://doc.rust-lang.org/book/getting-started.html#installing-on-linux-or-mac) and [Installing on Windows](https://doc.rust-lang.org/book/getting-started.html#installing-on-windows) sections. Platform Support section could be skipped in case of *quick* start.

This commit refactors the field `Module::children` from mapping `Name` -> `NameBindings` to mapping `(Name, Namespace)` -> `NameBinding` and refactors the field `Module::import_resolutions` from mapping `Name` -> `ImportResolutionPerNamespace` to mapping `(Name, Namespace)` -> `ImportResolution`.

This allows the duplicate checking code to be refactored so that `NameBinding` no longer needs ref-counting or a RefCell (removing the need for `NsDef`).

r? @nikomatsakis

Buildbot was updated long ago to use the correct triples.

The putvar here is emitting garbage into `configure --help` so
I want it gone.

These commits perform a few high-level changes with the goal of enabling i686 MSVC unwinding:

* LLVM is upgraded to pick up the new exception handling instructions and intrinsics for MSVC. This puts us somewhere along the 3.8 branch, but we should still be compatible with LLVM 3.7 for non-MSVC targets.
* All unwinding for MSVC targets (both 32 and 64-bit) are implemented in terms of this new LLVM support. I would like to also extend this to Windows GNU targets to drop the runtime dependencies we have on MinGW, but I'd like to land this first.
* Some tests were fixed up for i686 MSVC here and there where necessary. The full test suite should be passing now for that target.

In terms of landing this I plan to have this go through first, then verify that i686 MSVC works, then I'll enable `make check` on the bots for that target instead of just `make` as-is today.

Closes #25869

This commit transitions the compiler to using the new exception handling
instructions in LLVM for implementing unwinding for MSVC. This affects both 32
and 64-bit MSVC as they're both now using SEH-based strategies. In terms of
standard library support, lots more details about how SEH unwinding is
implemented can be found in the commits.

In terms of trans, this change necessitated a few modifications:

* Branches were added to detect when the old landingpad instruction is used or
  the new cleanuppad instruction is used to `trans::cleanup`.
* The return value from `cleanuppad` is not stored in an `alloca` (because it
  cannot be).
* Each block in trans now has an `Option<LandingPad>` instead of `is_lpad: bool`
  for indicating whether it's in a landing pad or not. The new exception
  handling intrinsics require that on MSVC each `call` inside of a landing pad
  is annotated with which landing pad that it's in. This change to the basic
  block means that whenever a `call` or `invoke` instruction is generated we
  know whether to annotate it as part of a cleanuppad or not.
* Lots of modifications were made to the instruction builders to construct the
  new instructions as well as pass the tagging information for the call/invoke
  instructions.
* The translation of the `try` intrinsics for MSVC has been overhauled to use
  the new `catchpad` instruction. The filter function is now also a
  rustc-generated function instead of a purely libstd-defined function. The
  libstd definition still exists, it just has a stable ABI across architectures
  and leaves some of the really weird implementation details to the compiler
  (e.g. the `localescape` and `localrecover` intrinsics).

This brings some routine upgrades to the bundled LLVM that we're using, the most
notable of which is a bug fix to the way we handle range asserts when loading
the discriminant of an enum. This fix ended up being very similar to f9d4149c
where we basically can't have a range assert when loading a discriminant due to
filling drop, and appropriate flags were added to communicate this to
`trans::adt`.

Buildbot was updated long ago to use the correct triples.

The putvar here is emitting garbage into `configure --help` so
I want it gone.

This target covers MIPS devices that run the trunk version of OpenWRT.

The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.

As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.

closes #21195

Rustdoc will automatically wrap things in main, but this doesn't work
here.

Fixes #31249

These are free functions in the text, but methods in the standard
library.

Fixes #31266

This code was refactored, but the words were not

Fixes #31284

I don't believe these test cases have served any purpose in years.

The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.

This test has been deadlocking and causing problems on the bots basically since
its inception. Some memory safety issues were fixed in 987dc84b, but the
deadlocks remained afterwards unfortunately.

After some investigation, I've concluded that this is just a situation where OSX
is not guaranteed to run destructors. The fix in 987dc84b observed that OSX was
rewriting the backing TLS memory to its initial state during destruction while
we weren't looking, and this would have the effect of canceling the destructors
of any other initialized TLS slots.

While very difficult to pin down, this is basically what I assume is happening
here, so there doesn't seem to really be anythig we can do to ensure the test
robustly passes on OSX, so just ignore it for now.