Unfortunately what we're using right now, Xcode 8.2, cannot compile LLVM for OSX
10.7. We've done this historically and Gecko would like to maintain this
compabitiliby. This commit moves our release builders for OSX to using Xcode 7
which can compile LLVM for 10.7.

The builders running tests continue to use Xcode 8.2, however, because the LLDB
version with Xcode 7, 350, is blacklisted in running our LLDB tests. To continue
running LLDB tests we'll stick with Xcode 8.2.

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 #40749.

r? @EddyB
beta-nominating because regression

Rollup of 7 pull requests

- Successful merges: #40642, #40734, #40740, #40771, #40807, #40820, #40821
- Failed merges:

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

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).

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

try to fix the build on emscripten

The "upstream" emscripten tar.gz now extracts to `emsdk-portable` instead of `emsdk_portable`, breaking our CI. It might be better to vendor a specific version of emscripten instead of using the latest, but I could not find a good way of doing that.

r? @alexcrichton

try to fix the build on emscripten

The "upstream" emscripten tar.gz now extracts to `emsdk-portable` instead of `emsdk_portable`, breaking our CI. It might be better to vendor a specific version of emscripten instead of using the latest, but I could not find a good way of doing that.

r? @alexcrichton

Fix typo in dec2flt/algorithm.rs

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.

"on-demandify" privacy and access levels

r? @EddyB
cc @cramertj https://github.com/rust-lang/rust/issues/40746

Basic documentation for inclusive range syntax

Done so that we can remove mention of this from the stable documentation ⚠️.

Add warning for use of lifetime parameter with 'static bound

Previously a `'static` lifetime bound would result in an `undeclared lifetime` error when compiling, even though it could be considered valid.

However, it is unnecessary to use it as a lifetime bound so we present the user with a warning instead and suggest using the `'static` lifetime directly, in place of the lifetime parameter. We can change this to an error (or warning with lint) if that's decided to be more appropriate.

Example output:
```
warning: unnecessary lifetime parameter `'a`
 --> ../static-lifetime-bound.rs:3:10
  |
3 | fn f<'a: 'static>(val: &'a i32) {
  |      ^^^^^^^^^^^
  |
  = help: you can use the `'static` lifetime directly, in place `'a`
```

Fixes #40661

r? @jseyfried

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.

The emsdk-portable .tar.gz now extracts to emsdk-portable instead of
emsdk_portable. Handle that.

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

Previously a `'static` lifetime bound would result in an `undeclared
lifetime` error when compiling, even though it could be considered
valid.

However, it is unnecessary to use it as a lifetime bound so we present
the user with a warning instead and suggest using the `'static` lifetime
directly, in place of the lifetime parameter.

Rollup of 8 pull requests

- Successful merges: #40567, #40602, #40636, #40739, #40756, #40790, #40794, #40803
- Failed merges:

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%

Update CONTRIBUTING.md regarding documentation contributions

Changed link to documentation issues from A-docs to T-doc as this has just been migrated.
Added a link to the documentation style guidelines in RFC 1574 (I've linked to [Appendix A][1] specifically since that's the combined version).

r? @steveklabnik

[1]: https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text

Fix formatting in the docs for std::process::Command::envs()

An empty line between the *Basic usage:* text and the example is required to properly format the code. Without the empty line, the example is not formatted as code.

[Here](https://doc.rust-lang.org/std/process/struct.Command.html#method.envs) you can see the current (improper) formatting.

Unnecessary iteration in BTreeMap::drop

`IntoIter::drop` already iterates.

Fix markdown links to pdqsort

r? @alexcrichton

Simplify hash table drops

This replaces the `std::collections::hash::table::RevMoveBuckets`
iterator with a simpler `while` loop.  This iterator was only used for
dropping the remaining elements of a `RawTable`, so instead we can just
loop through directly and drop them in place.

This should be functionally equivalent to the former code, but a little
easier to read.  I was hoping it might have some performance benefit
too, but it seems the optimizer was already good enough to see through
the iterator -- the generated code is nearly the same.  Maybe it will
still help if an element type has more complicated drop code.

Revert #39485, fixing type-inference regressions

This reverts PR #39485, which should fix the immediate regressions. Eventually I'd like to land https://github.com/rust-lang/rust/pull/40224 -- or some variant of it -- which revisits the question fo dead-code and inference.

r? @EddyB
cc @canndrew

Represent function pointers in mir-constants as a Value instead of Item

r? @EddyB

Fix for #39596: sort Trait2 before Trait10.

This is a change discussed in #39596. Essentially, item names will be sorted as if they're (&str, u64) pairs instead of just `&str`, meaning that `"Apple" < "Banana"` and also `"Fruit10" > "Fruit2"`.

Sample sorting:

1. Apple
2. Banana
3. Fruit
4. Fruit0
5. Fruit00
6. Fruit1
7. Fruit01
8. Fruit2
9. Fruit02
10. Fruit20
11. Fruit100
12. Pear

Examples of generated documentation:
https://docs.charr.xyz/before-doc/test_sorting/
https://docs.charr.xyz/after-doc/test_sorting/

Screenshots of generated documentation:
Before: http://imgur.com/Ktb10ti
After: http://imgur.com/CZJjqIN

update LLVM with fix for PR32379

Fixes #40593.

The "root" codegen bug fixed here is that, when generating ARM code, unpatched LLVM 3.9/3.9.1 miscompiles bit operations in rare circumstances - this can cause user code compiled via LLVM (through both `rustc` and `clang`) to subtly return incorrect results - for more details, see the test in this PR or in the LLVM rare report.

One effect of that LLVM bug is that `rustc` 1.17 (and possibly other versions) is miscompiled on ARM. The code generated by a miscompiled `rustc` lacks destructor calls in many circumstances.

Users who run an affected/miscompiled `rustc` - 1.17 or above - on an ARM build machine will be affected by the (fairly blatant) missing destructor bug, regardless of the target architecture (this includes the official `1.17.0-beta.1`, `1.17.0-beta.2`, and some official 1.17/1.18 nightlies).

Users who use an affected LLVM (that's any unpatched LLVM 3.9/3.9.1), whether through `rustc` (in any version that supports 3.9 - that's 1.12 or above) or through `clang`, who compile code to an ARM target architecture might be affected by the (fairly hard to hit) bit operation bug, regardless of the build machine.

Distributors and user who want to compile rustc using their own LLVM should apply the [patch](https://github.com/llvm-mirror/llvm/commit/cdc303e5ed4d3110e6f70931775a70bb1de44ed6) to avoid miscompilations.

r? @alexcrichton
Beta-nominating because regression (rustc 1.16 is not blatantly miscompiled). This also picks a fix for the (MSVC-affecting) PR29151.

Changed link to documentation issues from A-docs to T-doc as this has just been migrated.
Added a link to the documentation style guidelines.

appveyor: Upgrade MinGW toolchains we use

In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.

When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.

I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.

Closes #40546

In debugging #40546 I was able to reproduce locally finally using
the literal toolchain that the bots were using. I reproduced the error maybe 4
in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which
has yet to have a failed build.

When attempting to reproduce the bug with the toolchain that this commit
switches to I was unable to reproduce anything after a few builds. I have no
idea what the original problem was, but I'm hoping that it was just some random
bug fixed somewhere along the way.

I don't currently know of a technical reason to stick to the 4.9.2 toolchains we
were previously using. Historcal 5.3.* toolchains would cause llvm to segfault
(maybe a miscompile?) but this seems to have been fixed recently. To me if it
passes CI then I think we're good.

Closes #40546

travis: See if OSX generates crash dumps

I know for a fact we've had sccache segfault on various platforms and we've also
historically had a lot of problems with the linker on OSX. Let's just poke
around in the crash log directory to see if anything exists. If in the future we
see a build we think segfaulted *and* there's contents here then we can add some
bits that actually print out the logs.

The person who originally wrote the example forgot to include this attribute.
This caused Travis CI to fail on commit 9b0a4a4e (#40794), which just fixed
formatting in the description of std::process::Command::envs().