Update test for issue 17780 since diagnostic message have changed

The test was also renamed to be more descriptive.
Add regression test for issue #17403
Add failure tests for moving out of unboxed closure environments
Fix ICE in overloaded call with incorrect arity

When an overloaded call expression has parameters but the function
object takes none, construct an array of formal argument types with
the arity of the call expression so that we don't fail by indexing out
of bounds later.

Closes #16939
auto merge of #17869 : bkoropoff/rust/bound-all-the-upvars, r=nikomatsakis

This PR is based on #17784, which fixes closure soundness problems in borrowck.  Only the last two commits are unique to this PR.

My understanding of regionck is still evolving, so I'm not sure if this is the right approach.  Feedback is appreciated.

- In `link_reborrowed_region`, we account for the ability of upvars to
  change their mutability due to later processing.  A map of recursive
  region links we may want to establish in the future is maintained,
  with the links being established when the mutability of the borrow
  is adjusted.
- When asked to establish a region link for an upvar, we link it to
  the region of the closure body.  This creates the necessary
  constraint to stop unsound reborrows from the closure environment.

This partially (maybe completely) solves issue #17403.  Remaining work:

- This is only known to help with by-ref upvars.  I have not looked at
  by-value upvars yet to see if they can cause problems.
- The error diagnostics that result from failed region inference are
  pretty inscrutible.
Add regression test for issue #16939
Fix translation of unboxing shim for rust-call ABI methods

When translating the unboxing shim, account for the fact that the shim
translation has already performed the necessary unboxing of input
types and values when forwarding to the shimmed function.  This
prevents ICEing or generating incorrect code.

Closes #16739
Add regression test for issue #16739
auto merge of #18056 : TeXitoi/rust/shootout-reverse-complement-improvement, r=alexcrichton

This is some improvement as asked and discused here: http://www.reddit.com/r/rust/comments/2j2ij3/benchmark_improvement_reverse_compliment/

Before:
```
real    0m0.396s
user    0m0.280s
sys     0m0.112s
```
after:
```
real    0m0.293s
user    0m0.216s
sys     0m0.076s
```
best C version:
```
real    0m0.135s
user    0m0.132s
sys     0m0.060s
```

Another possibility will be to add a `DoubleEndedIterator::next_two_side()` with a deffault implementation, and specialising it for slices, and use it here (`MutableSlice::reverse()` can then become safe). This benchmark will then be safe.

What do you think?
auto merge of #18052 : IvanUkhov/rust/raw-byte-string-literals, r=aturon

Hello,


The pull request fixes a typo in the description of raw string literals in [reference.md](https://github.com/rust-lang/rust/blob/master/src/doc/reference.md#byte-and-byte-string-literals).


Regards,
Ivan
auto merge of #18089 : gamazeps/rust/small-bitv-cleanup, r=alexcrichton

I was going to write some doc in order to remove the #[allow(missing_doc)] but there was actually none missing.
I also removed a warning i didn't see in my last commit  #18018
Linked to #18009
Make the tests green as they should on 32-bit architectures

On 32-bit architectures, the size calculations on two of the tests wrap-around
in typeck, which gives the relevant arrays a size of 0, which is (correctly)
successfully allocated.
Correct a test. The error message changed because, with this fix, we
detected (correctly) that there was only one impl and hence ignored the
`Self` bound completely. I (semi-arbitrarily) elected to delect the
impl, forcing the trait matcher to be more conservative and lean on the
where clauses in scope, yielding the original error message.
Use match expression directly in guide.md

Use a match expression directly in the println statement, instead of creating a second variable.
auto merge of #18093 : steveklabnik/rust/remove_gc_reference, r=alexcrichton
Update LLVM to get slightly better memcpy elision
Check for borrow of local variable introduced within static block.

(Rather than ICE on it.)

Fix #18118.
auto merge of #16855 : P1start/rust/help-messages, r=brson

This adds ‘help’ diagnostic messages to rustc. This is used for anything that provides help to the user, particularly the `--explain` messages that were previously integrated into the relevant error message.

They look like this:

```
match.rs:10:13: 10:14 error: unreachable pattern [E0001]
match.rs:10             1 => {},
                        ^
match.rs:3:1: 3:38 note: in expansion of foo!
match.rs:7:5: 20:2 note: expansion site
match.rs:10:13: 10:14 help: pass `--explain E0001` to see a detailed explanation
```

(`help` is coloured cyan.) Adding these errors on a separate line stops the lines from being too long, as discussed in #16619.
auto merge of #17009 : kballard/rust/install_no_sudo, r=pnkfelix

When running `sudo make install`, we only want to run the actual install
as root, the building of the documentation and the distribution folder
should happen as the non-root user.

Related to #13728.
auto merge of #17815 : typelist/rust/recursive-structs, r=brson

The representability-checking routine ```is_type_representable``` failed to detect structural recursion in some cases, leading to stack overflow later on.

The first problem was in the loop in the ```find_nonrepresentable``` function. We were improperly terminating the iteration if we saw a ```ContainsRecursive``` condition. We should have kept going in case a later member of the struct (or enum, etc) being examined was ```SelfRecursive```. The example from #17431 triggered this issue:

```rust
use std::sync::Mutex;
struct Foo { foo: Mutex<Option<Foo>> }
impl Foo { fn bar(self) {} }
fn main() {}
```

I'm not 100% sure, but I think the ```ty_enum``` case of ```fn type_structurally_recursive``` had a similar problem, since it could ```break``` on ```ContainsRecursive``` before looking at all variants. I've replaced this with a ```flat_map``` call.

The second problem was that we were failing to identify code like ```struct Foo { foo: Option<Option<Foo>> }``` as SelfRecursive, even though we correctly identified ```struct Foo { foo: Option<Foo> }```. This was caused by using DefId's for the ```ContainsRecursive``` check, which meant the nested ```Option```s were identified as illegally recursive (because ```ContainsRecursive``` is not an error, we would then keep compiling and eventually hit a stack overflow).

In order to make sure that we can recurse through the different ```Option``` invocations, I've changed the type of ```seen``` from ```Vec<DefId>``` to ```Vec<t>``` and added a separate ```same_type``` function to check whether two types are the same when generics are taken into account. Now we only return ```ContainsRecursive``` when this stricter check is satisfied. (There's probably a better way to do this, and I'm not sure my code is entirely correct--but my knowledge of rustc internals is pretty limited, so any help here would be appreciated!)

Note that the ```SelfRecursive``` check is still comparing ```DefId```s--this is necessary to prevent code like this from being allowed:

```rust
struct Foo { x: Bar<Foo> }
struct Bar<T> { x: Bar<Foo> }
```

All four of the new ```issue-17431``` tests cause infinite recursion on master, and errors with this pull request. I wrote the extra ```issue-3008-4.rs``` test to make sure I wasn't introducing a regression.

Fixes #17431.