Shipping this tool gives people reliable way to reduce the generated executable size.

I'm not sure if this strip tool is available from the llvm version current rust is built on. But let's take a look. @japaric

They highlight how types are displayed in those cases, and will show
how the current output is altered by the next patch.

…types.

Fixes rust-lang#52097

Respectively.

This is a sequel to November 2017's rust-lang#46103 / 1a9dc2e. It had been
reported (more than once—at least rust-lang#19140, rust-lang#44083, and rust-lang#44565) that the
"never used" language was confusing for enum variants that were "used"
as match patterns, so the wording was changed to say never "constructed"
specifically for enum variants. More recently, the same issue was raised
for structs (rust-lang#52325). It seems consistent to say "constructed" here,
too, for the same reasons.

While we're here, we can also use more specific word "called" for unused
functions and methods. (We declined to do this in rust-lang#46103, but the
rationale given in the commit message doesn't actually make sense.)

This resolves rust-lang#52325.

Specifically, `&self` -> `&mut self` and explicit `ref` -> `ref mut`.
Implicit `ref` isn't handled yet and causes an ICE.

Also teach rustc_borrowck not to show useless help messages like
"use a mutable reference instead: `x`".

Provide llvm-strip in llvm-tools component

Shipping this tool gives people reliable way to reduce the generated executable size.

I'm not sure if this strip tool is available from the llvm version current rust is built on. But let's take a look. @japaric

Implement `Option::replace` in the core library

Here is the implementation of the `Option::replace` method. The first step of [the tracking issue rust-lang#51998](rust-lang#51998).

… r=Kimundi

Update std::ascii::ASCIIExt deprecation notes

Fixes rust-lang#52085

NLL: Suggest `ref mut` and `&mut self`

Fixes rust-lang#51244. Supersedes rust-lang#51249, I think.

Under the old lexical lifetimes, the compiler provided helpful suggestions about adding `mut` when you tried to mutate a variable bound as `&self` or (explicit) `ref`. NLL doesn't have those suggestions yet. This pull request adds them.

I didn't bother making the help text exactly the same as without NLL, but I can if that's important.

(Originally this was supposed to be part of rust-lang#51612, but I got bogged down trying to fit everything in one PR.)

Don't display default generic parameters in diagnostics that compare types

In errors like:
```
   expected type: `RawVec<foo, Global>`
      found type: `foo`
```

`RawVec` being defined as `RawVec<T, A: Alloc = Global>`, the error is better written as
```
   expected type: `RawVec<foo>`
      found type: `foo`
```

In fact, that is already what happens when `foo` is not an ADT, because in that case, the diagnostic handler doesn't try to highlight something, and just uses the `Display` trait instead of its own logic.

e.g.
```
   expected type: `RawVec<usize>`
      found type: `usize`
```

…r=cramertj

Deny bare trait objects in src/librustc_save_analysis

Enforce `#![deny(bare_trait_objects)]` in `src/librustc_save_analysis`.

Deny bare trait objects in librustc_typeck

Enforce `#![deny(bare_trait_objects)]` in `src/librustc_typeck`.

Deny bare trait objects in src/libserialize

Enforce `#![deny(bare_trait_objects)]` in `src/libserialize`.

…lacrum

Deny bare trait objects in librustc_target and libtest

Enforce `#![deny(bare_trait_objects)]` in `src/librustc_target` and `src/libtest`.

Deny bare trait objects in the rest of rust

Add `#![deny(bare_trait_objects)]` to all the modules not covered before (those did not require code changes) that I consider applicable (I left out shims) in order to futureproof them.

…ort-from-stable, r=pietroalbini

Backport 1.27.1 release notes to master

r? @pietroalbini

Fix ICE when using a pointer cast as array size

Fixes rust-lang#52023. I'm not sure if the comment rust-lang#52023 (comment) suggested we also emit `E0080`, but just emitting `E0018` seems reasonable for now.

r? @oli-obk

Resolve FIXME(rust-lang#27942)

[related issue](rust-lang#27942)

cc [rust-lang#44366](rust-lang#44366)

task: remove wrong comments about non-existent LocalWake trait

~~A `LocalWaker` is specifically `!Send `, and the unsafety comment around
`LocalWaker::new` only specifies that it be safe to call `wake_local`.
One could then accidentally promote a `LocalWaker` into a `Waker`, which
is universally `Send`, simply via `Waker::from(local_waker)`. A
`LocalWaker` the was built expecting to not be `Send`, such as using
`Rc`, could be sent to other threads safely.~~

~~Separately, though somewhat related, `Context` holds a `&LocalWaker`
internally, and exposes a `waker() -> &Waker` method. This simply
transmutes the `&LocalWaker` to `&Waker`, which would be unsound, except
that you can't "send" a `&Waker`, you'd need to clone it first. Since
`UnsafeWake::clone_raw` requires that it return a `Waker`, the transmute
is not unsound. The transmuted `LocalWaker` will be promoted to a
`Waker` correctly.~~

~~That would mean that if `UnsafeWake::clone_raw` were to be changed, such
as returning `Self` instead of `Waker`, this would no longer be sound.
Thus, this also adds a comment to `clone_raw` to remember this.~~

r? @cramertj

…excrichton

Update llvm-rebuild-trigger in light of LLVM 7 upgrade

Not triggering a LLVM rebuild [since the LLVM 7 upgrade](rust-lang#51966 (comment)) causes builds of rustc to fail.

r? @alexcrichton

…y_2_electric_boogaloo, r=pnkfelix

dead-code lint: say "constructed", "called" for structs, functions

Respectively.

This is a sequel to November 2017's rust-lang#46103 / 1a9dc2e. It had been
reported (more than once—at least rust-lang#19140, rust-lang#44083, and rust-lang#44565) that the
"never used" language was confusing for enum variants that were "used"
as match patterns, so the wording was changed to say never "constructed"
specifically for enum variants. More recently, the same issue was raised
for structs (rust-lang#52325). It seems consistent to say "constructed" here,
too, for the same reasons.

While we're here, we can also use more specific word "called" for unused
functions and methods. (We declined to do this in rust-lang#46103, but the
rationale given in the commit message doesn't actually make sense.)

This resolves rust-lang#52325.