Until some backwards-compatibility hazards are fixed in #23121,
these need to be unstable.

[breaking-change]

before:

test bench_read_slice  ... bench:        68 ns/iter (+/- 56)
test bench_read_vec    ... bench:        78 ns/iter (+/- 21)
test bench_write_slice ... bench:       133 ns/iter (+/- 46)
test bench_write_vec   ... bench:       308 ns/iter (+/- 69)

after:

test bench_read_slice  ... bench:        32 ns/iter (+/- 10)
test bench_read_vec    ... bench:        32 ns/iter (+/- 8)
test bench_write_slice ... bench:        53 ns/iter (+/- 12)
test bench_write_vec   ... bench:       247 ns/iter (+/- 172)

This PR adds support for associated types to the `#[derive(...)]` syntax extension. In order to do this, it switches over to using where predicates to apply the type constraints. So now this:

```rust
type Trait {
    type Type;
}

#[derive(Clone)]
struct Foo<A> where A: Trait {
    a: A,
    b: <A as Trait>::Type,
}
```

Gets expended into this impl:

```rust
impl<A: Clone> Clone for Foo<A> where
    A: Trait,
    <A as Trait>::Type: Clone,
{
    fn clone(&self) -> Foo<T> {
        Foo {
            a: self.a.clone(),
            b: self.b.clone(),
        }
    }
}
```

This commits adds back an `IpAddr` enum matching the `SocketAddr` enum, but
without a port. The enumeration is `#[unstable]`. The `lookup_host` function and
iterator are also destabilized behind a new feature gate due to questions around
the semantics of returning `SocketAddr` values.

I've started on refactoring the error handling code to avoid the need to reparse generated errors in `span_*`, but would rather land this incrementally as one monolithic PR (and have un-fond memories of merge conflicts from various other monoliths)

r? @EddyB 

This doesn't actually solve the issue that prompted this, at:

https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs#L262-271

But skimming the cfg it appears that all type information has been
discarded long before that point.

It's considered an error to access stdout while a process is being shut down, so
tweak this test a bit to actually wait for the child thread to exit.

This was discovered with a recent [snap-mac3 failure](http://buildbot.rust-lang.org/builders/snap3-mac/builds/164/steps/test/logs/stdio)

This commits adds back an `IpAddr` enum matching the `SocketAddr` enum, but
without a port. The enumeration is `#[unstable]`. The `lookup_host` function and
iterator are also destabilized behind a new feature gate due to questions around
the semantics of returning `SocketAddr` values.

It's considered an error to access stdout while a process is being shut down, so
tweak this test a bit to actually wait for the child thread to exit.

1. when mac-android cross compile and make-check , make it use gdb instead of lldb so as to it passes debuginfo tests.
2. ignore some tests on aarch64

Now that we check the stability of fields, the fields of this struct should also
be stable.

When built with `rustc -O`:

before:

test bench_read_slice  ... bench:        68 ns/iter (+/- 56)
test bench_read_vec    ... bench:        78 ns/iter (+/- 21)
test bench_write_slice ... bench:       133 ns/iter (+/- 46)
test bench_write_vec   ... bench:       308 ns/iter (+/- 69)

after:

test bench_read_slice  ... bench:        32 ns/iter (+/- 10)
test bench_read_vec    ... bench:        32 ns/iter (+/- 8)
test bench_write_slice ... bench:        53 ns/iter (+/- 12)
test bench_write_vec   ... bench:       247 ns/iter (+/- 172)

- Successful merges: #23617, #23664, #23680, #23684, #23692, #23693
- Failed merges: 

 The reassignment checker effectively only checks whether the last
assignment in a body affects the discriminant, but it should of course
check all the assignments.

Fixes #23698

`PathBuf::new` have been changed. Use `PathBuf::from` instead.

Apply the same change for freebsd too, while here.

Disable overflow checking on SIMD operations, fix #23037

r? @aturon cc @alexcrichton

The reassignment checker effectively only checks whether the last
assignment in a body affects the discriminant, but it should of course
check all the assignments.

Fixes #23698

Main motivation was to update docs for the removal or "demotion" of certain extension traits. The update to the slice docs was larger, since the text was largely outdated.

Fixes #23564

Makes Vec::push considerably smaller: 25 instructions, rather than 42, on
x86_64.

`PathBuf::new` have been changed. Use `PathBuf::from` instead.

Apply the same change for freebsd too, while here.

Disable overflow checking on SIMD operations, fix #23037

The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.

This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.

cc #23533

Reject specialized Drop impls.

See Issue #8142 for discussion.

This makes it illegal for a Drop impl to be more specialized than the original item.

So for example, all of the following are now rejected (when they would have been blindly accepted before):

```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type

struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region

struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement

struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```

Due to examples like the above, this is a [breaking-change].

(The fix is to either remove the specialization from the `Drop` impl, or to transcribe the requirements into the struct/enum definition; examples of both are shown in the PR's fixed to `libstd`.)

----

This is likely to be the last thing blocking the removal of the `#[unsafe_destructor]` attribute.

Fix #8142
Fix #23584

The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.

This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.

cc #23533

The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.

This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.

cc #23533

This commit alters the behavior of the `Read::read_to_end()` method to zero all
memory instead of passing an uninitialized buffer to `read`. This change is
motivated by the [discussion on the internals forum][discuss] where the
conclusion has been that the standard library will not expose uninitialized
memory.

[discuss]: http://internals.rust-lang.org/t/uninitialized-memory/1652

Closes #20314

I assume since both shifts say the same thing, I should fix both of them, but then I realized I don't strictly know about left shift.

Fixes #23421

r? @pnkfelix