This alters the stdio code on Windows to always call `GetStdHandle` whenever the
stdio read/write functions are called as this allows us to track changes to the
value over time (such as if a process calls `SetStdHandle` while it's running).

Closes rust-lang#40490

Now that we've also updated cargo's release process this commit also changes the
download location of Cargo from Cargos archives back to the static.r-l.o
archives. This should ensure that the Cargo download is the exact Cargo paired
with the rustc that we release.

This "on-demand" task both checks for errors and computes the custom
unsized kind, if any. This task is only defined on impls of
`CoerceUnsized`; invoking it on any other kind of impl results in a bug.
This is just to avoid having an `Option`, could easily be changed.

Top-down, top-down!

When the Range expression is the root of a constant, its node-id is
used for the def-id of the body, so it has to be preserved in the AST ->
HIR lowering.

Fixes rust-lang#40749.

There are now 3 queries:

- inherent_impls(def-id): for a given type, get a `Rc<Vec<DefId>>` with
  all its inherent impls. This internally uses `crate_inherent_impls`,
  doing some hacks to keep the current deps (which, btw, are not clearly
  correct).
- crate_inherent_impls(crate): gathers up a map from types
  to `Rc<Vec<DefId>>`, touching the entire krate, possibly generating
  errors.
- crate_inherent_impls_overlap_check(crate): performs overlap checks
  between the inherent impls for a given type, generating errors.

This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.

The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:

    #![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
    #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]

This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:

* Mark themselves as entirely unstable via the `staged_api` feature and the
  `#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
  required if the crate relies on any other crates to compile (other than std).

I'm not really sure what we want the cadence here to be. We'll at the very least
update the Cargo submodule right before all releases, but otherwise I figured we
could just do it whenever needed or otherwise weekly (or something like that).

In any case, I don't have a super strong particular reason to do this, it's just
been a week or so since the release!

Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:

* Relying on run-time data means we can't show concrete examples of how
  these methods work up-front. The user is required to run them in order
  to see how they behave.
* If the user tries to run an example in the playpen, it won't work
  because the playpen doesn't support user input to stdin.

…n macros.

This change slightly changes the main iteration loop so that LLVM can
optimize it more efficiently.

Benchmark:

name                                   before ns/iter   after ns/iter    diff ns/iter   diff %
slice::sort_unstable_small_ascending   39 (2051 MB/s)   38 (2105 MB/s)             -1   -2.56%
slice::sort_unstable_small_big_random  579 (2210 MB/s)  575 (2226 MB/s)            -4   -0.69%
slice::sort_unstable_small_descending  80 (1000 MB/s)   70 (1142 MB/s)            -10  -12.50%
slice::sort_unstable_small_random      396 (202 MB/s)   386                       -10   -2.53%

Looks like the last version was built with mio 0.6.5 which now has known bugs
against it. This build includes mio 0.6.6

Remove internal liblog

This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.

The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:

    #![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
    #![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]

This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:

* Mark themselves as entirely unstable via the `staged_api` feature and the
  `#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
  required if the crate relies on any other crates to compile (other than std).

Allow `use` macro imports to shadow global macros

Terminology:
 - global scope: builtin macros, macros from the prelude, `#[macro_use]`, or `#![plugin(..)]`.
 - legacy scope: crate-local `macro_rules!`.
 - modern scope: `use` macro imports, `macro` (once implemented).

Today, the legacy scope can shadow the global scope (modulo RFC 1560 expanded shadowing restrictions). However, the modern scope cannot shadow or be shadowed by either the global or legacy scopes, leading to ambiguity errors.

This PR allows the modern scope to shadow the global scope (subject to some restrictions).
More specifically, a name in the global scope is as shadowable as a glob import in the module `self`. In other words, we imagine a special, implicit glob import in each module item:
```rust
mod foo {
    #[lexical_only] // Not accessible via `foo::<name>`, like pre-RFC 1560 `use` imports.
    #[shadowable_by_legacy_scope] // for back-compat
    use <global_macros>::*;
}
```

r? @nrc

…uron

std: Don't cache stdio handles on Windows

This alters the stdio code on Windows to always call `GetStdHandle` whenever the
stdio read/write functions are called as this allows us to track changes to the
value over time (such as if a process calls `SetStdHandle` while it's running).

Closes rust-lang#40490

rustbuild: Update bootstrap compiler

Now that we've also updated cargo's release process this commit also changes the
download location of Cargo from Cargos archives back to the static.r-l.o
archives. This should ensure that the Cargo download is the exact Cargo paired
with the rustc that we release.

…ikomatsakis

On-demandify the typechecking of item bodies

r? @nikomatsakis

…=GuillaumeGomez

Rewrite `io::BufRead` doc examples to better demonstrate behaviors.

Prior to this commit, most of the `BufRead` examples used `StdinLock` to
demonstrate how certain `BufRead` methods worked. Using `StdinLock` is
not ideal since:

* Relying on run-time data means we can't show concrete examples of how
  these methods work up-front. The user is required to run them in order
  to see how they behave.
* If the user tries to run an example in the playpen, it won't work
  because the playpen doesn't support user input to stdin.

…ed-info, r=eddyb

on-demand-ify `custom_coerce_unsized_kind` and `inherent-impls`

This "on-demand" task both checks for errors and computes the custom unsized kind, if any. This task is only defined on impls of `CoerceUnsized`; invoking it on any other kind of impl results in a bug. This is just to avoid having an `Option`, could easily be changed.

r? @eddyb

keep the AST node-id when lowering ExprKind::Range

When the Range expression is the root of a constant, its node-id is
used for the def-id of the body, so it has to be preserved in the AST ->
HIR lowering.

Fixes rust-lang#40749.

r? @eddyb
beta-nominating because regression

…ichton

Update cargo submodule

I'm not really sure what we want the cadence here to be. We'll at the very least
update the Cargo submodule right before all releases, but otherwise I figured we
could just do it whenever needed or otherwise weekly (or something like that).

In any case, I don't have a super strong particular reason to do this, it's just
been a week or so since the release!

…=alexcrichton

Optimize insertion sort

This change slightly changes the main iteration loop so that LLVM can optimize it more efficiently.

Benchmark:

```
name                                   before ns/iter   after ns/iter    diff ns/iter   diff %
slice::sort_unstable_small_ascending   39 (2051 MB/s)   38 (2105 MB/s)             -1   -2.56%
slice::sort_unstable_small_big_random  579 (2210 MB/s)  575 (2226 MB/s)            -4   -0.69%
slice::sort_unstable_small_descending  80 (1000 MB/s)   70 (1142 MB/s)            -10  -12.50%
slice::sort_unstable_small_random      396 (202 MB/s)   386                       -10   -2.53%
```

The benchmark is not a fluke. I can see that performance on `small_descending` is consistently better after this change. I'm not 100% sure why this makes things faster, but my guess would be that `v.len()+1` to the compiler looks like it could in theory overflow.

…r=alexcrichton

travis: Update sccache again

Looks like the last version was built with mio 0.6.5 which now has known bugs
against it. This build includes mio 0.6.6