The example code for higher-ranked trait bounds on closures had an
unnecessary `mut` which was confusing, and the text referred to an
mutable reference which does not exist in the code (and isn't needed).
Removed the `mut`s and fixed the text to better describe the actual
error for the failing example.

The new Vec::extend covers the duties of .extend_from_slice() and some
previous specializations.

.wrapping_offset() exposes the arith_offset intrinsic in the core
module. This is the first step in making it possible to stabilize the
interface later.

`arith_offset` is a useful tool for developing iterators for two
reasons:

1. `arith_offset` is used by the slice's iterator, the most important
   iterator in libcore, and it is natural that Rust users need the same
   power available to implement similar iterators.
2. It is a good way to implement raw pointer iterations with step
   greater than one.

The name seems to fit the style of methods like "wrapping_add".

This now produces as good code (with optimizations) using the TrustedLen
codepath.

This commit is an implementation of [RFC 1665] which adds support for the
`#![windows_subsystem]` attribute. This attribute allows specifying either the
"windows" or "console" subsystems on Windows to the linker.

[RFC 1665]: https://github.com/rust-lang/rfcs/blob/master/text/1665-windows-subsystem.md

Previously all Rust executables were compiled as the "console" subsystem which
meant that if you wanted a graphical application it would erroneously pop up a
console whenever opened. When compiling an application, however, this is
undesired behavior and the "windows" subsystem is used instead to have control
over user interactions.

This attribute is validated, but ignored on all non-Windows platforms.

cc rust-lang#37499

This significantly reduces the number of bytes hashed by IchHasher.

This significantly reduces the number of bytes hashed by IchHasher.

The rustc-generated function `main` should respect the same config for
frame pointer elimination as the rest of code.

Environment variables on windows can't be empty.

On 64-bit platforms this reduces the size of `Expr` from 96 bytes to 88
bytes.

On 64-bit platforms this reduces the size of `Expr_` from  64 bytes to
56 bytes, and reduces the size of `Expr` from 88 bytes to 80 bytes.

Fix some mistakes in HRTB docs

The example code for higher-ranked trait bounds on closures had an unnecessary `mut` which was confusing, and the text referred to an mutable reference which does not exist in the code (and isn't needed).  Removed the `mut`s and fixed the text to better describe the actual error for the failing example.

Thanks to csd_ on IRC for pointing out these problems!

r? @steveklabnik

Add Iterator trait TrustedLen to enable better FromIterator / Extend

This trait attempts to improve FromIterator / Extend code by enabling it to trust the iterator to produce an exact number of elements, which means that reallocation needs to happen only once and is moved out of the loop.

`TrustedLen` differs from `ExactSizeIterator` in that it attempts to include _more_ iterators by allowing for the case that the iterator's len does not fit in `usize`. Consumers must check for this case (for example they could panic, since they can't allocate a collection of that size).

For example, chain can be TrustedLen and all numerical ranges can be TrustedLen. All they need to do is to report an exact size if it fits in `usize`, and `None` as the upper bound otherwise.

The trait describes its contract like this:

```
An iterator that reports an accurate length using size_hint.

The iterator reports a size hint where it is either exact
(lower bound is equal to upper bound), or the upper bound is `None`.
The upper bound must only be `None` if the actual iterator length is
larger than `usize::MAX`.

The iterator must produce exactly the number of elements it reported.

This trait must only be implemented when the contract is upheld.
Consumers of this trait must inspect `.size_hint()`’s upper bound.
```

Fixes rust-lang#37232

Add release notes for 1.12.1

It completely slipped my mind that this is something I'm supposed to do as part of the release process...

Add impls for `&Wrapping`. Also `Sum`, `Product` impls for both `Wrapping` and `&Wrapping`.

There are two changes here (split into two commits):
- Ops for references to `&Wrapping`  (`Add`, `Sub`, `Mul` etc.) similar to the way they are implemented for primitives.
- Impls for `iter::{Sum,Product}` for `Wrapping`.

As far as I know `impl` stability attributes don't really matter so I didn't bother breaking up the macro for two different kinds of stability. Happy to change if it does matter.

[3/n] rustc: unify and simplify managing associated items.

_This is part of a series ([prev](rust-lang#37401) | [next](rust-lang#37404)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._

<hr>

`ImplOrTraitItem`/`impl_or_trait_item` have been renamed to `AssociatedItem`/`associated_item`.

The common fields from (what used to be) `ty::ImplOrTraitItem`'s variants have been pulled out, leaving only an `AssociatedKind` C-like enum to distinguish between methods, constants and types.

The type information has been removed from `AssociatedItem`, and as such the latter can now be computed on-demand from the local HIR map, i.e. an extern-crate-enabled `TraitItem | ImplItem`.
It may be moved to HIR in the future, if we intend to start using HIR types cross-crate.

`ty::ExplicitSelfCategory` has been moved to `rustc_typeck` and is produced on-demand from the signature of the method, and a `method_has_self_argument` field on `AssociatedItem`, which is used to indicate that the first argument is a sugary "method receiver" and as such, method call syntax can be used.

Support GDB with native rust support

This PR aims at making the debuginfo tests pass with the newer GDB versions which have native rust support (RGDB)

To that end debuginfo tests now support three GDB prefixes:
- `gdb` applicable to both GDB varieties
- `gdbg` (**G**eneric) only applicable to the old GDB
- `gdbr` (**R**ust) only applicable to the new RGDB

Whether the GDB has rust support is detected based on it's version: GDB >= 7.11.10 is considered to have rust support.

---

**Test updates**

All tests have been updated to the new GDB version. Note that some tests currently require the GDB trunk<sup>1</sup>.

---

**How to move forward with this PR:**

I propose the following steps for moving forward with this PR:
- [x] Validate the general approach of this PR (the `gdb-`, `gdbg-` and `gdbr-` split)
- [x] Validate the approach taken for updating the debuginfo tests (I've checked this since there's (almost) no `set language c` left, which was my main concern)
- [x] Determine how to distinguish between the new and old GDB (and implement that)
- [ ] Add one or more non-gating build bots with the new GDB (blocked on the previous item, can happen after this PR has been merged)
- [ ] If the new bots pass the tests, gate on them
- [x] \(Maybe) update the remaining tests to run without `set syntax c` (in a separate PR)
- [ ] \(Maybe) add tests specifically for the new GDB (in a separate PR / open an issue about this)

I'm not completely sure about the build bot related steps (cc @alexcrichton), the current approach was suggested to prevent any downtime / broken build time between a new GDB gating builder being added and this PR being merged.

---

**Suboptimal RGDB Output**

I've found several places where the output of RGDB is not ideal. They are tagged with `// FIXME`, here is an overview:
- [x] Trait references are not syntactically correct: `type_names::&Trait2<...>` (**WontFix**: the issue is minor and from @Manishearth below: "to properly address the trait issue we should wait for trait object support")
- [x] Univariant enums are printed as `<error reading variable>` (**Fixed** in GDB trunk<sup>1<sup>)
- [x] Unions are printed as `<error reading variable>` (**Fixed** in GDB trunk<sup>1</sup>)
- [x] "Nil Enums" (`enum Foo {}`) are printed as `<error reading variable>` (**WontFix**: the are not supposed to exist)
- [x] I have found no alternative for `sizeof(var)` in rust mode, so had to resort to `set language c` (**Fixed** in GDB trunk<sup>1</sup>)
- [x] I have found not way of interpreting a value as a specific enum variant, so had to resort to `set language c` (**Fixed** in GDB trunk<sup>1</sup>)
- [x] Before the initial `run` command, gdb does not realise it should be in rust mode (thus, if one want's to print statics before the run one has to explicitly `set language rust`) (maybe this is intended / expected behaviour, if so, someone please tell me ;) (**"Expected"** / current behaviour of GDB: picks up jemalloc, see rust-lang#37410 (comment))

<sup>1</sup>: Or rather in @Manishearth's trunk, waiting to be merged upstream.

---

cc @alexcrichton, @michaelwoerister, rust-lang#36323

Add .wrapping_offset() methods

.wrapping_offset() exposes the arith_offset intrinsic in the core
module (as methods on raw pointers, next to offset). This is the
first step in making it possible to stabilize the interface later.

`arith_offset` is a useful tool for developing iterators for two
reasons:
1. `arith_offset` is used by the slice's iterator, the most important
   iterator in libcore, and it is natural that Rust users need the same
   power available to implement similar iterators.
2. It is a good way to implement raw pointer iterations with step
   greater than one.

The name seems to fit the style of methods like "wrapping_add".

…lwoerister

Reduce the number of bytes hashed by IchHasher.

IchHasher uses blake2b hashing, which is expensive, so the fewer bytes hashed
the better. There are two big ways to reduce the number of bytes hashed.
- Filenames in spans account for ~66% of all bytes (for builds with debuginfo).
  The vast majority of spans have the same filename for the start of the span
  and the end of the span, so hashing the filename just once in those cases is
  a big win.
- u32 and u64 and usize values account for ~25%--33% of all bytes (for builds
  with debuginfo). The vast majority of these are small, i.e. fit in a u8, so
  shrinking them down before hashing is also a big win.

This PR implements these two optimizations. I'm certain the first one is safe.
I'm about 90% sure that the second one is safe.

Here are measurements of the number of bytes hashed when doing
debuginfo-enabled builds of stdlib and
rustc-benchmarks/syntex-0.42.2-incr-clean.

```
                    stdlib   syntex-incr
                    ------   -----------
original       156,781,386   255,095,596
half-SawSpan   106,744,403   176,345,419
short-ints      45,890,534   118,014,227
no-SawSpan[*]    6,831,874    45,875,714

[*] don't hash the SawSpan at all. Not part of this PR, just implemented for
    comparison's sake.
```

For debug builds of syntex-0.42.2-incr-clean, the two changes give a 1--2%
speed-up.

Don't reuse RandomState seeds

cc rust-lang#36481

…rson

rustc: Add knowledge of Windows subsystems.

This commit is an implementation of [RFC 1665] which adds support for the
`#![windows_subsystem]` attribute. This attribute allows specifying either the
"windows" or "console" subsystems on Windows to the linker.

[RFC 1665]: https://github.com/rust-lang/rfcs/blob/master/text/1665-windows-subsystem.md

Previously all Rust executables were compiled as the "console" subsystem which
meant that if you wanted a graphical application it would erroneously pop up a
console whenever opened. When compiling an application, however, this is
undesired behavior and the "windows" subsystem is used instead to have control
over user interactions.

This attribute is validated, but ignored on all non-Windows platforms.

cc rust-lang#37499

…eveklabnik

Add missing urls for ErrorKind's variants

r? @steveklabnik

set frame pointer elimination attribute for main

The rustc-generated function `main` should respect the same config for
frame pointer elimination as the rest of code.

Use DefId's in const eval for cross-crate const fn's

Fixes rust-lang#36954.

r? @eddyb

cc @raphaelcohn

Fix ICE when querying DefId on Def::Err.

Also moves computations into check that `kind_id` is `Ok(_)`, which is in theory an optimization, though I expect it's minor.

Fixes rust-lang#37534.

r? @eddyb.

…hton

Peekable::peek(): Use Option::as_ref()

Replace the match expression in .peek() with Option::as_ref() since it's the same functionality.

Set RUSTC_BOOTSTRAP to some value.

Environment variables on windows can't be empty.

…=eddyb

Shrink `hir::Expr` slightly

r? @eddyb