rollup merge of #19820: alexcrichton/deprecate-some-more-libs

This commit deprecates a few more in-tree libs for their crates.io counterparts.
Note that this commit does not make use of the #[deprecated] tag to prevent
warnings from being generated for in-tree usage. Once #[unstable] warnings are
turned on then all external users will be warned to move.

These crates have all been duplicated in rust-lang/$crate repositories so
development can happen independently of the in-tree copies. We can explore at a
later date replacing the in-tree copies with the external copies, but at this
time the libraries have changed very little over the past few months so it's
unlikely for changes to be sent to both repos.

cc #19260

rollup merge of #19818: emk/regex_at_name_opt

Hello! This is my first Rust patch, and I fear that I've probably skipped at least 7 critical steps. I'd appreciate your feedback and advice about how to contribute to Rust.

This patch is based on a discussion with @BurntSushi in #14602 a while back. I'm happy to revise it as needed to fit into the modern world. :-)

As discussed in that issue, the existing `at` and `name` functions represent two different results with the empty string:

1. Matched the empty string.
2. Did not match anything.

Consider the following example.  This regex has two named matched groups, `key` and `value`. `value` is optional:

```rust
// Matches "foo", "foo;v=bar" and "foo;v=".
regex!(r"(?P<key>[a-z]+)(;v=(?P<value>[a-z]*))?");
```

We can access `value` using `caps.name("value")`, but there's no way for us to distinguish between the `"foo"` and `"foo;v="` cases.

Early this year, @BurntSushi recommended modifying the existing `at` and `name` functions to return `Option`, instead of adding new functions to the API.

This is a [breaking-change], but the fix is easy:

- `refs.at(1)` becomes `refs.at(1).unwrap_or("")`.
- `refs.name(name)` becomes `refs.name(name).unwrap_or("")`.

rollup merge of #19770: csouth3/iterator-wrapperstructs

Using a type alias for iterator implementations is fragile since this exposes the implementation to users of the iterator, and any changes could break existing code.

This PR changes the iterators of `BTreeMap`, `BTreeSet`, `HashMap`, and `HashSet` to use proper new types, rather than type aliases.  However, since it is fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

rollup merge of #19766: nick29581/coerce-raw

r?

rollup merge of #19764: lifthrasiir/that-stray-nul

Fixes #19719.

rollup merge of #19755: alexcrichton/rust-serialize

The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.

The current libserialize library, however, has a number of drawbacks:

* The API is not ready to be stabilize as-is and we will likely not have enough
  resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
  being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
  maintaining backwards compatibility.

One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.

For these reasons, this commit starts off a stability story for libserialize by
following these steps:

1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
   renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
   rustc-serialize crate shipped on crates.io. The contents of the crate will be
   the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
   deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
   expansions for each deriving mode will change from `::serialize::foo` to
   `::rustc_serialize::foo`.

This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.

The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:

* If plugins have a stable API, then any crate can provide a custom `deriving`
  mode (will require some compiler work). This means that any new serialization
  crate can provide its own `deriving` with its own backing
  implementation, entirely obsoleting the current libserialize and fully
  replacing it.

* Erick is exploring the possibility of code generation via preprocessing Rust
  source files in the near term until plugins are stable. This strategy would
  provide the same ergonomic benefit that `deriving` does today in theory.

So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.

Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.

rollup merge of #19753: brson/rust-installer

This is just a refactoring of the current installer so that Rust and Cargo
use the same codebase.

cc #16456

rollup merge of #19743: steveklabnik/gh16143

This will hopefully help people with their first steps in Rust.

Fixes #16143.

/cc @jvns

rollup merge of #19729: vhbit/ios-oibit-fix

rollup merge of #19720: csouth3/vecmap-newtypes

Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the iterators of `VecMap` to use
proper new types, rather than type aliases.  However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

auto merge of #19800 : sfackler/rust/core-hash, r=alexcrichton

r? @alexcrichton

auto merge of #19799 : alexcrichton/rust/stop-panicking, r=huonw

Fix a panic where the compiler was looking at stale or old metadata.

See #19798, #19772, #19757, #19744, #19718, #19691.

auto merge of #19789 : nick29581/rust/assoc-ufcs2, r=nikomatsakis

Closes #18433

auto merge of #19761 : nick29581/rust/coerce-double, r=nikomatsakis

Part of #18469

[breaking-change]

A receiver will only ever get a single auto-reference. Previously arrays and strings would get two, e.g., [T] would be auto-ref'ed to &&[T]. This is usually apparent when a trait is implemented for `&[T]` and has a method takes self by reference. The usual solution is to implement the trait for `[T]` (the DST form).

r? @nikomatsakis (or anyone else, really)

auto merge of #19921 : FlaPer87/rust/snapshot, r=nikomatsakis

r? @nikomatsakis

Fixed iOS build after oibit

auto merge of #19647 : nielsegberts/rust/master, r=pnkfelix

The names expected and actual are not used anymore in the output. It also
removes the confusion that the argument order is the opposite of junit.

Bug #7330 is relevant.

Create a snapshot on top of 1b97cd3

auto merge of #19782 : gereeter/rust/cleanup-btree-node, r=Gankro

Before:
```
test btree::map::bench::find_rand_100                      ... bench:        12 ns/iter (+/- 0)
test btree::map::bench::find_rand_10_000                   ... bench:        13 ns/iter (+/- 1)
test btree::map::bench::find_seq_100                       ... bench:        11 ns/iter (+/- 0)
test btree::map::bench::find_seq_10_000                    ... bench:        11 ns/iter (+/- 1)
test btree::map::bench::insert_rand_100                    ... bench:       106 ns/iter (+/- 1)
test btree::map::bench::insert_rand_10_000                 ... bench:       326 ns/iter (+/- 8)
test btree::map::bench::insert_seq_100                     ... bench:       198 ns/iter (+/- 1)
test btree::map::bench::insert_seq_10_000                  ... bench:       312 ns/iter (+/- 3)
test btree::map::bench::iter_1000                          ... bench:     16563 ns/iter (+/- 173)
test btree::map::bench::iter_100000                        ... bench:   1686508 ns/iter (+/- 108592)
test btree::map::bench::iter_20                            ... bench:       365 ns/iter (+/- 25)
```

After:
```
test btree::map::bench::find_rand_100                      ... bench:        12 ns/iter (+/- 0)
test btree::map::bench::find_rand_10_000                   ... bench:        12 ns/iter (+/- 0)
test btree::map::bench::find_seq_100                       ... bench:        11 ns/iter (+/- 0)
test btree::map::bench::find_seq_10_000                    ... bench:        11 ns/iter (+/- 0)
test btree::map::bench::insert_rand_100                    ... bench:        89 ns/iter (+/- 1)
test btree::map::bench::insert_rand_10_000                 ... bench:       121 ns/iter (+/- 3)
test btree::map::bench::insert_seq_100                     ... bench:       149 ns/iter (+/- 0)
test btree::map::bench::insert_seq_10_000                  ... bench:       228 ns/iter (+/- 1)
test btree::map::bench::iter_1000                          ... bench:     16965 ns/iter (+/- 220)
test btree::map::bench::iter_100000                        ... bench:   1687836 ns/iter (+/- 18746)
test btree::map::bench::iter_20                            ... bench:       366 ns/iter (+/- 21)
```

auto merge of #19777 : nikomatsakis/rust/warn-on-shadowing, r=acrichto

per rfc 459
cc https://github.com/rust-lang/rust/issues/19390

One question is: should we start by warning, and only switch to hard error later? I think we discussed something like this in the meeting.

r? @alexcrichton

Move hash module from collections to core

auto merge of #19478 : nick29581/rust/assoc-ice-test, r=nikomatsakis

closes #19121

r?

This won't actually pass until https://github.com/rust-lang/rust/pull/19391 lands

Test for associated types ICE

closes #19121

Remove the double auto-ref on arrays/strings as receivers

Part of #18469

[breaking-change]

A receiver will only ever get a single auto-reference. Previously arrays and strings would get two, e.g., [T] would be auto-ref'ed to &&[T]. This is usually apparent when a trait is implemented for `&[T]` and has a method takes self by reference. The usual solution is to implement the trait for `[T]` (the DST form).

auto merge of #19747 : alexcrichton/rust/slice-one-trait, r=brson

This commit collapses the various prelude traits for slices into just one trait:

* SlicePrelude/SliceAllocPrelude => SliceExt
* CloneSlicePrelude/CloneSliceAllocPrelude => CloneSliceExt
* OrdSlicePrelude/OrdSliceAllocPrelude => OrdSliceExt
* PartialEqSlicePrelude => PartialEqSliceExt

Use wrapper structs for `HashSet`'s iterators.

Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the iterators of `HashSet` to use
proper new types, rather than type aliases.  However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

Use wrapper structs for `HashMap`'s iterators.

Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the keys and values iterators of `HashMap` to use
proper new types, rather than type aliases.  However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

Use wrapper structs for `BTreeSet`'s iterators.

Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the iterators of `BTreeSet` to use
proper new types, rather than type aliases.  However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

Use wrapper structs for `BTreeMap`'s iterators.

Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the keys and values iterators of `BTreeMap` to use
proper new types, rather than type aliases.  However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

Review changes

Path types to associated types with form `T::A`

Closes #18433

auto merge of #19448 : japaric/rust/binops-by-value, r=nikomatsakis

- The following operator traits now take their arguments by value: `Add`, `Sub`, `Mul`, `Div`, `Rem`, `BitAnd`, `BitOr`, `BitXor`, `Shl`, `Shr`. This breaks all existing implementations of these traits.

- The binary operation `a OP b` now "desugars" to `OpTrait::op_method(a, b)` and consumes both arguments.

- `String` and `Vec` addition have been changed to reuse the LHS owned value, and to avoid internal cloning. Only the following asymmetric operations are available: `String + &str` and `Vec<T> + &[T]`, which are now a short-hand for the "append" operation.

[breaking-change]

---

This passes `make check` locally. I haven't touch the unary operators in this PR, but converting them to by value should be very similar to this PR. I can work on them after this gets the thumbs up.

@nikomatsakis r? the compiler changes
@aturon r? the library changes. I think the only controversial bit is the semantic change of the `Vec`/`String` `Add` implementation.
cc #19148

auto merge of #19882 : steveklabnik/rust/fix_download, r=nikomatsakis

Thank you, @Ap0ph1s.

auto merge of #19785 : brson/rust/rollup, r=brson

Remove all shadowed lifetimes.

Emit warning when lifetime names are shadowed.

This is not technically a [breaking-change], but it will be soon, so
you should update your code. Typically, shadowing is accidental, and
the shadowing lifetime can simply be removed. This frequently occurs
in constructor patterns:

```rust
// Old:
impl<'a> SomeStruct<'a> { fn new<'a>(..) -> SomeStruct<'a> { ... } }

// Should be:
impl<'a> SomeStruct<'a> { fn new(..) -> SomeStruct<'a> { ... } }
```

Otherwise, you should rename the inner lifetime to something
else. Note though that lifetime elision frequently applies:

```rust
// Old
impl<'a> SomeStruct<'a> {
    fn get<'a>(x: &'a self) -> &'a T { &self.field }
}

// Should be:
impl<'a> SomeStruct<'a> {
    fn get(x: &self) -> &T { &self.field }
}
``

Fix windows download links

Thank you, @Ap0ph1s.

rollup merge of #19814: jbranchaud/fix-a-typo-in-ownership-guide

rollup merge of #19812: frewsxcv/expansion-include-enum

In preparation for [removing the `std::cmp::Ordering` reexport](https://github.com/rust-lang/rust/issues/19253), this needs to be done to prevent errors like:

```
note: in expansion of #[deriving]
note: expansion site
error: unresolved name `std::cmp::Equal`
#[deriving(Clone, PartialEq, PartialOrd, Eq, Ord, Show)]
                                             ^~~
```

rollup merge of #19804: kballard/vim-new-unicode-escapes

rollup merge of #19802: jbranchaud/add-btreeset-new-doctest

rollup merge of #19793: tomjakubowski/metadata-const-attrs

Fix #19773

Together with #19774 (which this is rebased on):

Fix #18156, fix #19722, fix #19185

r? @alexcrichton (since this was your suggestion!)

rollup merge of #19787: akiss77/fix-i8-c_char

On AArch64, libc::c_char is u8. There are some places in the code where i8 is assumed, which causes compilation errors.

(AArch64 is not officially supported yet, but this change does not hurt any other targets and makes the code future-proof.)

rollup merge of #19784: csouth3/vim-syntax-iter

Vim still incorrectly highlights just `ExactSize` as a valid trait name, but the trait has been renamed to `ExactSizeIterator`.

rollup merge of #19779: Noctune/master

The old PartialOrd impl for raw pointers would always return Some(_), so It might as well implement Ord too.

rollup merge of #19775: SimonSapin/gedit-new-unicode-escape

rollup merge of #19774: tomjakubowski/rustdoc-consts-statics

Build `clean::ConstantItem` values in the `inline` module and
pretty-print the AST for inlined const items.

Doc strings are still missing from inlined constants (see #19773).

Partially address #18156, #19722, #19185

Fix #15821

r? @alexcrichton

rollup merge of #19771: jbranchaud/add-btreeset-iter-doctests

rollup merge of #19763: csouth3/remove-featuregates

This is a revival of #19517 (per request of @alexcrichton) now that the new snapshots have landed.  We can now remove the last feature gates for if_let, while_let, and tuple_indexing scattered throughout the test sources since these features have been added to Rust.

Closes #19473.

rollup merge of #19754: steveklabnik/remove_sundown

rollup merge of #19746: steveklabnik/gh9266

Fixes #9266

rollup merge of #19738: steveklabnik/gh19717

Fixes #19717

rollup merge of #19735: sethpollack/patch-1

rollup merge of #19714: steveklabnik/gh16219

These should be properly annotated instead.

Fixes #16219.

rollup merge of #19710: steveklabnik/gh15449

Fixes #15499.

rollup merge of #19709: steveklabnik/po4a_fix

This line was declared twice, which causes the build of i10n docs to
fail.

auto merge of #19778 : aochagavia/rust/ice, r=alexcrichton

Fixes #19734

auto merge of #19750 : murarth/rust/rusti-support, r=brson

Makes a couple changes that support the implementation of a REPL:

* Implementation of wrapper code for LLVM ExecutionEngine API
* Fixing a change I made earlier to reset compiler state in `phase_1_[...]`
  instead of `compile_input` as the latter is not used in a REPL

std: Collapse SlicePrelude traits

This commit collapses the various prelude traits for slices into just one trait:

* SlicePrelude/SliceAllocPrelude => SliceExt
* CloneSlicePrelude/CloneSliceAllocPrelude => CloneSliceExt
* OrdSlicePrelude/OrdSliceAllocPrelude => OrdSliceExt
* PartialEqSlicePrelude => PartialEqSliceExt

auto merge of #19742 : vhbit/rust/copy-for-bitflags, r=alexcrichton

auto merge of #19703 : nikomatsakis/rust/unsafe-trait, r=acrichto

This PR allows declaring traits and impls as `unsafe`. An `unsafe` trait requires an `unsafe` impl. An `unsafe` impl does not permit unsafe code within its interior (unless that code is contained within an unsafe block or unsafe fn, as normal). The commits are standalone.

r? @alexcrichton
cc #13231

Add a bunch of new tests per Alex's suggestion.

Implement `unsafe trait` semantics.

Parse `unsafe impl` but don't do anything particularly interesting with the results.

Parse `unsafe trait` but do not do anything with it beyond parsing and integrating into rustdoc etc.

Rename FnStyle trait to Unsafety.

auto merge of #19725 : vadimcn/rust/inst-path, r=alexcrichton

Change default installation directory to %SYSTEMDRIVE%\Rust.
Modify user PATH, rather than system PATH.

Modify `regex::Captures::{at,name}` to return `Option`

Closes #14602.  As discussed in that issue, the existing `at` and `name`
functions represent two different results with the empty string:

1. Matched the empty string.
2. Did not match anything.

Consider the following example.  This regex has two named matched
groups, `key` and `value`. `value` is optional:

```rust
// Matches "foo", "foo;v=bar" and "foo;v=".
regex!(r"(?P<key>[a-z]+)(;v=(?P<value>[a-z]*))?");
```

We can access `value` using `caps.name("value")`, but there's no way for
us to distinguish between the `"foo"` and `"foo;v="` cases.

Early this year, @BurntSushi recommended modifying the existing `at` and
`name` functions to return `Option`, instead of adding new functions to
the API.

This is a [breaking-change], but the fix is easy:

- `refs.at(1)` becomes `refs.at(1).unwrap_or("")`.
- `refs.name(name)` becomes `refs.name(name).unwrap_or("")`.

auto merge of #19338 : nikomatsakis/rust/unboxed-closure-purge-the-proc, r=acrichto

They are replaced with unboxed closures.

cc @pcwalton @aturon

This is a [breaking-change]. Mostly, uses of `proc()` simply need to be converted to `move||` (unboxed closures), but in some cases the adaptations required are more complex (particularly for library authors). A detailed write-up can be found here: http://smallcultfollowing.com/babysteps/blog/2014/11/26/purging-proc/

The commits are ordered to emphasize the more important changes, but are not truly standalone.

auto merge of #19690 : barosl/rust/struct-variant-as-a-function-ice, r=alexcrichton

Unlike a tuple variant constructor which can be called as a function, a struct variant constructor is not a function, so cannot be called.

If the user tries to assign the constructor to a variable, an ICE occurs, because there is no way to use it later. So we should stop the constructor from being used like that.

A similar mechanism already exists for a normal struct, as it prohibits a struct from being resolved. This commit does the same for a struct variant.

This commit also includes some changes to the existing tests.

Fixes #19452.

Stop using diagnostics to avoid merge conflicts.

Temporarily remove issue #14039; it is fixed and re-added by PR #19438

Add some tests for obsolete code, sugar used in appropriate ways.

Update emacs and vi modes.

Update guide/intro to take into account the removal of `proc`.

cc @steveklabnick

Delete tests that are either no longer relevant or which have
duplicate tests around object types.

Mostly rote conversion of `proc()` to `move||` (and occasionally `Thunk::new`)

Rewrite WorkItem not to use `proc()`.

Patch rustdoc to include missing types, make the match exhaustive
to prevent such oversights in the future.

Remove `proc` types/expressions from the parser, compiler, and
language. Recommend `move||` instead.

Adjust feature gates to allow for parenthetical notation to be used
with the fn traits

Purge the hack that allows `FnOnce` to be used with a by-value self method.  Besides being yucky, it will cause problems if we try to make all traits implement themselves, which would make a lot of things in life easier. Also, it was inextricably linked to `Box`, which was not the intention.  We can work around its absence, so better to reimplement it later in a more thorough fashion.

Rewrite threading infrastructure, introducing `Thunk` to represent
boxed `FnOnce` closures.

auto merge of #19677 : japaric/rust/deprecate-tupleN, r=alexcrichton

r? @alexcrichton or anyone else
closes #18006

rustc: Start the deprecation of libserialize

The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.

The current libserialize library, however, has a number of drawbacks:

* The API is not ready to be stabilize as-is and we will likely not have enough
  resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
  being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
  maintaining backwards compatibility.

One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.

For these reasons, this commit starts off a stability story for libserialize by
following these steps:

1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
   renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
   rustc-serialize crate shipped on crates.io. The contents of the crate will be
   the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
   deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
   expansions for each deriving mode will change from `::serialize::foo` to
   `::rustc_serialize::foo`.

This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.

The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:

* If plugins have a stable API, then any crate can provide a custom `deriving`
  mode (will require some compiler work). This means that any new serialization
  crate can provide its own `deriving` with its own backing
  implementation, entirely obsoleting the current libserialize and fully
  replacing it.

* Erick is exploring the possibility of code generation via preprocessing Rust
  source files in the near term until plugins are stable. This strategy would
  provide the same ergonomic benefit that `deriving` does today in theory.

So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.

Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.

Change `VecMap`'s iterators to use wrapper structs instead of typedefs.

Using a type alias for iterator implementations is fragile since this
exposes the implementation to users of the iterator, and any changes
could break existing code.

This commit changes the iterators of `VecMap` to use
proper new types, rather than type aliases.  However, since it is
fair-game to treat a type-alias as the aliased type, this is a:

[breaking-change].

libcollections: convert `BTreeSet` binops to by value

libcollections: convert `TreeSet` binops to by value

libcollections: convert `TrieSet` binops to by value

Test binops move semantics

libcollections: add commutative version of `Vec`/`String` addition

Address Niko's comments

libcore: fix doctests

libstd: fix unit tests

libcoretest: fix unit tests

libcollections: fix unit tests

Fix compile-fail tests

Fix run-pass tests

Test that binops consume their arguments

librustdoc: convert `Counts` binops to by value