Implement some trivial size_hints for various iterators

This also implements ExactSizeIterator where applicable.

Addresses most of the Iterator traits mentioned in #23708.

I intend to do more, but I don't want to make the PR too large.

optimize NLL constraint propagation a little

Removes a bone-headed hot spot in NLL constant propagation; we were re-allocating the stack vector and hashmap as we repeated the DFS. This change shares those resources across each call.

It also modifies the constraint list to be a linked list; arguably I should revert that, though, as this didn't turn out to be a perf hit and perhaps the old code was clearer? (Still, the new style appeals to me.)

r? @pnkfelix

Add primitive intra-links

Part of #43466.

r? @QuietMisdreavus

Deprecate signed std::num::NonZeroI* with a call for use cases

CC https://github.com/rust-lang/rust/issues/49137#issuecomment-375823481

Revert "Add TryFrom and TryInto to the prelude"

This reverts commit 09008cc2.

This addition landed in https://github.com/rust-lang/rust/pull/49305 and turned out to break crates that had their own copy of `TryFrom` in order to use it on the Stable channel :(

We’ll explore the possibility of the 2018 edition having a different prelude that includes this traits. However per the editions RFC this requires implementing a warning in the 2015 edition for code that *would* break.

rustc: Forbid #[inline(always)] with #[target_feature]

Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!

Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!

This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.

Closes rust-lang-nursery/stdsimd#404

This reverts commit 09008cc2.

Trim discriminants to their final type size

r? @EddyB

fixes  #49181

Fix stable hashing of AllocIds

r? @michaelwoerister

fixes #49081

Stabilize fs::read and fs::write

As discussed in https://github.com/rust-lang/rust/issues/46588#issuecomment-373956283

Rollup of 10 pull requests

- Successful merges: #49443, #49445, #49446, #49463, #49464, #49466, #49468, #49473, #49484, #49486
- Failed merges:

Hide type declarations by default

I'm not very happy for the moment about the rendering but the bases are here:

<img width="610" alt="screen shot 2018-03-27 at 11 56 27" src="https://user-images.githubusercontent.com/3050060/37960492-0e045954-31b6-11e8-9cea-1ef8a3f980c4.png">

r? @QuietMisdreavus

correct a typo in RELEASES.md

Ignore stack-probes tests on powerpc/s390x too

We only support stack probes on x86 and x86_64.
Other arches are already ignored.

src/libcore/ptr.rs: Fix documentation for size of `Option<NonNull<T>>`

Seems more useful to say that it has the same size as `*mut T`.

Remove unnecessary use core::hash in liballoc/boxed.rs

It' only used for hash::Hasher, but Hasher is also imported.

Use f{32,64}::to_bits for is_zero test in vec::SpecFromElem

vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.

For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:

```
  xorps xmm1, xmm1
  ucomisd xmm0, xmm1
  setnp al
  sete cl
  and cl, al
  movq rax, xmm0
  test rax, rax
  setns al
  and al, cl
  ret
```

A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:

```
  movq rax, xmm0
  test rax, rax
  sete al
  ret
```

Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.

rustbuild: Don't leak file handles when creating junctions on Windows

This fixes building the compiler docs because stage1-rustc\x86_64-pc-windows-msvc\doc is used twice which doesn't work if we still have a handle from the first time.

Don't mention unstable constructors in release notes

Explicitly mention `Option` in `?` error message.

Save users the time/effort of having to lookup what types implement
the `Try` trait.

Rename main theme into light theme

r? @QuietMisdreavus

Fix tooltip position

r? @QuietMisdreavus

rustc: Group linked libraries where needed

This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.

This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!

To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)

Closes #18807
Closes #47074

This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.

This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!

To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)

Closes #18807
Closes #47074

We only support stack probes on x86 and x86_64.
Other arches are already ignored.

Rename RangeArgument to RangeBounds, move it and Bound to libcore

As proposed in the tracking issue: https://github.com/rust-lang/rust/issues/30877

Changes to *stable* items:

* `core::ops::Bound` / `std::ops::Bound` is new
* `std::collections::Bound` is a deprecated reexport of it (does this actually cause a warning?)

Changes to *unstable* items

* `alloc::Bound` is gone
* `alloc::range::RangeArgument` is moved to `core::ops::RangeBounds` / `std::ops::RangeBounds`
* `alloc::range` is gone
* `std::collections::range::RangeArgument` is deprecated reexport, to be removed later
* `std::collections::range` is deprecated, to be removed later
* `impl RangeBounds<T> for Range{,From,To,Inclusive,ToInclusive}<&T>` are added

The idea of replacing this trait with a type to be used with `Into<_>` is left for future consideration / work.

(Fixes https://github.com/rust-lang-nursery/rust-clippy/issues/2552.)

These unstable items are deprecated:

* The `std::collections::range::RangeArgument` reexport
* The `std::collections::range` module.