This commit updates the compiler to not attempt to use jemalloc for platforms
where jemalloc is never enabled. Currently the compiler attempts to link in
jemalloc based on whether `--disable-jemalloc` was specified at build time for
the compiler itself, but this is only the right decision for the host target,
not for other targets.

This still leaves a hole open where a set of target libraries are downloaded
which were built with `--disable-jemalloc` and the compiler is unaware of that,
but this is a pretty rare case so it can always be fixed later.

- Successful merges: #28664, #28673, #28681, #28682, #28688
- Failed merges: 

None

Fixes #28568 

r? @EddyB

Implement AsMut for Vec

Fixes #28549

By putting an "unreachable" instruction into the default arm of a switch
instruction we can let LLVM know that the match is exhaustive, allowing
for better optimizations.

For example, this match:
```rust
pub enum Enum {
    One,
    Two,
    Three,
}

impl Enum {
    pub fn get_disc(self) -> u8 {
        match self {
            Enum::One => 0,
            Enum::Two => 1,
            Enum::Three => 2,
        }
    }
}
```

Currently compiles to this on x86_64:
```asm
  .cfi_startproc
  movzbl  %dil, %ecx
  cmpl  $1, %ecx
  setne %al
  testb %cl, %cl
  je  .LBB0_2
  incb  %al
  movb  %al, %dil
.LBB0_2:
  movb  %dil, %al
  retq
.Lfunc_end0:
```

But with this change we get:
```asm
  .cfi_startproc
  movb  %dil, %al
  retq
.Lfunc_end0:
```

- Successful merges: #28666, #28674, #28677, #28678, #28679, #28680
- Failed merges: #28621

This wasn't complete (you need a `./configure`), and it is already
documented well in the main README.

r? @steveklabnik 

This was non-obvious to me: with no example, I assumed `Electron {}` and
didn't know what else to try when it didn't work.  The correct form is
weird because it looks like you're assigning the struct name rather than
an instance of the struct.

r? @steveklabnik 

The lifetime can be elided here, and I think eliding it makes the example slightly simpler.

the example for `find` was misleading in that it fails to mention the result is either `None` or `Some` containing only the first match. Further confusing the issue is the `println!` statement, "We got some numbers!"

r? @Manishearth 

As discussed in the referenced issues, this PR makes rustc emit `__imp_<symbol>` stubs for all public static data to ensure smooth linking in on `-windows-msvc` targets.  
Resolves #26591, cc #27438

It can never be instantiated, so signify this by having it actually be an empty
`enum`.

cc #27734

Fixes #28568

This commit updates the `MatchIndices` and `RMatchIndices` iterators to follow
the same pattern as the `chars` and `char_indices` iterators. The `matches`
iterator currently yield `&str` elements, so the `MatchIndices` iterator now
yields the index of the match as well as the `&str` that matched (instead of
start/end indexes).

cc #27743

This wasn't complete (you need a `./configure`), and it is already
documented well in the main README.

Also adds a reference to the books that this also generates.

This was non-obvious to me: with no example, I assumed `Electron {}` and
didn't know what else to try when it didn't work.  The correct form is
weird because it looks like you're assigning the struct name rather than
an instance of the struct.

different supertraits can suffer from the same object-safety violation,
leading to duplication in the error message. Avoid it.

Fixes #20692

This adds a new target, `x86_64-rumprun-netbsd`, and related changes to `std`.

Rumprun is a unikernel platform that provides a POSIX-y interface. For the most part, rumprun uses NetBSD's libc and drivers, therefore `target_os` is `netbsd`. However, being a unikernel, rumprun does not support process management, signals or virtual memory, so related functions might fail at runtime. For this reason, stack guards are disabled in `std`.

To support conditional compilation, `target_env` is set to `rumprun`. Maybe `target_vendor` would be technically more fitting, but it doesn't seem to be worth the hassle.

Code for rumprun is always cross-compiled, it uses always static linking and needs a custom linker. The target makes use of the newly introduced `no_default_libs` flag, as the rumprun linker will otherwise not use the correct search path.

Because of type inference, duplicate obligations exist and cause duplicate
errors. To avoid this, only display the first error for each (predicate,span).

The inclusion of the span is somewhat bikesheddy, but *is* the more
conservative option (it does not remove some instability, as duplicate
obligations are ignored by `duplicate_set` under some inference conditions).

Fixes #28098
cc #21528 (is it a dupe?)

the example for `find` was misleading in that it fails to mention the result is either `None` or `Some` containing only the first match. Further confusing the issue is the `println!` statement, "We got some numbers!"

Please see the commits for details.

Live demo: http://www.nickhowell.com/rust/book/

Commit 0bebbab4 should fix #22682

r? @steveklabnik

This PR removes random remaining `Ident`s outside of libsyntax and performs general cleanup
In particular, interfaces of `Name` and `Ident` are tidied up, `Name`s and `Ident`s being small `Copy` aggregates are always passed to functions by value, and `Ident`s are never used as keys in maps, because `Ident` comparisons are tricky.

Although this PR closes https://github.com/rust-lang/rust/issues/6993 there's still work related to it:
- `Name` can be made `NonZero` to compress numerous `Option<Name>`s and `Option<Ident>`s but it requires const unsafe functions.
- Implementation of `PartialEq` on `Ident` should be eliminated and replaced with explicit hygienic, non-hygienic or member-wise comparisons.
- Finally, large parts of AST can potentially be converted to `Name`s in the same way as HIR to clearly separate identifiers used in hygienic and non-hygienic contexts.

r? @nrc 

Fixes #28576

r? @EddyB 

For most parts, rumprun currently looks like NetBSD, as they share the same
libc and drivers. However, being a unikernel, rumprun does not support
process management, signals or virtual memory, so related functions
might fail at runtime. Stack guards are disabled exactly for this reason.

Code for rumprun is always cross-compiled, it uses always static
linking and needs a custom linker.

GDB 7.10 was recently released.

This is mainly to avoid infinite recursion and make debugging more convenient in the anomalous case in which `on_panic` panics.
I encountered such issues while changing libstd to debug/fix part of #28129.

While writing this I was wondering about which functions belong to `panicking` and which to `unwind`.
I placed them in this way mostly because of convenience, but I would strongly appreciate guidance.

cc #27726 

r? @alexcrichton