Implement downcast the like it exists for Box.

The implementation avoids using into_raw/from_raw, because the pointer
arithmetic which should cancel does not seem to optimize out at the
moment.

Since Rc<T> is never Send, only Rc<Any> and not Rc<Any + Send>
implements downcast.

On Windows, the gcc crate would send /Wall to msvc, which would cause
builds to get flooded with warnings, exploding compile times from one
hour to more than 72! The gcc crate version 0.3.54 changes this behavior
to send /W4 instead, which greatly cuts down on cl.exe flooding the
command prompt window with warnings.

In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to
fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn
batch scripts they need to be manually spawned with `cmd /c` instead now. This
updates the compiler to handle this case explicitly for Emscripten.

Closes rust-lang#42791

cc rust-lang#44270

Removing unwanted file merged in  a previous commit

Most of the other rust-lang buckets are in us-west-1 and I think the original
bucket was just accidentally created in the us-east-1 region. Let's consolidate
by moving it to the same location as the rest of our buckets.

`FlatMap` can use internal iteration for its `fold`, which shows a
performance advantage in the new benchmarks:

    test iter::bench_flat_map_chain_ref_sum ... bench:   4,354,111 ns/iter (+/- 108,871)
    test iter::bench_flat_map_chain_sum     ... bench:     468,167 ns/iter (+/- 2,274)
    test iter::bench_flat_map_ref_sum       ... bench:     449,616 ns/iter (+/- 6,257)
    test iter::bench_flat_map_sum           ... bench:     348,010 ns/iter (+/- 1,227)

... where the "ref" benches are using `by_ref()` that isn't optimized.
So this change shows a decent advantage on its own, but much more when
combined with a `chain` iterator that also optimizes `fold`.

This commit alters the `query` function in the dep graph module to preallocate
memory using `with_capacity` instead of relying on automatic growth. Discovered
in rust-lang#44576 it was found that for the syntex_syntax clean incremental benchmark
the peak memory usage was found when the dep graph was being saved, particularly
the `DepGraphQuery` data structure itself. PRs like rust-lang#44142 which add more
queries end up just making this much larger!

I didn't see an immediately obvious way to reduce the size of the
`DepGraphQuery` object, but it turns out that `with_capacity` helps quite a bit!
Locally 831 MB was used [before] this commit, and 770 MB is in use at the peak
of the compiler [after] this commit. That's a nice 7.5% improvement! This won't
quite make up for the losses in rust-lang#44142 but I figured it's a good start.

[before]: https://gist.github.com/alexcrichton/2d2b9c7a65503761925c5a0bcfeb0d1e
[before]: https://gist.github.com/alexcrichton/6da51f2a6184bfb81694cc44f06deb5b

fixes rust-lang#40491

Just a routine update

updated clippy and rls as it uses the iterator_for_each

Right now we comiple rustdoc in stage 2 and the error index in stage 0, which
ends up compiling rustdoc twice! To avoid compiling rustdoc twice (which takes
awhile) let's just compile it once in stage 2.

Should help suppress some warnings from various repos as `cmake` in the newest
version disables warnings by default.

Our OSX builders are routinely and significantly over hour 2 hour "soft limit"
for testing PRs. I *think* that a big portion of this time comes from the fact
that LLVM and debug assertions are enabled. In an effort to speed up these
builders and reduce cycle time this commit disables LLVM assertions on OSX for
all builders.

My thinking is that we'll let this bake for a bit after merged to see what the
effect is on timing on Travis. If it doesn't actually help much we can turn them
back on, and if it doesn't help enough we can disable Rust debug assertions as
well.

Previously it would use the librustc output directory which would cause rustdoc
to get entirely recompiled, whereas the intention is that it uses the
already-compiled artifacts from building rustdoc itself, using the tool output
directory

implement unsafe pointer methods

I also cleaned up some existing documentation a bit here or there since I was doing so much auditing of it. Most notably I significantly rewrote the `offset` docs to clarify safety (`*const` and `*mut`'s offset docs had actually diverged).

…ig, r=alexcrichton

Remove Borrow bound from SliceExt::binary_search

rust-lang#37761 added a Borrow bound to `binary_search` and `binary_search_by_key` in `core::SliceExt`, but did not add it to the methods in `std::slice`. rust-lang#41590 attempted to add this bound to `std::slice` but was not merged due to breakage. This PR removes the bound in `core::SliceExt`, so that these methods will have the same signature in `core` and `std`.

Fixes rust-lang#41561

Implement <Rc<Any>>::downcast

* Implement `<Rc<Any>>::downcast::<T>`
  * New unstable method. Works just like Box\<Any\>, but for Rc.
  * Any has two cases for its methods: Any and Any + Send; Rc is never Send, so that case is skipped for Rc.
  * Motivation for being a method with self is to match Box and there is no user-supplied type; the inner type is Any and downcast does not conflict with any method of Any.
* Arc was skipped because Any itself has no downcast for the case that makes most sense: Any + Send + Sync

…crichton

Attempt to fix the component manifest problem for rls-preview

cc rust-lang#44270

See rust-lang#44270

Ipv4Addr and Ipv6Addr convenience constructors.

Introduce convenience constructors for common types.

This introduces the following constructors:

* Ipv6Addr::localhost()
* Ipv6Addr::unspecified()
* Ipv4Addr::localhost()
* Ipv4Addr::unspecified()

The recently added `From` implementations were nice for avoiding the fallibility of conversions from strings like `"127.0.0.1".parse().unwrap()`, and `"::1".parse().unwrap()`, but while the Ipv4 version is roughly comparable in verbosity, the Ipv6 version lacks zero-segment elision, which makes it significantly more awkward: `[0, 0, 0, 0, 0, 0, 0, 0].into()`.  While there isn't a clear way to introduce zero elision to type that can infallibly be converted into Ipv6 addresses, this PR resolves the problem for the two most commonly used addresses, which, incidentally, are the ones that suffer the most from the lack of zero-segment elision.

This change is dead simple, and introduces no backwards incompatibility.

See also, [this topic on the inernals board](https://internals.rust-lang.org/t/pre-rfc-convenience-ip-address-constructors/5878)

…uietMisdreavus

Codeblock color

<img width="1440" alt="screen shot 2017-09-07 at 21 53 58" src="https://user-images.githubusercontent.com/3050060/30183045-4319108e-9419-11e7-98da-da54952cab37.png">

This screenshot has been generated from:

```rust
/// foo
///
/// ```compile_fail
/// foo();
/// ```
///
/// ```ignore
/// goo();
/// ```
///
/// ```
/// let x = 0;
/// ```
pub fn bar() -> usize { 2 }
```

r? @QuietMisdreavus
cc @rust-lang/docs

{compiler-builtins,libc} shim cleanup

~~Depends on rust-lang/libc#764; opening early for feedback.~~ r? @alexcrichton

…chton

bump gcc for bootstrap

On Windows, the gcc crate would send /Wall to msvc, which would cause
builds to get flooded with warnings, exploding compile times from one
hour to more than 72! The gcc crate version 0.3.54 changes this behavior
to send /W4 instead, which greatly cuts down on cl.exe flooding the
command prompt window with warnings.

…, r=nikomatsakis

rustc: Spawn `cmd /c emcc.bat` explicitly

In rust-lang#42436 the behavior for spawning processes on Windows was tweaked slightly to
fix various bugs, but this caused rust-lang#42791 as a regression, namely that to spawn
batch scripts they need to be manually spawned with `cmd /c` instead now. This
updates the compiler to handle this case explicitly for Emscripten.

Closes rust-lang#42791

extend E0623 for earlybound and latebound for structs

This fixes rust-lang#44508

r? @nikomatsakis

bring TyCtxt into scope

got comments both from @eddyb and @nikomatsakis (via rust-lang#44505) that we should always put `TyCtxt` in scope

should I just go and import it at other places in the codebase or we just keep doing small improvements?

rustdoc: pretty-print Unevaluated expressions in types.

Fixes rust-lang#44555.

r? @nikomatsakis

… r=alexcrichton

stabilized iterator_for_each (closes rust-lang#42986)

Also updated clippy and rls as these use the iterator_for_each

I've made my first PR's today so most likely I've done something wrong. Sorry about that!

…aidanhs

travis: Move sccache to the us-west-1 region

Most of the other rust-lang buckets are in us-west-1 and I think the original
bucket was just accidentally created in the us-east-1 region. Let's consolidate
by moving it to the same location as the rest of our buckets.

Customize `<FlatMap as Iterator>::fold`

`FlatMap` can use internal iteration for its `fold`, which shows a
performance advantage in the new benchmarks:

    test iter::bench_flat_map_chain_ref_sum ... bench:   4,354,111 ns/iter (+/- 108,871)
    test iter::bench_flat_map_chain_sum     ... bench:     468,167 ns/iter (+/- 2,274)
    test iter::bench_flat_map_ref_sum       ... bench:     449,616 ns/iter (+/- 6,257)
    test iter::bench_flat_map_sum           ... bench:     348,010 ns/iter (+/- 1,227)

... where the "ref" benches are using `by_ref()` that isn't optimized.
So this change shows a decent advantage on its own, but much more when
combined with a `chain` iterator that also optimizes `fold`.

…elwoerister

rustc: Preallocate when building the dep graph

This commit alters the `query` function in the dep graph module to preallocate
memory using `with_capacity` instead of relying on automatic growth. Discovered
in rust-lang#44576 it was found that for the syntex_syntax clean incremental benchmark
the peak memory usage was found when the dep graph was being saved, particularly
the `DepGraphQuery` data structure itself. PRs like rust-lang#44142 which add more
queries end up just making this much larger!

I didn't see an immediately obvious way to reduce the size of the
`DepGraphQuery` object, but it turns out that `with_capacity` helps quite a bit!
Locally 831 MB was used [before] this commit, and 770 MB is in use at the peak
of the compiler [after] this commit. That's a nice 7.5% improvement! This won't
quite make up for the losses in rust-lang#44142 but I figured it's a good start.

[before]: https://gist.github.com/alexcrichton/2d2b9c7a65503761925c5a0bcfeb0d1e
[before]: https://gist.github.com/alexcrichton/6da51f2a6184bfb81694cc44f06deb5b

Require +thumb-mode to generate thumb2 code for Android/armv7-a

I am investigating rust's code generation into Gecko by https://bugzilla.mozilla.org/show_bug.cgi?id=1399337.

armv7-linux-androideabi target uses `+v7,+thumb2,+vfp3,+d16,-neon` as target-feature.  But `+thumb2` only doesn't generate thumb2 code.  To generate thumb2 code, it requires `+thumb-mode`.  So we should add it for armv7-linux-androideabi.

r? @alexcrichton

…=eddyb

Get `allow(unused_mut)` to work on `let` bindings

fixes rust-lang#40491

…xcrichton

stabilized ord_max_min (fixes rust-lang#25663)

update rust-installer

Fixes <rust-lang#44594>

r? @alexcrichton

…imulacrum

Update cargo submodule

Just a routine update

…imulacrum

rustbuild: Compile the error-index in stage 2

Right now we comiple rustdoc in stage 2 and the error index in stage 0, which
ends up compiling rustdoc twice! To avoid compiling rustdoc twice (which takes
awhile) let's just compile it once in stage 2.

…imulacrum

rustbuild: Update `cmake` dependency

Should help suppress some warnings from various repos as `cmake` in the newest
version disables warnings by default.

Mention that HashMap::new and HashSet::new do not allocate

The docs for `HashMap::with_capacity` and `HashSet::with_capacity` already say that
> If `capacity` is 0, the hash map/set will not allocate.
However, the docs for `::new` do not say that the initial capacity is 0, and thus promise that a call to `::new` alone does not allocate. This PR fixes that.

…ark-Simulacrum

travis: Disable LLVM assertions on OSX

Our OSX builders are routinely and significantly over hour 2 hour "soft limit"
for testing PRs. I *think* that a big portion of this time comes from the fact
that LLVM and debug assertions are enabled. In an effort to speed up these
builders and reduce cycle time this commit disables LLVM assertions on OSX for
all builders.

My thinking is that we'll let this bake for a bit after merged to see what the
effect is on timing on Travis. If it doesn't actually help much we can turn them
back on, and if it doesn't help enough we can disable Rust debug assertions as
well.

…, r=Mark-Simulacrum

rustbuild: Fix test "test rustdoc" invocation

Previously it would use the librustc output directory which would cause rustdoc
to get entirely recompiled, whereas the intention is that it uses the
already-compiled artifacts from building rustdoc itself, using the tool output
directory