fix build errors

tweak links

add link to contribution guidelines and IRC room

Add contribution instructions to stdlib docs

Auto merge of #40758 - frewsxcv:rollup, r=frewsxcv

Rollup of 5 pull requests

- Successful merges: #40612, #40627, #40668, #40715, #40753
- Failed merges:

Rollup merge of #40753 - mandeep:change-ObjectSafetyViolation-message, r=brson

Change object safety violation message

Hello!

This is my first pull request to rust so hopefully all goes well. This PR should fix issue #40670. I changed the error message in object_safety.rs and the corresponding compile-fail test in object-safety-supertrait-mentions-Self.rs.

Once the changes were made, I ran ```python x.py test src/tools/tidy``` and ```python x.py test```. Tidy passed and the compile-fail tests passed, however the test suite failed on the tcp tests as my machine has IPv6 disabled. I'm not sure what to do in this case besides letting travis run the suite against my changes. Please let me know if there's anything I can do to help further.

Thanks!
Mandeep

Rollup merge of #40715 - manuel-rhdt:patch-1, r=brson

Fix doc error for ExactSizeIterator

The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.

This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.

Rollup merge of #40668 - cramertj:on-demandify-more, r=nikomatsakis

On-demandify associated item retrieval

Part of #40614.

I also started converting `adt_def`, but I decided to open a PR with just this bit first to make sure I'm going about this correctly.

r? @nikomatsakis

Rollup merge of #40627 - estebank:pub-restricted, r=petrochenkov

Add diagnostic for incorrect `pub (restriction)`

Given the following statement

```rust
pub (a) fn afn() {}
```

Provide the following diagnostic:

```rust
error: incorrect restriction in `pub`
  --> file.rs:15:1
   |
15 | pub (a) fn afn() {}
   |     ^^^
   |
   = help: some valid visibility restrictions are:
           `pub(crate)`: visible only on the current crate
           `pub(super)`: visible only in the current module's parent
           `pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
   | pub (in a) fn afn() {}
```

Follow up to #40340, fix #40599, cc #32409.

Rollup merge of #40612 - TimNN:new-netbsd-cross, r=alexcrichton

Use the "official" cross compiler for NetBSD

The current NetBSD cross compiler is lacking, for example `std::thread` is not available (which causes problems for LLVM 4.0). This PR uses the official netbsd build system to compiler the cross compiler.

@alexcrichton: Can you please mirror `ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/source/sets/{src,gnusrc,sharesrc,syssrc}.tgz`. (Optionally you may want to use NetBSD versions 7.0.2 or 7.1, in that case you'll probably want to update the binary downloads used today as well).

I'll update the URL's afterwards (or feel free to use "allow edits from maintainers").

r? @alexcrichton

Auto merge of #40605 - alexcrichton:add-stamps, r=brson

travis: Add timestamps to all build messages

When debugging why builds are taking so long it's often useful to get the
timestamp of all log messages as we're not always timing every tiny step of the
build. I wrote a [utility] for prepending a relative timestamp from the start of
a process which is now downloaded to the builders and is what we wrap the entire
build invocation in.

[utility]: https://github.com/alexcrichton/stamp-rs

Closes #40577

Auto merge of #40549 - alexcrichton:uwtable-everywhere, r=eddyb

rustc: Always emit the `uwtable` attribute on Windows

This commit alters the translation layer to unconditionally emit the `uwtable`
LLVM attribute on Windows regardless of the `no_landing_pads` setting.
Previously I believe we omitted this attribute as an optimization when the
`-Cpanic=abort` flag was passed, but this unfortunately caused problems for
Gecko.

It [was discovered] that there was trouble unwinding through Rust functions due
to foreign exceptions such as illegal instructions or otherwise in-practice
methods used to abort a process. In testing it looked like the major difference
between a working binary and a non-working binary is indeed this `uwtable`
attribute, but this PR has unfortunately not been thoroughly tested in terms of
compiling Gecko with `-C panic=abort` *and* this PR to see whether it works, so
this is still somewhat working on just suspicion.

[was discovered]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078

Auto merge of #40515 - alexcrichton:tarball-names, r=brson

rustbuild: Don't hardcode 'nightly' for Cargo

It now follows rustc release trains. I also had to land this commit on beta (https://github.com/rust-lang/rust/commit/0a27a8713bdca09564ffd298fce8f760e47775af) before https://github.com/rust-lang/rust/pull/40484 could land, so this is basically just a forward port (if you will) of that commit to master.

Add diagnostic for incorrect `pub (restriction)`

Given the following statement

```rust
pub (a) fn afn() {}
```

Provide the following diagnostic:

```rust
error: incorrect restriction in `pub`
  --> file.rs:15:1
   |
15 | pub (a) fn afn() {}
   | ^^^^^^^
   |
   = help: some valid visibility restrictions are:
           `pub(crate)`: visible only on the current crate
           `pub(super)`: visible only in the current module's parent
           `pub(in path::to::module)`: visible only on the specified path
help: to make this visible only to module `a`, add `in` before the path:
   | pub (in a) fn afn() {}
```

Remove cruft from old `pub(path)` syntax.

Changed E0038 error message in test to comply with new message

Auto merge of #40752 - frewsxcv:rollup, r=frewsxcv

Rollup of 6 pull requests

- Successful merges: #39891, #40518, #40542, #40617, #40678, #40696
- Failed merges:

Rollup merge of #40696 - cramertj:remove-unused-adt-def-code, r=petrochenkov

Remove unused adt-def insertion by constructor DefIndex

It looks to me like ADT definitions weren't being looked up by constructor id, and a test run supports my theory.

In any case, I'm not sure it would have worked in its current configuration. If I understand correctly, the `adt_def` map entry from constructor id -> adt def would only be present after a successful call to `queries::adt_def::get` with the proper ADT `DefIndex`. Trying to look up an adt_def by the constructor index prior to a successful lookup by ADT index would fail since `item.kind` would be `EntryKind::Fn` (for the constructor function) and so would trigger the `bug!`.

r? @nikomatsakis

Rollup merge of #40678 - michaelwoerister:dmi-prep, r=nikomatsakis

Some preparations for directly computing the ICH of crate-metadata.

This PR contains some small fixes in preparation for direct metadata hashing. It mostly just moves stuff into places where it will be needed (making the module structure slightly cleaner along the way) and it fixes some omissions in the MIR region eraser.

r? @nikomatsakis

Rollup merge of #40617 - TimNN:dist-update-gcc, r=alexcrichton

Update gcc used for dist-x86-linux builds

GCC 4.7 is too old to build LLVM 4.0, so this PR updates to 4.8.

r? @alexcrichton (I'll ping you again once travis is green and the test commit is removed).

Rollup merge of #40542 - abonander:issue_40535, r=jseyfried

Correctly get source for metatdata-only crate type

Closes #40535

However, I'm not sure how to approach writing a regression test since I'm still working on a reduced test case from the code that caused the ICE in the first place. It's not enough to have an unknown `extern crate` in a metadata crate, it depends on a few extra arguments but I'm not sure which yet.

Also replaced the `unwrap()` with a more informative `expect()`.

r? @jseyfried

Rollup merge of #40518 - michaelwoerister:hir-id, r=eddyb

Introduce HirId, a replacement for ast::NodeId after lowering to HIR

This is the first step towards implementing #40303. This PR introduces the `HirId` type and generates a `HirId` for everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still use `NodeId` for now. Changing that is a big refactoring that I want to do in a separate PR.

A `HirId` uniquely identifies a node in the HIR of the current crate. It is composed of the `owner`, which is the `DefIndex` of the directly enclosing `hir::Item`, `hir::TraitItem`, or `hir::ImplItem` (i.e. the closest "item-like"), and the `local_id` which is unique within the given owner.

This PR is also running a number of consistency checks for the generated `HirId`s:
- Does `NodeId` in the HIR have a corresponding `HirId`?
- Is the `owner` part of each `HirId` consistent with its position in the HIR?
- Do the numerical values of the `local_id` part all lie within a dense range of integers?

cc @rust-lang/compiler

r? @eddyb or @nikomatsakis

Rollup merge of #39891 - shepmaster:emit-mir, r=nikomatsakis

Teach rustc --emit=mir

I'm opening this PR to discuss:

1. Is this a good idea?
1. Is this a good implementation?

I'm sure people will have opinions on both points!

This spawned from https://github.com/rust-lang/rust/issues/31847#issuecomment-279179057, so I figured a prototype implementation could help provide a seed to talk about.

Changed error message for ObjectSafetyViolation::SupertraitSelf

Auto merge of #40748 - frewsxcv:rollup, r=frewsxcv

Rollup of 13 pull requests

- Successful merges: #40509, #40523, #40548, #40578, #40619, #40689, #40690, #40692, #40704, #40722, #40723, #40725, #40732
- Failed merges:

Rollup merge of #40732 - petrochenkov:booktidy, r=steveklabnik

Update the book submodule and fix tidy

When the book was included into https://github.com/rust-lang/rust as a submodule, tidy started failing on Windows.
https://github.com/rust-lang/book/pull/549 fixed the problem, now the submodule needs to be updated.

Rollup merge of #40725 - Cldfire:master, r=estebank

Remove duplicated styling in main.css

If nothing else, it saves a bit of data.

Rollup merge of #40723 - SamWhited:e0090_error_explanation, r=estebank

E0090: Add explanation for error message

See #32777

    $ rustc --explain E0090
    The wrong number of lifetimes were supplied. For example:

    ```
    fn foo<'a: 'b, 'b: 'a>() {}

    fn main() {
        foo::<'static>(); // error, expected 2 lifetime parameters
    }
    ```

Rollup merge of #40722 - stjepang:doc-consistency-fixes, r=steveklabnik

Various fixes to wording consistency in the docs

A bunch of random fixes, added punctuation, plurals, backticks, and so on...

r? @steveklabnik

Rollup merge of #40704 - omtcyfz:clang_version_bump, r=alexcrichton

Nit: LLVM & Clang latest version is 4.0

Small nit: since latest Clang version is 4.0 it's nice to reflect this in the documentation.

Also, I couldn't find anything, but there might be any hard-coded check that Clang version matches "3.X" anywhere in the build system; if there is one, it'd be great to bump that one too.

Rollup merge of #40692 - SamWhited:consistent_str_docs_punctuation, r=bstrie

str: Make docs consistently punctuated

Every so slightly pointless one character PR, but this was driving me nuts while reading the docs a moment ago (all the [other public structs](https://doc.rust-lang.org/std/str/index.html#structs) have descriptions that end in a full-stop).

Rollup merge of #40690 - GuillaumeGomez:fix-iter-docs, r=frewsxcv

Fix invalid linking in iter docs

r? @rust-lang/docs

Rollup merge of #40689 - GuillaumeGomez:rustdoc-associated-type-formatting, r=frewsxcv

Add whitespace around "=" in assoc items

Part of #40641.

r? @rust-lang/docs

Before:

<img width="1440" alt="screen shot 2017-03-20 at 22 42 34" src="https://cloud.githubusercontent.com/assets/3050060/24123102/89181d8c-0dbe-11e7-897c-841497cf7001.png">

After:

<img width="1440" alt="screen shot 2017-03-20 at 22 42 36" src="https://cloud.githubusercontent.com/assets/3050060/24123118/8dec176e-0dbe-11e7-9759-cabbd062a4c2.png">

Rollup merge of #40619 - stjepang:unstable-book-sort-unstable, r=frewsxcv

Add docs for sort_unstable to unstable book

Tracking issue for the feature: #40585

r? @steveklabnik

Rollup merge of #40578 - michaelwoerister:shorter-compiletest-stamps, r=alexcrichton

Make the filenames of .stamp files generated by compiletest shorter

Otherwise we run into filename length limitations on some file systems. See https://bugs.launchpad.net/ecryptfs/+bug/344878 for an example where we only can have ~145 characters for filenames.

r? @alexcrichton

Rollup merge of #40548 - alexcrichton:appveyor-ninja, r=brson

appveyor: Use Ninja to build LLVM on MinGW

I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.

I'm not sure if this closes #40546 for real, but this is my current best shot at
closing it out, so...

Closes #40546

Rollup merge of #40523 - durka:patch-38, r=petrochenkov

add test for nested macro def (#31946)

Adds a test for issue #31946 which was fixed in 1.12.0.

Closes #31946.

Rollup merge of #40509 - jseyfried:duplicate_check_macro_exports, r=nrc

Forbid conflicts between macros 1.0 exports and macros 2.0 exports

This PR forbids for conflicts between `#[macro_export]`/`#[macro_reexport]` macro exports and `pub use` macro exports. For example,
```rust
// crate A:
pub use macros::foo;
//^ This is allowed today, will be forbidden by this PR.

// crate B:
extern crate A; // This triggers a confusing error today.
use A::foo; // This could refer to refer to either macro export in crate A.
```

r? @nrc

Add 'the' before 'start'/'end'

Various fixes to wording consistency in the docs

Allocate numerical values of DefIndexes from two seperate ranges.

This way we can have all item-likes occupy a dense range of
DefIndexes, which is good for making fast, array-based
dictionaries.

Introduce HirId, a replacement for NodeId after lowering to HIR.

HirId has a more stable representation than NodeId, meaning that
modifications to one item don't influence (part of) the IDs within
other items. The other part is a DefIndex for which there already
is a way of stable hashing and persistence.

This commit introduces the HirId type and generates a HirId for
every NodeId during HIR lowering, but the resulting values are
not yet used anywhere, except in consistency checks.

Implement indexed_vec::Idx for ast::NodeId

Add resize() method to IndexVec.

Update the book submodule and fix tidy

Address review comments.

Move some constants to rustc::ich.

Move CachingCodemapView to rustc::ich.

Move DefPathHashes to rustc::ich

Move Fingerprint to rustc::ich::Fingerprint.

Add some missing method impls to MIR region eraser.

Support more kinds of Regions in TypeIdHasher.

E0090: Expand error message explanation

Remove duplicate style classes

appveyor: Use Ninja to build LLVM on MinGW

I have a suspicion that MinGW's make is the cause of #40546 rather than anything
else, but that's purely a suspicion without any facts to back it up. In any case
we'll eventually be moving the MSVC build over to Ninja in order to leverage
sccache regardless, so this commit simply jumpstarts that process by downloading
Ninja for use by MinGW anyway.

I'm not sure if this closes #40546 for real, but this is my current best shot at
closing it out, so...

Closes #40546

Auto merge of #40043 - petrochenkov:objpars, r=nikomatsakis

Refactor parsing of trait object types

Bugs are fixed and code is cleaned up.

User visible changes:
- `ty` matcher in macros accepts trait object types like `Write + Send` (https://github.com/rust-lang/rust/issues/39080)
- Buggy priority of `+` in trait object types starting with `for` is fixed (https://github.com/rust-lang/rust/issues/39317). `&for<'a> Trait<'a> + Send` is now parsed as `(&for<'a> Trait<'a>) + Send` and requires parens `&(for<'a> Trait<'a> + Send)`. For comparison, `&Send + for<'a> Trait<'a>` was parsed like this since [Nov 27, 2014](https://github.com/rust-lang/rust/pull/19298).
- Trailing `+`s are supported in trait objects, like in other bounds.
- Better error reporting for trait objects starting with `?Sized`.

Fixes https://github.com/rust-lang/rust/issues/39080
Fixes https://github.com/rust-lang/rust/issues/39317 [breaking-change]
Closes https://github.com/rust-lang/rust/issues/39298
cc https://github.com/rust-lang/rust/issues/39085 (fixed, then reverted https://github.com/rust-lang/rust/pull/40043#issuecomment-286570653)
cc https://github.com/rust-lang/rust/issues/39318 (fixed, then reverted https://github.com/rust-lang/rust/pull/40043#issuecomment-284493890)

r? @nikomatsakis

E0090: Add explanation for error message

See #32777

Add warning about volatility of MIR output

Teach rustc --emit=mir

Auto merge of #40664 - jseyfried:fix_derive_bug, r=nrc

macros: fix bug in legacy custom derive processing

Fixes #40663.
r? @nrc

Add docs for sort_unstable to unstable book

Fix doc error for ExactSizeIterator

The code example in the trait documentation of ExactSizeIterator
has an incorrect implementation of the len method that does not return
the number of times the example iterator 'Counter' will iterate. This
may confuse readers of the docs as the example code will compile but
doesn't uphold the trait's contract.

This is easily fixed by modifying the implementation of len and changing
the assert statement to actually assert the correct behaviour. I also
slightly modified a code comment to better reflect what the method
returns.

Fix bug in legacy `#[derive]` processing logic.

travis: Don't enable quiet tests

This makes travis problems more difficult to debug, so let's just enable more
verbose logging.

travis: Add timestamps to all build messages

When debugging why builds are taking so long it's often useful to get the
timestamp of all log messages as we're not always timing every tiny step of the
build. I wrote a [utility] for prepending a relative timestamp from the start of
a process which is now downloaded to the builders and is what we wrap the entire
build invocation in.

[utility]: https://github.com/alexcrichton/stamp-rs

Closes #40577

Make the filenames of .stamp files generated by compiletest shorter.

Otherwise we run into filename length limitations on some file
systems (especially ecryptfs).

rustc: Always emit the `uwtable` attribute on Windows

This commit alters the translation layer to unconditionally emit the `uwtable`
LLVM attribute on Windows regardless of the `no_landing_pads` setting.
Previously I believe we omitted this attribute as an optimization when the
`-Cpanic=abort` flag was passed, but this unfortunately caused problems for
Gecko.

It [was discovered] that there was trouble unwinding through Rust functions due
to foreign exceptions such as illegal instructions or otherwise in-practice
methods used to abort a process. In testing it looked like the major difference
between a working binary and a non-working binary is indeed this `uwtable`
attribute, but this PR has unfortunately not been thoroughly tested in terms of
compiling Gecko with `-C panic=abort` *and* this PR to see whether it works, so
this is still somewhat working on just suspicion.

[was discovered]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078

Regression test for rust-lang/rust#40535

Correctly get source for metadata crate type;
replace `unwrap()` with `expect()`

Remove unused adt_def access by constructor in typeck/collect

Remove unused adt-def insertion by constructor DefIndex

add test for nested macro def (#31946)

Adds a test for issue #31946 which was fixed a while ago.

Nit: LLVM & Clang latest version is 4.0

rustbuild: Don't hardcode 'nightly' for Cargo

It now follows rustc release trains

Check for conflicts between macros 1.0 exports (`#[macro_export]`, `#[macro_reexport]`)
and macros 2.0 exports (`pub use` macro re-exports and `pub macro` (once implemented)
at the crate root.

Add whitespace around "=" in assoc items

Fix invalid linking in iter docs

str: Make docs consistently punctuated

Refactor parsing of trait object types

Auto merge of #40601 - stjepang:sort-unstable, r=alexcrichton

Implement feature sort_unstable

Tracking issue for the feature: #40585

This is essentially integration of [pdqsort](https://github.com/stjepang/pdqsort) into libcore.

There's plenty of unsafe blocks to review. The heart of pdqsort is `fn partition_in_blocks` and is probably the most challenging function to understand. It requires some patience, but let me know if you find it too difficult - comments could always be improved.

#### Changes

* Added `sort_unstable` feature.
* Tweaked insertion sort constants for stable sort. Sorting integers is now up to 5% slower, but sorting big elements is much faster (in particular, `sort_large_big_random` is 35% faster). The old constants were highly optimized for sorting integers, so overall the configuration is more balanced now. A minor regression in case of integers is forgivable as we recently had performance improvements (#39538) that completely make up for it.
* Removed some uninteresting sort benchmarks.
* Added a new sort benchmark for string sorting.

#### Benchmarks

The following table compares stable and unstable sorting:
```
name                                 stable ns/iter        unstable ns/iter     diff ns/iter   diff %
slice::sort_large_ascending          7,240 (11049 MB/s)    7,380 (10840 MB/s)            140    1.93%
slice::sort_large_big_random         1,454,138 (880 MB/s)  910,269 (1406 MB/s)      -543,869  -37.40%
slice::sort_large_descending         13,450 (5947 MB/s)    10,895 (7342 MB/s)         -2,555  -19.00%
slice::sort_large_mostly_ascending   204,041 (392 MB/s)    88,639 (902 MB/s)        -115,402  -56.56%
slice::sort_large_mostly_descending  217,109 (368 MB/s)    99,009 (808 MB/s)        -118,100  -54.40%
slice::sort_large_random             477,257 (167 MB/s)    346,028 (231 MB/s)       -131,229  -27.50%
slice::sort_large_random_expensive   21,670,537 (3 MB/s)   22,710,238 (3 MB/s)     1,039,701    4.80%
slice::sort_large_strings            6,284,499 (38 MB/s)   6,410,896 (37 MB/s)       126,397    2.01%
slice::sort_medium_random            3,515 (227 MB/s)      3,327 (240 MB/s)             -188   -5.35%
slice::sort_small_ascending          42 (1904 MB/s)        41 (1951 MB/s)                 -1   -2.38%
slice::sort_small_big_random         503 (2544 MB/s)       514 (2490 MB/s)                11    2.19%
slice::sort_small_descending         72 (1111 MB/s)        69 (1159 MB/s)                 -3   -4.17%
slice::sort_small_random             369 (216 MB/s)        367 (217 MB/s)                 -2   -0.54%
```

Interesting cases:
* Expensive comparison function and string sorting - it's a really close race, but timsort performs a slightly smaller number of comparisons. This is a natural difference of bottom-up merging versus top-down partitioning.
* `large_descending` - unstable sort is faster, but both sorts should have equivalent performance. Both just check whether the slice is descending and if so, they reverse it. I blame LLVM for the discrepancy.

r? @alexcrichton

Unit test heapsort

Remove stabilized features

Use partial insertion sort

Tweak the constants a bit

Fix grammar

Faster sort_unstable on presorted inputs

Fix a doctest

Address Alex's PR comments

Implement feature sort_unstable

dist-x86-linux: ugrade gcc to 4.8.5

link agains relocatable libstdc++

include compiler hash in wrapper scripts

Switch to rust-lang-ci mirror URLs

ci/netbsd: use the "official" cross compiler

Auto merge of #40693 - frewsxcv:rollup, r=frewsxcv

Rollup of 10 pull requests

- Successful merges: #40229, #40312, #40332, #40502, #40556, #40576, #40667, #40671, #40681, #40685
- Failed merges:

Auto merge of #40686 - alexcrichton:less-logging, r=brson

travis: Don't set `RUST_LOG` globally

I have a suspicion that this caused a large regression in cycle times by forcing
the compiler to perform more checks on every `debug!` statement, so let's test
this out by removing the `RUST_LOG` env var globally.

This regression in cycle time was witnessed between [two] [builds] where the
[PR] in question didn't do much suspicious. Judging by how the stage0 times
*also* regressed though then this is my best guess.

[two]: https://travis-ci.org/rust-lang/rust/builds/210149932
[builds]: https://travis-ci.org/rust-lang/rust/builds/210179995
[PR]: https://github.com/rust-lang/rust/pull/40446

Use Iterator::find in associated_item search

Rollup merge of #40685 - portal-chan:patch-1, r=eddyb

Add missing associated type Item to Iterator

Rollup merge of #40681 - est31:nightlies_txt_was_removed, r=alexcrichton

config.toml.example: nightlies.txt got removed

Instead, stage0.txt got introduced.

See also commit 02538d463a350f5c3658f7aabefca16eb599d31c

Rollup merge of #40671 - GuillaumeGomez:options-urls, r=frewsxcv

Add missing urls in Option enum

r? @rust-lang/docs

Rollup merge of #40667 - DaseinPhaos:patch-4, r=GuillaumeGomez

Fix typo in `ptr` doc

`sizeof` should be `size_of`