rustc: Remove f{32,64} % from the language

This commit removes the compiler support for floating point modulus operations,
as well as from the language. An implementation for this operator is now
required to be provided by libraries.

Floating point modulus is rarely used, doesn't exist in C, and is always lowered
to an fmod library call by LLVM, and LLVM is considering removing support
entirely.

Closes #12278
rust-mode cleanup.

* Use `setq-local' instead of (set (make-local-variable ...) value).
  Provides a version for older Emacsen.
* Remove use of `cl.el'.
* Use \' in file regexp instead of line end match $.
* Use type for defcustom and add parent group.
Collect move errors before reporting

This commit changes the way move errors are reported when some value is
captured by a PatIdent. First, we collect all of the "cannot move out
of" errors before reporting them, and those errors with the same "move
source" are reported together. If the move is caused by a PatIdent (that
binds by value), we add a note indicating where it is and suggest the
user to put `ref` if they don't want the value to move. This makes the
"cannot move out of" error in match expression nicer (though the extra
note may not feel that helpful in other places :P). For example, with
the following code snippet,

```rust
enum Foo {
    Foo1(~u32, ~u32),
    Foo2(~u32),
    Foo3,
}

fn main() {
    let f = &Foo1(~1u32, ~2u32);
    match *f {
        Foo1(num1, num2) => (),
        Foo2(num) => (),
        Foo3 => ()
    }
}
```

Errors before the change:

```rust
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10         Foo1(num1, num2) => (),
                   ^~~~~~~~~~~~~~~~
test.rs:10:9: 10:25 error: cannot move out of dereference of `&`-pointer
test.rs:10         Foo1(num1, num2) => (),
                   ^~~~~~~~~~~~~~~~
test.rs:11:9: 11:18 error: cannot move out of dereference of `&`-pointer
test.rs:11         Foo2(num) => (),
                   ^~~~~~~~~
```

After:

```rust
test.rs:9:11: 9:13 error: cannot move out of dereference of `&`-pointer
test.rs:9     match *f {
                    ^~
test.rs:10:14: 10:18 note: attempting to move value to here (to prevent the move, you can use `ref num1` to capture value by reference)
test.rs:10         Foo1(num1, num2) => (),
                        ^~~~
test.rs:10:20: 10:24 note: and here (use `ref num2`)
test.rs:10         Foo1(num1, num2) => (),
                              ^~~~
test.rs:11:14: 11:17 note: and here (use `ref num`)
test.rs:11         Foo2(num) => (),
                        ^~~
```

Close #8064
Tweaked the design to be a lot cleaner.

Signed-off-by: Daniel Fagnan <dnfagnan@gmail.com>
fixed issues

Signed-off-by: Daniel Fagnan <dnfagnan@gmail.com>
doc: design changes cleanups

Conflicts:
	src/librustdoc/html/layout.rs
rustdoc: add webfonts and tweak the styles accordingly
std: Update documentation on the `comm` module

Some of this documentation got a little out of date. There was no mention of a
`SyncSender`, and the entire "Outside the runtime" section isn't really true any
more (or really all that relevant).

This also updates a few other doc blocks and adds some examples.
libc: Deglob reexports. #11870
optimized SipHash implementation

work started from @gereeter's PR: https://github.com/mozilla/rust/pull/13114
but adjusted bits
Improve the copying code for slices and Vec
Remove usage of private enum variants

This replaces all uses of private enum variants with a struct that has
one private field pointing at a private enum.

RFC: 0006-remove-priv
Make Vec::clone and slice::to_owned failure-safe
pprust: Handle multi-stmt/no-expr `ExprFnBlock`

Fixes #12685
syntax: unify all MacResult's into a single trait.

There's now one unified way to return things from a macro, instead of
being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr`
variants of the `MacResult` enum. This does simplify the logic handling
the expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.

By my measurements (using `-Z time-passes` on libstd and librustc etc.),
this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all `macro_rules!`-defined macros have
not changed in behaviour, since they had to use the `AnyMacro` trait
anyway).
auto merge of #13522 : seanmonstar/rust/sip, r=alexcrichton

work started from @gereeter's PR: https://github.com/mozilla/rust/pull/13114
but adjusted bits

```
before
test hash::sip::tests::bench_u64                            ... bench:        34 ns/iter (+/- 0)
test hash::sip::tests::bench_str_under_8_bytes              ... bench:        37 ns/iter (+/- 1)
test hash::sip::tests::bench_str_of_8_bytes                 ... bench:        43 ns/iter (+/- 1)
test hash::sip::tests::bench_str_over_8_bytes               ... bench:        50 ns/iter (+/- 1)
test hash::sip::tests::bench_long_str                       ... bench:       613 ns/iter (+/- 14)
test hash::sip::tests::bench_compound_1                     ... bench:       114 ns/iter (+/- 11)

after
test hash::sip::tests::bench_u64                            ... bench:        25 ns/iter (+/- 0)
test hash::sip::tests::bench_str_under_8_bytes              ... bench:        31 ns/iter (+/- 0)
test hash::sip::tests::bench_str_of_8_bytes                 ... bench:        36 ns/iter (+/- 0)
test hash::sip::tests::bench_str_over_8_bytes               ... bench:        40 ns/iter (+/- 0)
test hash::sip::tests::bench_long_str                       ... bench:       600 ns/iter (+/- 14)
test hash::sip::tests::bench_compound_1                     ... bench:        64 ns/iter (+/- 6)
```

Notably it seems smaller keys will hash faster. A long string doesn't see much gains, but compound cuts in half (once compound used a `int` and `u64`).
auto merge of #13527 : huonw/rust/macro-expander-trait, r=sfackler

There's now one unified way to return things from a macro, instead of
being able to choose the `AnyMacro` trait or the `MRItem`/`MRExpr`
variants of the `MacResult` enum. This does simplify the logic handling
the expansions, but the biggest value of this is it makes macros in (for
example) type position easier to implement, as there's this single thing
to modify.

By my measurements (using `-Z time-passes` on libstd and librustc etc.),
this appears to have little-to-no impact on expansion speed. There are
presumably larger costs than the small number of extra allocations and
virtual calls this adds (notably, all `macro_rules!`-defined macros have
not changed in behaviour, since they had to use the `AnyMacro` trait
anyway).

---

Summary of changes for dynamic syntax extension maintainers:

- `MacResult` is now a trait, and is returned as `~MacResult`
- `MRExpr` & `MRItem` are now `MacExpr::new` and `MacItem:new` respectively (which return `~MacResult`s)
- `MacResult::dummy_...` is `DummyResult::any` or `DummyResult::expr`
debuginfo: Add a test case for issue #12886.
auto merge of #13539 : Aatch/rust/vector-copy-faster, r=thestinger

LLVM wasn't recognising the loops as memcpy loops and was therefore failing to optimise them properly. While improving LLVM is the "proper" way to fix this, I think that these cases are important enough to warrant a little low-level optimisation.

Fixes #13472 

r? @thestinger 

---

Benchmark Results:

```
--- Before ---
test clone_owned          ... bench:   6126104 ns/iter (+/- 285962) = 170 MB/s
test clone_owned_to_owned ... bench:   6125054 ns/iter (+/- 271197) = 170 MB/s
test clone_str            ... bench:     80586 ns/iter (+/- 11489) = 13011 MB/s
test clone_vec            ... bench:   3903220 ns/iter (+/- 658556) = 268 MB/s
test test_memcpy          ... bench:     69401 ns/iter (+/- 2168) = 15108 MB/s

--- After ---
test clone_owned          ... bench:     70839 ns/iter (+/- 4931) = 14801 MB/s
test clone_owned_to_owned ... bench:     70286 ns/iter (+/- 4836) = 14918 MB/s
test clone_str            ... bench:     78519 ns/iter (+/- 5511) = 13353 MB/s
test clone_vec            ... bench:     71415 ns/iter (+/- 1999) = 14682 MB/s
test test_memcpy          ... bench:     70980 ns/iter (+/- 2126) = 14772 MB/s
```
auto merge of #13544 : klutzy/rust/pprust, r=alexcrichton

Fixes #12685