Cleanup Deref impls and add ?Sized bound to &mut T impls

Remove outdated rustdoc PinBox tests

Cleanup and fix method resolution issue

Update to a new pinning API.

Auto merge of #53758 - oli-obk:clippy, r=kennytm

Update clippy submodule

r? @Manishearth @nrc @kennytm

Add more features to the workspace so that all tools pick up on it

Update clippy submodule

Auto merge of #53245 - michaelwoerister:thinlto-rust-llvm, r=alexcrichton

[experimental]: Build LLVM with ThinLTO enabled (2nd attempt)

This is https://github.com/rust-lang/rust/pull/51207 revived. This time, I'd like to run actual performance tests to see if it improves compile times.

bootstrap: Link LLVM tools dynamically in order to save time in ThinLTO builds.

Auto merge of #53711 - arielb1:macro-table, r=michaelwoerister

create a valid DefIdTable for proc macro crates

At least the incremental compilation code, and a few other places in the
compiler, require the CrateMetadata for a loaded target crate to contain a
valid DefIdTable for the DefIds in the target.

Previously, the CrateMetadata for a proc macro contained the crate's
"host" DefIdTable, which is of course incompatible with the "target"
DefIdTable, causing ICEs. This creates a DefIdTable that properly refers
to the "proc macro" DefIds.

Fixes #49482.

r? @michaelwoerister

Should we beta-nominate this?

Auto merge of #53684 - alexcrichton:suggest-remove, r=oli-obk

rustc: Suggest removing `extern crate` in 2018

This commit updates the `unused_extern_crates` lint to make automatic
suggestions about removing `extern crate` annotations in the 2018 edition. This
ended up being a little easier than originally though due to what's likely been
fixed issues in the resolver!

Closes #52829

Auto merge of #53659 - nnethercote:rm-AccumulateVec, r=Mark-Simulacrum

Remove `AccumulateVec` and its uses.

It's basically just a less capable version of `SmallVec`.

FWIW, the only use of `ArrayVec` is now within `HybridIdxSet`.

r? @Mark-Simulacrum

Auto merge of #53642 - alexcrichton:fix-target-cpu-native, r=arielb1

Fix warnings about the `native` target-cpu

This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.

This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.

Closes #53322

Auto merge of #53671 - RalfJung:miri-refactor, r=oli-obk

Miri engine cleanup

* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
      uses "lazy" `AllocType::Static` when encountering a static.  Acessing that
      static invokes CTFE (no matter the machine).  The machine only has any
      influence when writing to a static, which CTFE outright rejects (but miri
      makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
      making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
      just has to find the MIR (or entirely take care of everything); pushing the
      new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
      have to reimplement them.
* Allow Machine to hook into foreign statics (used by miri to get rid of some other hacks).
* Clean up function calling.
* Switch const sanity check to work on operands, not mplaces.
* Move const_eval out of rustc_mir::interpret, to make sure that it does not access private implementation details.

In particular, we can finally make `eval_operand` take `&self`. :-)

Should be merged after https://github.com/rust-lang/rust/pull/53609, across which I will rebase.

Remove `AccumulateVec` and its uses.

It's basically just a less capable version of `SmallVec`.

Fix warnings about the `native` target-cpu

This fixes a regression from #53031 where specifying `-C target-cpu=native` is
printing a lot of warnings from LLVM about `native` being an unknown CPU. It
turns out that `native` is indeed an unknown CPU and we have to perform a
mapping to an actual CPU name, but this mapping is only performed in one
location rather than all locations we inform LLVM about the target CPU.

This commit centralizes the mapping of `native` to LLVM's value of the native
CPU, ensuring that all locations we inform LLVM about the `target-cpu` it's
never `native`.

Closes #53322

first test const-ness, then hook fn call

fix const_prop detecting unary neg underflows

restructure unary_op to also dispatch on type first; fix promotion with unary '-' overflowing

fix unsized extern types

address nits

Auto merge of #53679 - japaric:cortex-r, r=alexcrichton

add more Cortex-R targets

This expands on PR #53663 to complete the set of Cortex-R targets and builds
rust-std components for them.

r? @alexcrichton

each extra rust-std component (there's 4 of them) takes about 3 minutes to build
on my local machine. In terms of stability (LLVM codegen bugs) these new targets
should be as stable as the Cortex-M ones (e.g. `thumbv7m-none-eabi`).

If the extra build time is too much we can leave the rust-std components out for
now

closes #53663
cc @paoloteti

Auto merge of #53493 - matthewjasper:hair-spans, r=nikomatsakis

Use smaller span for adjustments on block expressions

When returning a mutable reference don't use the entire body of the function as the span for the adjustments at the end.

The error [in this case](https://github.com/rust-lang/rust/compare/master...matthewjasper:hair-spans?expand=1#diff-ecef8b1f15622fb48a803c9b61605c78) is worse, but neither error message is really what we want. I have some ideas on how to get a better error message that will have to wait for a future PR.

Auto merge of #53314 - nikomatsakis:nll-invert-liveness, r=pnkfelix

NLL: experiment with inverting liveness

I got inspired to see what would happen here.

Fixes #52460

r? @pnkfelix

Fix definition of `LocalUseMapBuild` so that it can build under stage0,
which does not have as many feature gates enabled.

Auto merge of #53616 - varkor:hir-map-rename, r=nikomatsakis

Restructure hir::map::Node and hir::map::Entry

- Moves `hir::map::Node` to `hir::Node` and removes the `Node*` prefix from its variants.
- Changes `hir::map::Entry` to a struct `hir::map::Entry`.
- Removes the `Node*` prefix from each of `AnnNode`s variants.

r? @eddyb

Auto merge of #53404 - oconnor663:current_dir_behavior, r=alexcrichton

document the platform-specific behavior of Command::current_dir

See also https://github.com/rust-lang/rust/issues/37868.

Here's my initial wording:

> Note that if the program path is relative (e.g. `"./script.sh"`), the interaction between that path and `current_dir` varies across platforms. Windows currently ignores `current_dir` when locating the program, but Unix-like systems interpret the program path relative to `current_dir`. These implementation details aren't considered stable, and it's recommended to call `canonicalize` to get an absolute program path instead of using relative paths and `current_dir` together.

I'd like to get feedback on:

- _Should_ we consider those details stable? It might be disruptive to change them, regardless of what I can get away with claiming in docs :)
- Is `canonicalize` an appropriate recommendation? As discussed in #37868 above, there are reasons it's not called automatically in the `Command` implementation.

Auto merge of #53272 - mark-i-m:anon_param_error_now, r=nikomatsakis

Warn on anon params in 2015 edition

cc #41686 https://github.com/rust-lang/rfcs/pull/2522
cc  @Centril @nikomatsakis

TODO:
- [x] Make sure the tests pass.
- [x] Make sure there is rustfix-able suggestion. Current plan is to just suggest `_ : Foo`
- [x] Add a rustfix ui test.

EDIT: It seems I already did the last two in #48309

Auto merge of #53227 - nivkner:pin_move, r=RalfJung

move the Pin API into its own module for centralized documentation

This implements the change proposed by @withoutboats in #49150, as suggested by @RalfJung in the review of #53104,
along with the documentation that was originally in it, that was deemed more appropriate in module-level documentation.

r? @RalfJung

Revert crate root changes

Make small modifications

Rename hir::map::NodeKind to hir::Node

Convert EntryKind to a struct, Entry

Remove path prefixes from NodeKind

Remove Node* prefix from AnnNode

Rename hir::map::Node to hir::map::NodeKind

Rename MapEntry to EntryKind

Auto merge of #51456 - qmx:crate-in-path, r=nikomatsakis

resolve suggestions should use `crate::` when enabled

I couldn't find a way to add a specific assertion for the ui test, so the expected output is living under the `crates-in-path.stderr` ui test.

- is this the right place for the test?

fixes #51212

fix test stderrs

make `to_location` O(1)

merge `PointIndexMap` and `RegionValueElements`

micro-optimize dominator code

kill dead code from `util/liveness`

improve comment on `LiveVar`

rename `LocalWithRegion` to `LiveVar`

comment what `trace` does

fix comment

enable feature `impl_header_lifetime_elision`

liveness.rs: rustfmt

implement liveness tracing, remove old liveness system

rustc: Suggest removing `extern crate` in 2018

This commit updates the `unused_extern_crates` lint to make automatic
suggestions about removing `extern crate` annotations in the 2018 edition. This
ended up being a little easier than originally though due to what's likely been
fixed issues in the resolver!

Closes #52829

update comment in the interest of precision

remove the liveness mode and simplify `categorize`

Less modes!

Auto merge of #53441 - toidiu:ak-fix53419, r=nikomatsakis

fix for late-bound regions

Fix for https://github.com/rust-lang/rust/issues/53419

r? @nikomatsakis

Fix anon param + make it allow-by-def

fix another

fix some anon params

oops

warn on anon params in 015

use associated const for machine controlling mutable statics

So get rid of the IsStatic trait again

get rid of *most* of the fn call hack by honoring mir.spread_arg

fix len() on non-array but array-layout types (e.g. SIMD)

expand comment on how statics work

fix handling of unsized types in validation; validate str to be UTF-8

validate enum discriminant whenever it is read

dedicated handling for binops on bool and char (UB if they are not valid)

get rid of FinishStatic hack from stack clenaup; const_eval can do that itself

move const_eval out of rustc_mir::interpret

to make sure that it does not access private implementation details

switch validation to use operand, not mplace

this means we can get rid of the public allocate_op, and make OpTy only
constructible in librustc_mir

terminator/drop.rs is just one fn... merge it together with the other terminator stuff

Clean up function calling

Still not as clean as I'd like it, but better

simplify const_to_allocation_provider because it is used for statics only

allow Machine to hook into foreign statics; remove unused HasMemory trait

without all those copies of constants, we can finally make eval_operand take &self

Miri Memory Work

* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
  uses "lazy" `AllocType::Static` when encountering a static.  Acessing that
  static invokes CTFE (no matter the machine).  The machine only has any
  influence when writing to a static, which CTFE outright rejects (but miri
  makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
  making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
  just has to find the MIR (or entirely take care of everything); pushing the
  new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
  have to reimplement them.

Auto merge of #53580 - nikomatsakis:nll-issue-53568, r=pnkfelix

fix NLL ICEs

Custom type-ops reuse some of the query machinery -- but while query results are canonicalized after they are constructed, custom type ops are not, and hence we have to resolve the type variables to avoid an ICE here.

Also, use the type-op machinery for implied outlives bounds.

Fixes #53568
Fixes #52992
Fixes #53680

add test for the suggestion from prelude

no need to special case std

Auto merge of #53656 - nnethercote:HybridIdxSet-tweaks, r=nikomatsakis

`HybridIdxSet` tweaks

A couple of tweaks to `HybridIdxSet`.

r? @nikomatsakis

Also use smaller spans for unsize adjustments

Auto merge of #53624 - Zoxc:ice-fix, r=oli-obk

Move with_globals setup from run_compiler to run

An alternative to https://github.com/rust-lang/rust/pull/53526

Note this breaks some miri stuff and clippy since they call `run_compiler` directly, and they now need to also call `with_globals ` cc @rust-lang/dev-tools

r? @oli-obk

Auto merge of #53648 - japaric:thumb-lld, r=alexcrichton

change the default linker of the ARM Cortex-M targets

to rust-lld so users won't need an external linker to build programs

This will break nightly builds.

We discussed this within the embedded WG and with the embedded community in
rust-embedded/wg#160 and there was consensus in that this breaking change is
worthwhile and that we should do it now before it becomes impossible to do
without breaking stable builds.

We have already written an announcement (see rust-embedded/wg#196) that explains
the breakage and instructs the users how to fix their builds. The TL;DR is that
they can switch to the old behavior by passing the `-C linker` flag to rustc.
We'll post the announcement as soon as this change makes into nightly.

closes rust-embedded/wg#160

r? @alexcrichton

Update clippy

Auto merge of #53640 - alexcrichton:more-symbol-tweaks, r=michaelwoerister

rustc: Continue to tweak "std internal symbols"

In investigating [an issue][1] with `panic_implementation` defined in an
executable that's optimized I once again got to rethinking a bit about the
`rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of
been non-stop tweaking these items ever since their inception, and this
continues to the trend.

The crux of the bug was that in the reachability we have a [different branch][2]
for non-library builds which meant that weak lang items (and std internal
symbols) weren't considered reachable, causing them to get eliminiated by
ThinLTO passes. The fix was to basically tweak that branch to consider these
symbols to ensure that they're propagated all the way to the linker.

Along the way I've attempted to erode the distinction between std internal
symbols and weak lang items by having weak lang items automatically configure
fields of `CodegenFnAttrs`. That way most code no longer even considers weak
lang items and they're simply considered normal functions with attributes about
the ABI.

In the end this fixes the final comment of #51342

[1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019
[2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238

Move with_globals setup from run_compiler to run

rustc: Continue to tweak "std internal symbols"

In investigating [an issue][1] with `panic_implementation` defined in an
executable that's optimized I once again got to rethinking a bit about the
`rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of
been non-stop tweaking these items ever since their inception, and this
continues to the trend.

The crux of the bug was that in the reachability we have a [different branch][2]
for non-library builds which meant that weak lang items (and std internal
symbols) weren't considered reachable, causing them to get eliminiated by
ThinLTO passes. The fix was to basically tweak that branch to consider these
symbols to ensure that they're propagated all the way to the linker.

Along the way I've attempted to erode the distinction between std internal
symbols and weak lang items by having weak lang items automatically configure
fields of `CodegenFnAttrs`. That way most code no longer even considers weak
lang items and they're simply considered normal functions with attributes about
the ABI.

In the end this fixes the final comment of #51342

[1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019
[2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238

Auto merge of #53715 - pietroalbini:missing-components-manifest, r=alexcrichton

Include missing tools in the manifest and mark them as unavailable

This PR changes the `build-manifest` tool to always include the missing components in the manifest, marking them as `available = false`. This blocks rustup from updating to a different nightly if the component is installed.

The code builds and _should_ be correct, but I don't know a way to test the changes locally.

r? @alexcrichton
cc @kennytm https://github.com/rust-lang-nursery/rustup.rs/issues/1486

Auto merge of #53717 - GuillaumeGomez:rollup, r=GuillaumeGomez

Rollup of 5 pull requests

Successful merges:

 - #53043 (Improve unstable message display)
 - #53428 (libtest terse format: show how far in we are)
 - #53626 (Automatically expand a section even after page load)
 - #53651 (Add struct keyword doc)
 - #53706 (rustdoc: Fix gap on section anchor symbol when hovering.)

Failed merges:

 - #53472 (Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.)

r? @ghost

use an incremental-fulldeps test instead of a run-make test

create a valid DefIdTable for proc macro crates

At least the incremental compilation code, and a few other places in the
compiler, require the CrateMetadata for a loaded target crate to contain a
valid DefIdTable for the DefIds in the target.

Previously, the CrateMetadata for a proc macro contained the crate's
"host" DefIdTable, which is of course incompatible with the "target"
DefIdTable, causing ICEs. This creates a DefIdTable that properly refers
to the "proc macro" DefIds.

Fixes #49482.

Rollup merge of #53706 - ehuss:rustdoc-section-anchor, r=GuillaumeGomez

rustdoc: Fix gap on section anchor symbol when hovering.

Fixes #49485 for section headings.

Rollup merge of #53651 - GuillaumeGomez:struct-keyword, r=QuietMisdreavus

Add struct keyword doc

Slowly, one keyword at a time.

r? @QuietMisdreavus

Rollup merge of #53626 - kzys:hashchange, r=GuillaumeGomez

Automatically expand a section even after page load

Fixes #52774

Rollup merge of #53428 - RalfJung:libtest-terse, r=KodrAus

libtest terse format: show how far in we are

So for example `./x.py test src/libcore` looks like
```
running 881 tests
.................................................................................................... 100/881
.................................................................................................... 200/881
.................................................................................................... 300/881
.............................................................i.i.................................... 400/881
.................................................................................................... 500/881
.................................................................................................... 600/881
.................................................................................................... 700/881
.................................................................................................... 800/881
.................................................................................
test result: ok. 879 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out
```
When I am waiting for 3500 ui tests to complete, I am often missing some sense of how far in these 3500 it is.

Getting the total count in `write_run_start` is a bit hacky; I did that to not change the "public interface" of the formatters. I can also give them an extra argument in their constructor so that they know from the beginning how many tests there will be. Would you prefer that? (I think I would, but I wanted to get feedback first.)

Rollup merge of #53043 - GuillaumeGomez:improve-unstable-msg-display, r=QuietMisdreavus

Improve unstable message display

Fixes #51387.
Reopening of #51563.

New display:

<img width="1440" alt="screen shot 2018-08-04 at 00 01 39" src="https://user-images.githubusercontent.com/3050060/43667793-dc14f708-9779-11e8-9808-f3ff126fc213.png">

r? @QuietMisdreavus

Auto merge of #53629 - nnethercote:lazier-SparseBitMatrix, r=nikomatsakis

Lazier sparse bit matrix

A small NLL win.

r? @nikomatsakis

add the other two targets to the manifest

remove no longer needed Docker images

fix docker build for the armebv7r-none-eabi target

more consistent llvm triples