Fix ref-to-ptr coercions not working with NLL in certain cases

Implicit coercions from references to pointers were lowered to slightly
different Mir than explicit casts (e.g. 'foo as *mut T'). This resulted
in certain uses of self-referential structs compiling correctly when an
explicit cast was used, but not when the implicit coercion was used.

To fix this, this commit adds an outer 'Use' expr when applying a
raw-ptr-borrow adjustment. This makes the lowered Mir for coercions
identical to that of explicit coercions, allowing the original code to
compile regardless of how the raw ptr cast occurs.

Fixes #47722

Auto merge of #47837 - eddyb:going-places, r=nikomatsakis

Replace "lvalue" terminology with "place".

See #46425 for the previous PR (which only changed MIR-related code).

r? @nikomatsakis

Auto merge of #47766 - spastorino:inference-dirty-list, r=nikomatsakis

Make region inference use a dirty list

r? @nikomatsakis

rustc_borrowck: replace "lvalue" terminology with "place" in docs.

tests: replace "lvalue" terminology with "place".

Auto merge of #47730 - alexcrichton:multitrans, r=Mark-Simulacrum

rustc: Split Emscripten to a separate codegen backend

This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.

A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.

There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:

* A *second* LLVM submodule was added in this commit. The main LLVM submodule
  will soon start to drift from the Emscripten submodule, but currently they're
  both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
  This is gated behind a `--enable-emscripten` flag to the configure script. By
  default users should neither check out the emscripten submodule nor compile
  it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
  GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
  of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
  platforms, though. All cross-compiled platforms will not be receiving an
  Emscripten backend yet.

This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.

Closes #46819

rustc: Split Emscripten to a separate codegen backend

This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.

A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.

There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:

* A *second* LLVM submodule was added in this commit. The main LLVM submodule
  will soon start to drift from the Emscripten submodule, but currently they're
  both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
  This is gated behind a `--enable-emscripten` flag to the configure script. By
  default users should neither check out the emscripten submodule nor compile
  it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
  GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
  of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
  platforms, though. All cross-compiled platforms will not be receiving an
  Emscripten backend yet.

This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.

Closes #46819

rustc: replace "lvalue" terminology with "place" in the code.

Auto merge of #47663 - malbarbo:mips-crt-static, r=alexcrichton

Do not assume dynamic linking for musl/mips[el] targets

All musl targets except mips[el] assume static linking by default. This can be [confusing](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084).

When the musl/mips[el] targets was [added](https://github.com/rust-lang/rust/pull/31298), dynamic linking was chosen because of binary size concerns, and probably also because libunwind [didn't](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084/8) supported mips.

Now that we have `crt-static` target-feature (the user can choose dynamic link for musl targets), and libunwind [6.0](https://github.com/llvm-mirror/libunwind/commits/release_60) add support to mips, we do not need to assume dynamic linking.

rustc: move `expr_is_lval` to rustc_typeck and rename to `is_place_expr`.

rustc_typeck: rename `LvalueOp` to `PlaceOp`.

rustc_typeck: rename `LvaluePreference::PreferMutLvalue` to `Needs::MutPlace`.

rustc: remove `LvaluePreference` argument from `Ty::builtin_deref`.

Auto merge of #47204 - varkor:unsafecell-into_inner-safe, r=alexcrichton

Make UnsafeCell::into_inner safe

This fixes #35067. It will require a Crater run as discussed in that
issue.

Auto merge of #47800 - Pulkit07:issue47755, r=sfackler

don't mention tasks in stability warnings of #[thread_local] #47755

This is a fix for issue #47755.

Auto merge of #47794 - etaoins:fix-ice-on-const-eval-of-union-field, r=eddyb

Fix ICE on const eval of union field

MIR's `Const::get_field()` attempts to retrieve the value for a given field in a constant. In the case of a union constant it was falling through to a generic `const_get_elt` based on the field index. As union fields don't have an index this caused an ICE in `llvm_field_index`.

Fix by simply returning the current value when accessing any field in a union. This works because all union fields start at byte offset 0.

The added test uses `const_fn` it ensure the field is extracted using MIR's const evaluation. The crash is reproducible without it, however.

Fixes #47788

r? @eddyb

Auto merge of #47772 - arthurprs:iter-position-bounds-check, r=dtolnay

Use the slice length to hint the optimizer about iter.position result

Using the len of the iterator doesn't give the same result.
That's also why we can't generalize it to all TrustedLen iterators.

Problem demo: https://godbolt.org/g/MXg2ae
Fix demo: https://godbolt.org/g/P8q5aZ

Second attempt of #47333
Third attempt of #45501
Fixes #45964

Auto merge of #47767 - estebank:as-suggestion, r=petrochenkov

Correctly format `extern crate` conflict resolution help

Closes #45799. Follow up to @Cldfire's #45820.

If the `extern` statement that will have a suggestion ends on a `;`, synthesize a new span that doesn't include it.

Auto merge of #47671 - alexcrichton:trans-c-api-only, r=Mark-Simulacrum

rustc: Load the `rustc_trans` crate at runtime

Building on the work of #45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement #46819 where rustc
will have multiple backends available to it to load.

This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).

Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.

A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.

rustc: Load the `rustc_trans` crate at runtime

Building on the work of # 45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement # 46819 where rustc
will have multiple backends available to it to load.

This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).

Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.

A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.

Auto merge of #47746 - varkor:never-type-ice, r=nikomatsakis

Fix never-type rvalue ICE

This fixes #43061.
r? @nikomatsakis

A small post-mortem as a follow-up to our investigations in https://github.com/rust-lang/rust/pull/47291:
The problem as I understand it is that when `NeverToAny` coercions are made, the expression/statement that is coerced may be enclosed in a block. In our case, the statement `x;` was being transformed to something like: `NeverToAny( {x;} )`. Then, `NeverToAny` is transformed into an expression:
https://github.com/rust-lang/rust/blob/000fbbc9b8f88adc6a417f1caef41161f104250f/src/librustc_mir/build/expr/into.rs#L52-L59
Which ends up calling `ast_block_stmts` on the block `{x;}`, which triggers this condition:
https://github.com/rust-lang/rust/blob/000fbbc9b8f88adc6a417f1caef41161f104250f/src/librustc_mir/build/block.rs#L141-L147
In our case, there is no return expression, so `push_assign_unit` is called. But the block has already been recorded as _diverging_, meaning the result of the block will be assigned to a location of type `!`, rather than `()`. This causes the MIR error.
I'm assuming the `NeverToAny` coercion code is doing what it's supposed to (there don't seem to be any other problems), so fixing the issue simply consists of checking that the destination for the return value actually _is_ supposed to be a unit. (If no return value is given, the only other possible type for the return value is `!`, which can just be ignored, as it will be unreachable anyway.)

I checked the other cases of `push_assign_unit`, and it didn't look like they could be affected by the divergence issue (blocks are kind of special-cased in this regard as far as I can tell), so this should be sufficient to fix the issue.

Remove musl/libunwind patch for i686

The i686 problem was fixed upstream:
https://github.com/llvm-mirror/libunwind/commit/aa805e415f19f50ebc6f5e1e1e4bf9bb7f61816b

Auto merge of #47420 - davidtwco:issue-46885, r=estebank

Fix off-by-one spans in MIR borrowck errors

Fixes #46885.

r? @nikomatsakis

Fixed infinite loop issues and added some improved logging.

Now handling case where span has same lo and hi.

Fix new test from rebase.

next_point now handles creating spans over multibyte characters.

Replaced multi-byte character handling in end_point with potentially more performant variant.

end_point handling multibyte characters correctly.

Moved overflow check into end_point function.

Fixed off-by-one spans in MIR borrowck errors.

Updated tests with fixed span location.

Auto merge of #46450 - Gilnaa:libtest_json_output, r=nrc

Libtest json output

A revisit to my [last PR](https://github.com/rust-lang/rust/pull/45923).

Events are now more atomic, printed in a flat hierarchy.

For the normal test output:
```
running 1 test
test f ... FAILED

failures:

---- f stdout ----
thread 'f' panicked at 'assertion failed: `(left == right)`
  left: `3`,
 right: `4`', f.rs:3:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.

failures:
    f

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
```

The JSON equivalent is:
```
{ "type": "suite", "event": "started", "test_count": "1" }
{ "type": "test", "event": "started", "name": "f" }
{ "type": "test", "event": "failed", "name": "f" }
{ "type": "suite", "event": "failed", "passed": 0, "failed": 1, "allowed_fail": 0, "ignored": 0,  "measured": 0, "filtered_out": "0" }
{ "type": "test_output", "name": "f", "output": "thread 'f' panicked at 'assertion failed: `(left == right)`
  left: `3`,
 right: `4`', f.rs:3:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
" }
```

libtest: Fixed call to python in run-make

Auto merge of #47690 - estebank:for-block-277, r=nikomatsakis

For E0277 on `for` loops, point at the "head" expression

When E0277's span points at a `for` loop, the actual issue is in the
element being iterated. Instead of pointing at the entire loop, point
only at the first line (when possible) so that the span ends in the
element for which E0277 was triggered.

don't mention tasks in stability warnings of #[thread_local] #47755

This is a fix for issue #47755.

Expand union test to include different types

Fix ICE on const eval of union field

MIR's `Const::get_field()` attempts to retrieve the value for a given
field in a constant. In the case of a union constant it was falling
through to a generic `const_get_elt` based on the field index. As union
fields don't have an index this caused an ICE in `llvm_field_index`.

Fix by simply returning the current value when accessing any field in a
union. This works because all union fields start at byte offset 0.

The added test uses `const_fn` it ensure the field is extracted using
MIR's const evaluation. The crash is reproducible without it, however.

Fixes #47788

pacify the mercilous tidy

change from `dirty_bit_vec` to `clean_bit_vec`

Otherwise the vector is initially out of sync

Adjust comment spacing

I suspect the lines would be long for tidy.

Make region inference use a dirty list

Fixes #47602

Auto merge of #47571 - FenrirWolf:libunwind, r=alexcrichton

Match libunwind's EABI selection with libpanic_unwind

Currently, the `libunwind` crate will only select the ARM EABI if it is compiling for ARM/Linux or Android targets. `libpanic_unwind`, however, will choose the ARM EABI if the target arch is ARM and the OS is not iOS. This means that if one tries to enable unwinding for a non-standard ARM target (such as implementing a custom stdlib via Xargo, for example), then the two crates can potentially disagree about which EABI is being targeted.

This PR makes `libunwind` use the [same logic](https://github.com/rust-lang/rust/blob/master/src/libpanic_unwind/gcc.rs#L139-L146) as `libpanic_unwind` when choosing the EABI.

I noticed there are a few comments about certain functions only differing on Android or ARM/Linux, but I *think* that those differences apply to the ARM EABI in general. Let me know if I'm wrong about that.

Instead of modifying the item's span synthesize it

Don't add "in this macro invocation" label to desugared spans

Modify spans of expanded expression

Modify the spans used for `for`-loop expression expansion, instead of
creating a new span during error creation.

Updated Cargo commit hash

libtest: Failing benchmarks no longer crash the harness.

libtest: Split-up formatters.rs into smaller modules

libtest: Split HumanFormatter into {Pretty,Terse}

libtest: Fixed padding of benchmarks when not benchmarking

libtest: Fixed benchmarks' names not showing in terse-mode

libtest: Formatting

libtest: Added UI tests for --format=json

libtest: Remove usage of jq

libtest: Fixed UI tests

- Now comparing to the right file.
- A python script checks for validity of JSON documents

libtest: rustfmt run

libtest: Whoops

libtest: Fixed pretty-printing of test names in single-threaded code.

libtest: JSON formatting is now only available in unstable builds

libtest: Added the -Z option for unstable options

Added JSON output to libtest.

libtest: Json format now outputs failed tests' stdouts.

libtest: Json format now outputs failed tests' stdouts.

libtest: Json formatter now spews individiual events, not as an array

libtest: JSON fixes

libtest: Better JSON escaping

libtest: Test start event is printed on time

Refactoring needed in order to have test json output.

Auto merge of #47748 - alexcrichton:rollup, r=alexcrichton

Rollup of 19 pull requests

- Successful merges: #47415, #47437, #47439, #47453, #47460, #47502, #47529, #47600, #47607, #47618, #47626, #47656, #47668, #47696, #47701, #47705, #47710, #47711, #47719
- Failed merges: #47455, #47521

Ignore a test on emscripten

Add clarifying comment regarding the trailing type of a block

Fix a test case on Windows

Merge branch 'mlsm' of https://github.com/dotdash/rust into rollup

Merge branch 'beta-prerelease' of https://github.com/cuviper/rust into rollup

Merge branch 'android-run-pass' of https://github.com/malbarbo/rust into rollup

Merge branch 'fix-regression' of https://github.com/estebank/rust into rollup

Merge branch 'rustdoc_masked' of https://github.com/ollie27/rust into rollup

Merge branch 'simd-always-mem' of https://github.com/alexcrichton/rust into rollup

Merge branch 'llvm5-indirect-deref' of https://github.com/cuviper/rust into rollup

Merge branch 'explain' of https://github.com/estebank/rust into rollup

Merge branch 'no-stderr-sink' of https://github.com/Zoxc/rust into rollup

Shorten another test path for MSVC

Auto merge of #47252 - Zoxc:backtrace-win, r=alexcrichton

Print inlined functions on Windows

Split from https://github.com/rust-lang/rust/pull/45637

r? @alexcrichton

Use the slice length to hint the optimizer

Using the len of the iterator doesn't give the same result.
That's also why we can't generalize it to all TrustedLen iterators.

Upgrade LLVM to incorporate a fix for #47364

Fixes #47364

Correctly format `extern crate` conflict resolution help

Ignore an i128 test on emscripten

Auto merge of #47676 - topecongiro:update-rls, r=alexcrichton

Update rls

Currently rls is missing from the latest nightly component. This PR brings it back.

Update rls

Do not capture stderr in the compiler. Instead just panic silently for fatal errors

Print inlined functions on Windows

Shorten a filename for MSVC

Call non-git beta builds simply x.y.z-beta

We can't use git commands to compute a prerelease version when we're
building from a source tarball, or if git is otherwise unavailable.
We'll just call such builds `x.y.z-beta`, without a prerelease.

Revert update of the i686-freebsd builder

Looks like llvm 4.0.0 isn't read for that either.

Remove stray src/llvm-emscripten module

Accidentally added in e9a64996b

Merge branch 'configure-lto' of https://github.com/alexcrichton/rust into rollup

Merge branch 'cache-ty-collect' of https://github.com/michaelwoerister/rust into rollup

Rollup merge of #47719 - malbarbo:run-pass-arch-powerpc, r=alexcrichton

Add powerpc to run-pass/conditional-compile-arch.rs

Rollup merge of #47711 - alexcrichton:update-compiler-builtins, r=nikomatsakis

Update compiler-builtins submodule

No sense of urgency, just wanted to make sure we don't lag too far behind!

Rollup merge of #47710 - alexcrichton:llvm-6-compat, r=nikomatsakis

First round of LLVM 6.0.0 compatibility

This includes a number of commits for the first round of upgrading to LLVM 6. There are still [lingering bugs](https://github.com/rust-lang/rust/issues/47683) but I believe all of this will nonetheless be necessary!

Rollup merge of #47705 - pietroalbini:fix-47673, r=petrochenkov

Fix ICE when use trees have multiple empty nested groups

The issue was caused by an oversight of mine in the original use_nested_groups PR, where different paths were resolved with the same `NodeId` in some cases (such as in `use {{}, {}};`).

Fixes #47673
r? @petrochenkov

Rollup merge of #47701 - Manishearth:intra-fixes, r=QuietMisdreavus

Fixes for intra-doc-links

Turn errors into warnings, also handle methods, trait items, and variants.

r? @killercup @QuietMisdreavus

Rollup merge of #47696 - Zoxc:variance-rg, r=nikomatsakis

Make use of the implemented red/green algorithm for variance

r? @michaelwoerister

Rollup merge of #47668 - nikomatsakis:issue-47511, r=eddyb

do not ICE when return type includes unconstrained anon region

It turns out that this *can* happen after all, if the region is only
used in projections from the input types.

Fixes https://github.com/rust-lang/rust/issues/47511

r? @eddyb

Rollup merge of #47656 - ishitatsuyuki:patch-1, r=nikomatsakis

[perf] Use std based dedup in projection

Unstable sort was added recently, and the code that is being modified is 3 years old. As quicksort doesn't allocate it will likely perform as well as, or better than linear search.

I didn't benchmark. Have a perf run.

Rollup merge of #47626 - eddyb:one-less-unwrap, r=nagisa

rustc_trans: remove an unwrap by replacing a bool with Result.

Prompted by @shepmaster.
r? @nagisa

Rollup merge of #47618 - mrhota:dw_at_noreturn, r=michaelwoerister

Teach rustc about DW_AT_noreturn and a few more DIFlags

We achieve two small things with this PR:
1. We provide definitions for a few additional llvm debuginfo flags
1. We _use_ one of these new flags, `FlagNoReturn`, and add it to debuginfo for functions with the never return type (`!`).

Make 3 run-pass tests works on android (aarch64 and x86)

rustc: SIMD types use pointers in Rust's ABI

This commit changes the ABI of SIMD types in the "Rust" ABI to unconditionally
be passed via pointers instead of being passed as immediates. This should fix a
longstanding issue, #44367, where SIMD-using programs ended up showing very odd
behavior at runtime because the ABI between functions was mismatched.

As a bit of a recap, this is sort of an LLVM bug and sort of an LLVM feature
(today's behavior). LLVM will generate code for a function solely looking at the
function it's generating, including calls to other functions. Let's then say
you've got something that looks like:

```llvm
define void @foo() { ; no target features enabled
  call void @bar(<i64 x 4> zeroinitializer)
  ret void
}

define void @bar(<i64 x 4>) #0 { ; enables the AVX feature
  ...
}
```

LLVM will codegen the call to `bar` *without* using AVX registers becauase `foo`
doesn't have access to these registers. Instead it's generated with emulation
that uses two 128-bit registers. The `bar` function, on the other hand, will
expect its argument in an AVX register (as it has AVX enabled). This means we've
got a codegen problem!

Comments on #44367 have some more contexutal information but the crux of the
issue is that if we want SIMD to work in general we'll need to ensure that
whenever a function calls another they ABI of the arguments being passed is in
agreement.

One possible solution to this would be to insert "shim functions" where whenever
a `target_feature` mismatch is detected the compiler inserts a shim function
where you pass arguments via memory to the shim and then the shim loads the
values and calls the target function (where the shim and the target have the
same target features enabled). This unfortunately is quite nontrivial to
implement in rustc today (especially when accounting for function pointers and
such).

This commit takes a different solution, *always* passing SIMD arguments through
memory instead of passing as immediates. This strategy solves the problem at the
LLVM layer because the ABI between two functions never uses SIMD registers. This
also shouldn't be a hit to performance because SIMD performance is thought to
often rely on inlining anyway, where a `call` instruction, even if using SIMD
registers, would be disastrous to performance regardless. LLVM should then be
more than capable of fixing all our memory usage to use registers instead after
enough inlining has been performed.

Note that there's a few caveats to this commit though:

* The "platform intrinsic" ABI is omitted from "always pass via memory". This
  ABI is used to define intrinsics like `simd_shuffle4` where LLVM and rustc
  need to have the arguments as an immediate.

* Additionally this commit does *not* fix the `extern` ("C") ABI. This means
  that the bug in #44367 can still happen when using non-Rust-ABI functions. My
  hope is that before stabilization we can ban and/or warn about SIMD types in
  these functions (as AFAIK there's not much motivation to belong there anyway),
  but I'll leave that for a later commit and if this is merged I'll file a
  follow-up issue.

All in all this...

Closes #44367

Add description to field and method

Fix regression: account for impl methods in arg count mismatch error

Rollup merge of #47600 - varkor:empty-never-array, r=eddyb

Fix type inhabitedness check for arrays

Arrays of uninhabited types were considered to also be uninhabited if
their length had not been evaluated, causing unsoundness.

Fixes #47563.

r? @eddyb

Rollup merge of #47529 - nikomatsakis:impl-trait-issue-38064, r=cramertj

track recursion limit when expanding existential impl trait

r? @cramertj