Documentation of what Default does for each type

Addresses #36265
I haven't changed the following types due to doubts:

1)src/libstd/ffi/c_str.rs
2)src/libcore/iter/sources.rs
3)src/libcore/hash/mod.rs
4)src/libcore/hash/mod.rs
5)src/librustc/middle/privacy.rs

r? @steveklabnik

book: fix mistake (File::open -> File::create)

Add urls

r? @steveklabnik

Set run button transparent instead of invisible

r? @steveklabnik

And of course a screenshot:

![screenshot from 2016-09-08 01-15-45](https://cloud.githubusercontent.com/assets/3050060/18331849/31fe1f8c-7562-11e6-9ae9-1dab44089ec6.png)

Replace try! with ?.

crate-ify compiler-rt into compiler-builtins

libcompiler-rt.a is dead, long live libcompiler-builtins.rlib

This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.

Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics - this is a [breaking-change]. Users
of the `std` have to do nothing extra as the std crate depends
on compiler-builtins.

Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.

closes #34400

---

r? @alexcrichton

This commit fixes a test which now needs to explicitly link to the
`compiler_builtins` crate as well as makes the `compiler_builtins` crate
unstable.

core: add likely and unlikely intrinsics

I'm no good at reading assembly, but I have tried a stage1 compiler with this patch, and it does cause different asm output. Additionally, testing this compiler on my httparse crate with some `likely` usage added in to the branches does affect benchmarks. However, I'm sure a codegen test should be included, if anyone knows what it should look like.

There isn't an entry in `librustc_trans/context.rs` in this diff, because it already exists (`llvm.expect.i1` is used for array indices).

----

Even though this does affect httparse benchmarks, it doesn't seem to affect it the same way GCC's `__builtin_expect` affects picohttpparser. I was confused that the deviation on the benchmarks grew hugely when testing this, especially since I'm absolutely certain that the branchs where I added `likely` were always `true`. I chalk that up to GCC and LLVM handle branch prediction differently.

cc #26179

This flag is intended for rlibs included once, not rlibs that are repeatedly
included.

Zero first byte of CString on drop

Hi! This is one more attempt to ameliorate `CString::new("...").unwrap().as_ptr()` problem (related RFC: https://github.com/rust-lang/rfcs/pull/1642).

One of the biggest problems with this code is that it may actually work in practice, so the idea of this PR is to proactively break such invalid code.

Looks like writing a `null` byte at the start of the CString should do the trick, and I think is an affordable cost: zeroing a single byte in `Drop` should be cheap enough compared to actual memory deallocation which would follow.

I would actually prefer to do something like

```Rust
impl Drop for CString {
    fn drop(&mut self) {
        let pattern = b"CTHULHU FHTAGN ";
        let bytes = self.inner[..self.inner.len() - 1];
        for (d, s) in bytes.iter_mut().zip(pattern.iter().cycle()) {
            *d = *s;
        }
    }
}
```

because Cthulhu error should be much easier to google, but unfortunately this would be too expensive in release builds, and we can't implement things `cfg(debug_assertions)` conditionally in stdlib.

Not sure if the whole idea or my implementation (I've used ~~`transmute`~~ `mem::unitialized` to workaround move out of Drop thing) makes sense :)

Rollup of 5 pull requests

- Successful merges: #36357, #36380, #36389, #36397, #36402
- Failed merges:

Tweak array docs

Fixes #29331.

r? @GuillaumeGomez

Remove unnecessary `cmp::min` from BufWriter::write

The first branch of the if statement already checks if `buf.len() >= self.buf.capacity()`, which makes the `cmp::min(buf.len(), self.buf.capacity())` redundant: the result will always be `buf.len()`. Therefore, we can pass the `buf` slice directly into `Write::write`.

Update E0297 to new error format

Fixes #35521.
Part of #35233.

I didn't attempt the bonus of narrowing the span to focus on the "for `<pattern>`" piece (it's my first time contributing), but I'm happy to do so given some hints.

r? @jonathandturner

book: fix a typo

Tweak std::mem docs (#29362)

r? @steveklabnik

All crates depend on compiler-builtins, so we need to always include the crate
last.

libcompiler-rt.a is dead, long live libcompiler-builtins.rlib

This commit moves the logic that used to build libcompiler-rt.a into a
compiler-builtins crate on top of the core crate and below the std crate.
This new crate still compiles the compiler-rt instrinsics using gcc-rs
but produces an .rlib instead of a static library.

Also, with this commit rustc no longer passes -lcompiler-rt to the
linker. This effectively makes the "no-compiler-rt" field of target
specifications a no-op. Users of `no_std` will have to explicitly add
the compiler-builtins crate to their crate dependency graph *if* they
need the compiler-rt intrinsics. Users of the `std` have to do nothing
extra as the std crate depends on compiler-builtins.

Finally, this a step towards lazy compilation of std with Cargo as the
compiler-rt intrinsics can now be built by Cargo instead of having to
be supplied by the user by some other method.

closes #34400

Introduce `into_inner` method on `std::io::Take`.

https://github.com/rust-lang/rust/issues/23755

fix a few errant `Krate` edges

Exploring the effect of small changes on `syntex` reuse, I discovered the following sources of unnecessary edges from `Krate`

r? @michaelwoerister

fix span for errors E0537, E0535 & E0536

fix #36182 as part of #35233

README.md: fix a "\" in table heading to be "/"

Improve char_lit's readability and speed

This is my first contribution to rustc. Please let me know if I've done anything wrong. (I ran `make tidy` before making the pull request.)

use `adt::trans_const` when translating constant closures and tuples

The previous way dropped padding on the floor.

Fixes #36401

r? @EddyB

Allow setting --docdir

This will allow setting `--docdir` during configure, this is useful because not all linux distributions install documentation to `/usr/share/doc`.  For example in Slackware documentation is installed to `/usr/doc/$PRGNAM-$VERSION` and `/usr/share/doc` is a symlink to `/usr/doc`.

To use this `./configure --docdir=/usr/doc/$PRGNAM-$VERSION` can be used.

This reduces the time taken to run
`rustc -Zparse-only rustc-benchmarks/issue-32278-big-array-of-strings`
from 0.18s to 0.15s on my machine, and reduces the number of
instructions (as measured by Cachegrind) from 1.34B to 1.01B.

With the change applied, the time to fully compile that benchmark is
1.96s, so this is a 1.5% improvement.

This makes the function more concise and easier to understand.

Work around pointer aliasing issue in Vec::extend_from_slice, extend_with_element

Due to missing noalias annotations for &mut T in general (issue #31681),
in larger programs extend_from_slice and extend_with_element may both
compile very poorly. What is observed is that the .set_len() calls are
not lifted out of the loop, even for `Vec<u8>`.

Use a local length variable for the Vec length instead, and use a scope
guard to write this value back to self.len when the scope ends or on
panic. Then the alias analysis is easy.

This affects extend_from_slice, extend_with_element, the vec![x; n]
macro, Write impls for Vec<u8>, BufWriter, etc (but may / may not
have triggered since inlining can be enough for the compiler to get it right).

Fixes #32155
Fixes #33518
Closes #17844

Use LLVM_COMPONENTS to run tests just for supported targets

This is already done for simd-ffi test, but not for atomic-lock-free test.

Fix #35023.