Rename assert_eq arguments to left and right.

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.
Deprecate more in-tree libs for crates.io

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
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].
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.
libcore: make iterator adaptors `Clone`able
Free stdin on exit
Remove internal uses of `marker::NoCopy`
libstd: add a dummy field to `OsRng` to avoid out of module construction
libgraphviz: add `label` and `escaped` ctors taking any `str::IntoMaybeOwned`.
libgraphviz: extend API with flags to indicate options like "do not include labels".
Added `-Z print-region-graph` debugging option; produces graphviz
visualization of region inference constraint graph.

Optionally uses environment variables `RUST_REGION_GRAPH=<path_template>`
and `RUST_REGION_GRAPH_NODE=<node-id>` to select which file to output
to and which AST node to print.

Note that in some cases of method AST's, the identification of AST
node is based on the id for the *body* of the method; this is largely
due to having the body node-id already available at the relevant point
in the control-flow of rustc in its current incarnation. Ideally we
would handle identifying AST's by name in addition to node-id,
e.g. the same way that the pretty-printer supports path suffixes as
well as node-ids for identifying subtrees to print.
Path types to associated types with form `T::A`

Closes #18433
Review changes
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).
Add probe and var for file

Was testing rustup on a very minimal Debian installation and got errors during the install process (error occurred in `install.sh` of the Rust nightly.)

Noticed that Rustup was downloading the i686 nightly instead of x86-64. Installing `file` fixed the problem, and this patch adds the probe to ensure file is installed before attempting to use it.

There may still be an issue with the i686 installation, I did not investigate further.
Move hash module from collections to core
Don't make unboxed closures implicitly copiable

The fix just checks if the bound is `Copy` and returns an `Err` if so.

Closes: #19817
AST refactor: make the place in ExprBox an option.

This is to allow us to migrate away from UnUniq in a followup commit,
and thus unify the code paths related to all forms of `box`.
Create a snapshot on top of 1b97cd3
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.