This PR kicks off the implementation of the [default binding modes RFC][1] by
introducing the `pat_binding_modes` typeck table mentioned in the [mentoring
instructions][2].

`pat_binding_modes` is populated in `librustc_typeck/check/_match.rs` and
used wherever the HIR would be scraped prior to this PR. Unfortunately, one
blemish, namely a two callers to `contains_explicit_ref_binding`, remains.
This will likely have to be removed when the second part of [1], the
`pat_adjustments` table, is tackled. Appropriate comments have been added.

See #42640.

[1]: https://github.com/rust-lang/rfcs/pull/2005
[2]: https://github.com/rust-lang/rust/issues/42640#issuecomment-313535089

Rollup of 8 pull requests

- Successful merges: #43409, #43501, #43509, #43512, #43513, #43536, #43544, #43549
- Failed merges:

rustbuild: Enable building LLVM

I use this from time to time debugging LLVM builds, useful to have!

Update redox sys

- Add JoinHandleExt
- Split FL and FD for fcntl

Flag docker invocations as --privileged on CI

When upgrading to LLVM 5.0 it was found that the leak sanitizer tests were
failing with fatal errors, but they were passing locally when run. Turns out it
looks like they may be using new ptrace-like syscalls so the docker container
now needs `--privileged` when executing to complete the test.

std: Mark `Layout::repeat` as `#[inline]`

This fixes an optimization regression by allowing LLVM to see through more
functions.

Closes #43272

erase types in the move-path abstract domain

Leaving types unerased would lead to 2 types with a different "name"
getting different move-paths, which would cause major brokenness (see
e.g. #42903).

This does not fix any *known* issue, but is required if we want to use
abs_domain with non-erased regions (because the same can easily
have different names). cc @RalfJung.

r? @EddyB

rustdoc: add [src] links to associated functions inside an impl block

While impl blocks currently have a `[src]` link to show the source for the impl block as a whole, individual methods inside that impl block do not. This can pose a problem for structs with a lot of methods, like many in libstd. This change adds little `[src]` links to individual methods that point directly to the function in the bundled source.

fixes #12932

![methods on HashMap, showing the new src links](https://user-images.githubusercontent.com/5217170/28686066-9e7a19de-72cf-11e7-8e6b-b7d60fa33032.png)

Add Span to ast::WhereClause

This PR adds `Span` field to `ast::WhereClause`. The motivation here is to make rustfmt's life easier when recovering comments before and after where clause.
r? @nrc

doc: make into_iter example more concise

Also, remove dupe example

Throw errors when doc comments are added where they're unused

#42617

When upgrading to LLVM 5.0 it was found that the leak sanitizer tests were
failing with fatal errors, but they were passing locally when run. Turns out it
looks like they may be using new ptrace-like syscalls so the docker container
now needs `--privileged` when executing to complete the test.

I use this from time to time debugging LLVM builds, useful to have!

Changing E0623 error message - both anonymous lifetime regions

Changing the error message to
```
error[E0623]: lifetime mismatch
  --> $DIR/ex3-both-anon-regions.rs:12:12
   |
11 | fn foo(x: &mut Vec<&u8>, y: &u8) {
   |                    ---      --- these references are not declared with the same lifetime...
12 |     x.push(y);
   |            ^ ...but data from `y` flows into `x` here

error: aborting due to previous error
```
cc @nikomatsakis @aturon @jonathandturner

r? @nikomatsakis

This fixes an optimization regression by allowing LLVM to see through more
functions.

Closes #43272

rustbuild: Use Cargo's "target runner"

This commit leverages a relatively new feature in Cargo to execute
cross-compiled tests, the `target.$target.runner` configuration. We configure it
through environment variables in rustbuild and this avoids the need for us to
locate and run tests after-the-fact, instead relying on Cargo to do all that
execution for us.

rustbuild: Update cross-compilers for FreeBSD

When working through bugs for the LLVM 5.0 upgrade it looks like the FreeBSD
cross compilers we're currently using are unable to build LLVM, failing with
references to the function `std::to_string` claiming it doesn't exist. I don't
actually know what this function is, but assuming that it was added in a more
recent version of a C++ standard I've updated the gcc versions for the
toolchains we're using. This made the error go away!

rustbuild: Tweak how we cross-compile LLVM

In preparation for upgrading to LLVM 5.0 it looks like we need to tweak how we
cross compile LLVM slightly. It's using `CMAKE_SYSTEM_NAME` to infer whether to
build libFuzzer which only works on some platforms, and then once we configure
that it needs to apparently reach into the host build area to try to compile
`llvm-config` as well. Once these are both configured, though, it looks like we
can successfully cross-compile LLVM.

More Altivec Intrinsics

Support homogeneous aggregates for hard-float ARM

Hard-float ARM targets use the AAPCS-VFP ABI, which passes and returns
homogeneous float/vector aggregates in the VFP registers.

Fixes #43329.

r? @EddyB

This commit leverages a relatively new feature in Cargo to execute
cross-compiled tests, the `target.$target.runner` configuration. We configure it
through environment variables in rustbuild and this avoids the need for us to
locate and run tests after-the-fact, instead relying on Cargo to do all that
execution for us.

When working through bugs for the LLVM 5.0 upgrade it looks like the FreeBSD
cross compilers we're currently using are unable to build LLVM, failing with
references to the function `std::to_string` claiming it doesn't exist. I don't
actually know what this function is, but assuming that it was added in a more
recent version of a C++ standard I've updated the gcc versions for the
toolchains we're using. This made the error go away!

In preparation for upgrading to LLVM 5.0 it looks like we need to tweak how we
cross compile LLVM slightly. It's using `CMAKE_SYSTEM_NAME` to infer whether to
build libFuzzer which only works on some platforms, and then once we configure
that it needs to apparently reach into the host build area to try to compile
`llvm-config` as well. Once these are both configured, though, it looks like we
can successfully cross-compile LLVM.

Implement tokenization for some items in proc_macro

This PR is a partial implementation of https://github.com/rust-lang/rust/issues/43081 targeted towards preserving span information in attribute-like procedural macros. Currently all attribute-like macros will lose span information with the input token stream if it's iterated over due to the inability of the compiler to losslessly tokenize an AST node. This PR takes a strategy of saving off a list of tokens in particular AST nodes to return a lossless tokenized version. There's a few limitations with this PR, however, so the old fallback remains in place.

This is then later used by `proc_macro` to generate a new
`proc_macro::TokenTree` which preserves span information. Unfortunately this
isn't a bullet-proof approach as it doesn't handle the case when there's still
other attributes on the item, especially inner attributes.

Despite this the intention here is to solve the primary use case for procedural
attributes, attached to functions as outer attributes, likely bare. In this
situation we should be able to now yield a lossless stream of tokens to preserve
span information.

improve case with both anonymous lifetime parameters #43269

This is a fix to #43269.

Sample output message-

```

error[E0623]: lifetime mismatch
  --> $DIR/ex3-both-anon-regions.rs:12:12
   |
11 | fn foo(x: &mut Vec<&u8>, y: &u8) {
   |                    ---      --- these references must have the same lifetime
12 |     x.push(y);
   |            ^ data from `y` flows into `x` here

error: aborting due to 2 previous errors

```
r? @nikomatsakis

This test currently fails because the tokenization of an AST item during the
expansion of a procedural macro attribute rounds-trips through strings, losing
span information.

This partly resolves the `FIXME` located in `src/libproc_macro/lib.rs` when
interpreting interpolated tokens. All instances of `ast::Item` which have a list
of tokens attached to them now use that list of tokens to losslessly get
converted into a `TokenTree` instead of going through stringification and losing
span information.

cc #43081

This commit adds a new field to the `Item` AST node in libsyntax to optionally
contain the original token stream that the item itself was parsed from. This is
currently `None` everywhere but is intended for use later with procedural
macros.

The function should accept feature strings that old LLVM might not
support.

Simplify the code using the same approach used by
LLVMRustPrintTargetFeatures.

Dummify the function for non 4.0 LLVM and update the tests accordingly.

Provide positional information when visiting ty, substs and closure_substs in MIR

This will enable the region renumbering portion of #43234 (non-lexical lifetimes). @nikomatsakis's current plan [here](https://gist.github.com/nikomatsakis/dfc27b28cd024eb25054b52bb11082f2) shows that we need spans of the original code to create new region variables, e.g. `self.infcx.next_region_var(infer::MiscVariable(span))`. The current visitor impls did not pass positional information (`Location` in some, `Span` and `SourceInfo` for others) for all types. I did not expand this to all visits, just the ones necessary for the above-mentioned plan.

Embed MSVC .natvis files into .pdbs and mangle debuginfo for &str, *T, and [T].

No idea if these changes are reasonable - please feel free to suggest changes/rewrites.  And these are some of my first real commits to any rust codebase - *don't* be gentle, and nitpick away, I need to learn! ;)

### Overview
Embedding `.natvis` files into `.pdb`s allows MSVC (and potentially other debuggers) to automatically pick up the visualizers without having to do any additional configuration (other than to perhaps add the relevant .pdb paths to symbol search paths.)

The native debug engine for MSVC parses the type names, making various C++ish assumptions about what they mean and adding various limitations to valid type names.  `&str` cannot be matched against a visualizer, but if we emit `str&` instead, it'll be recognized as a reference to a `str`, solving the problem.  `[T]` is similarly problematic, but emitting `slice<T>` instead works fine as it looks like a template.  I've been unable to get e.g. `slice<u32>&` to match visualizers in VS2015u3, so I've gone with `str*` and `slice<u32>*` instead.

### Possible Issues
* I'm not sure if `slice<T>` is a great mangling for `[T]` or if I should worry about name collisions.
* I'm not sure if `linker.rs` is the right place to be enumerating natvis files.
* I'm not sure if these type name mangling changes should actually be MSVC specific.  I recall seeing gdb visualizer tests that might be broken if made more general?  I'm hesitant to mess with them without a gdb install.  But perhaps I'm just wracking up technical debt.
  Should I try `pacman -S mingw-w64-x86_64-gdb` and to make things consistent?
* I haven't touched `const` / `mut` yet, and I'm worried MSVC might trip up on `mut` or their placement.
* I may like terse oneliners too much.
* I don't know if there's broader implications for messing with debug type names here.
* I may have been mistaken about bellow test failures being ignorable / unrelated to this changelist.

### Test Failures on `x86_64-pc-windows-gnu`

```
---- [debuginfo-gdb] debuginfo-gdb\associated-types.rs stdout ----
        thread '[debuginfo-gdb] debuginfo-gdb\associated-types.rs' panicked at 'gdb not available but debuginfo gdb debuginfo test requested', src\tools\compiletest\src\runtest.rs:48:16
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[...identical panic causes omitted...]

---- [debuginfo-gdb] debuginfo-gdb\vec.rs stdout ----
        thread '[debuginfo-gdb] debuginfo-gdb\vec.rs' panicked at 'gdb not available but debuginfo gdb debuginfo test requested', src\tools\compiletest\src\runtest.rs:48:16
```

### Relevant Issues
* https://github.com/rust-lang/rust/issues/40460 Metaissue for Visual Studio debugging Rust
* https://github.com/rust-lang/rust/issues/36503 Investigate natvis for improved msvc debugging
* https://github.com/PistonDevelopers/VisualRust/issues/160 Debug visualization of Rust data structures

### Pretty Pictures
![Collapsed Watch Window](https://user-images.githubusercontent.com/75894/28180998-e44c7516-67bb-11e7-8b48-d4f9605973ae.png)
![Expanded Watch Window](https://user-images.githubusercontent.com/75894/28181000-e8da252e-67bb-11e7-96b8-d613310c04dc.png)

rustc_const_eval: always require Substs and a ParamEnv.

Fixes #43357 by tracking the `Substs` and `ParamEnv` for const-evaluation in generic contexts.