Fixes #27467.

Closes #27412 

r? @brson

This test case has been removed a while ago because it allegedly was broken. But I don't think it is (at least I couldn't reproduce any failure on Linux). Let's give it another chance `:)`

Fixes #27467.

After #26694, the overloaded operator and "impl not known at method lookup time" cases started triggering the lint.
I've also added checks for overloaded autoderef and method calls via paths (i.e. `T::method()`).
All new 8 test cases did not trigger the lint before #26694.
r? @huonw

After this change, the only remaining symbol we are pulling from libgcc on Win64 is `__chkstk_ms` - the stack probing routine.

Fixes #25022

This adapts the deriving mechanism to not repeat bounds for the same type parameter. To give an example: for the following code:

```rust
#[derive(Clone)]
pub struct FlatMap<I, U: IntoIterator, F> {
    iter: I,
    f: F,
    frontiter: Option<U::IntoIter>,
    backiter: Option<U::IntoIter>,
}
```
the latest nightly generates the following impl signature:

```rust
impl <I: ::std::clone::Clone,
      U: ::std::clone::Clone + IntoIterator,
      F: ::std::clone::Clone>
::std::clone::Clone for FlatMap<I, U, F> where
    I: ::std::clone::Clone,
    F: ::std::clone::Clone,
    U::IntoIter: ::std::clone::Clone,
    U::IntoIter: ::std::clone::Clone
```

With these changes, the signature changes to this:
```rust
impl <I, U: IntoIterator, F> ::std::clone::Clone for FlatMap<I, U, F> where
    I: ::std::clone::Clone,
    F: ::std::clone::Clone,
    U::IntoIter: ::std::clone::Clone
```
(Nothing in the body of the impl changes)
Note that the second impl is more permissive, as it doesn't have a `Clone` bound on `U` at all. There was a compile-fail test that failed due to this. I don't understand why we would want the old behaviour (and nobody on IRC could tell me either), so please tell me if there is a good reason that I missed.

Inspired by https://github.com/rust-lang/rust/issues/27484

- Successful merges: #27464, #27473
- Failed merges: 

This removes some of the more casual language.

The only outright goofiness I couldn't bear to remove is "these modules are the bedrock upon which all of Rust is forged, and they have mighty names like `std::slice` and `std::cmp`", which I believe the greatest sentence I have ever created.

Because Markdown.

I found that the book had little information for `loop`s and `loop` label so I've added some.

Because Markdown.

When a `nounwind` function has a personality routine, LLVM messes up .seh directives (happens to `rust_try` in optimized builds).  A workaround is to give `rust_try` the `uwtable` attribute.
Also, make sure that the dummy "load from null" instruction inserted by init_function() gets cleaned up.

Only `make -j4` takes ~50 mins
`make check` bumps it up to ~1hr 30min

Travis seems more than happy to let this happen. 

Time limits appear to be meaningless.

Similar to the previous PR, it's easy to tell how much your PR definitely builds by checking the current logs or just considering how long it's been building for.

Sorry :/

- Successful merges: #26982, #27305, #27419, #27423, #27426
- Failed merges: 

Corrects formatting of bullet-ed sentences and changes 'pervasive use raw pointers' to 'pervasive use of raw pointers'.

part of #24407 

I'm not sure whether I should be trying to explain the general rule in the E0210 explanation or just point people to the RFC. However, if we go with the latter option I think that the RFC will need to be revised slightly, since it is not quite as gentle as I would like.

Also, the link to RFC 1023 is not the correct one (it should be https://github.com/rust-lang/rfcs/blob/master/text/1023-rebalancing-coherence.md), but the correct one is too long. I'm aware of @michaelsproul's PR https://github.com/rust-lang/rust/pull/26290 from awhile back, but it doesn't seem to be working. Has there not been a new snapshot yet?

@alexcrichton please upload the FreeBSD 32-bit snapshot file when landing this patch:
https://github.com/dhuseby/rust-manual-snapshots/raw/master/rust-stage0-2015-07-26-a5c12f4-freebsd-i386-2fee22adec101e2f952a5548fd1437ce1bd8d26f.tar.bz2

@alexcrichton fixes the build bot failures due to unused imports being treated as errors.

r? @alexcrichton