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.

libcore: make iterator adaptors `Clone`able

InvariantLifetime is Copy-able

Both ContravariantLifetime and CovariantLifetime are marked as Copy,
so it makes sense for InvariantLifetime to be as well.

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

libsyntax: Output where clauses in pretty printer for structs.

libsyntax: Make deriving also respect where bounds.

Fix mispelling in char.rs error message

Error message has wrong spelling ("radix is to high").

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

librustc: convert `TypeContents` binops to by value

libsyntax: convert `LockstepIterSize` binops to by value

libsyntax: convert `BytePos`/`CharPos` binops to by value

libtime: convert `Timespec` binops to by value

libstd: convert `Duration` binops to by value

libstd: convert `BitFlags` binops to by value

libcollections: make `EnumSet` binops by value

libcollections: String + &str

libcollections: Vec<T> + &[T]

libcore: fix move semantics fallout

libcore: convert binop traits to by value

Tell regionck which binops are by value

Tell expr_use_visitor which binops are by value

Tell trans which binops are by value

Tell typeck which binops are by value

syntax/ast_util: add `is_by_value_binop()`

auto merge of #19669 : alfie/rust/master, r=sanxiyn

Get rid of all the remaining uses of `refN`/`valN`/`mutN`/`TupleN`

libcore: allow deprecated `valN` methods on doc tests

libgraphviz: use tuple indexing

libcoretest: use tuple indexing

librustdoc: use tuple indexing

librustc_trans: use tuple indexing

librustc: use tuple indexing

libsyntax: use tuple indexing

libregex: use tuple indexing

libstd: use tuple indexing

libcollections: use tuple indexing

libunicode: use tuple indexing

Deprecate the `TupleN` traits

auto merge of #19467 : japaric/rust/uc, r=alexcrichton

This PR moves almost all our current uses of closures, both in public API and internal uses, to the new "unboxed" closures system.

In most cases, downstream code that *only uses* closures will continue to work as it is. The reason is that the `|| {}` syntax can be inferred either as a boxed or an "unboxed" closure according to the context. For example the following code will continue to work:

``` rust
some_option.map(|x| x.transform_with(upvar))
```

And will get silently upgraded to an "unboxed" closure.

In some other cases, it may be necessary to "annotate" which `Fn*` trait the closure implements:

```
// Change this
|x| { /* body */}
// to either of these
|: x| { /* body */}  // closure implements the FnOnce trait
|&mut : x| { /* body */}  // FnMut
|&: x| { /* body */}  // Fn
```

This mainly occurs when the closure is assigned to a variable first, and then passed to a function/method.

``` rust
let closure = |: x| x.transform_with(upvar);
some.option.map(closure)
```

(It's very likely that in the future, an improved inference engine will make this annotation unnecessary)

Other cases that require annotation are closures that implement some trait via a blanket `impl`, for example:

- `std::finally::Finally`
- `regex::Replacer`
- `std::str::CharEq`

``` rust
string.trim_left_chars(|c: char| c.is_whitespace())
//~^ ERROR: the trait `Fn<(char,), bool>` is not implemented for the type `|char| -> bool`
string.trim_left_chars(|&: c: char| c.is_whitespace())  // OK
```

Finally, all implementations of traits that contain boxed closures in the arguments of their methods are now broken. And will need to be updated to use unboxed closures. These are the main affected traits:

- `serialize::Decoder`
- `serialize::DecoderHelpers`
- `serialize::Encoder`
- `serialize::EncoderHelpers`
- `rustrt::ToCStr`

For example, change this:

``` rust
// libserialize/json.rs
impl<'a> Encoder<io::IoError> for Encoder<'a> {
    fn emit_enum(&mut self,
                 _name: &str,
                 f: |&mut Encoder<'a>| -> EncodeResult) -> EncodeResult {
        f(self)
    }
}
```

to:

``` rust
// libserialize/json.rs
impl<'a> Encoder<io::IoError> for Encoder<'a> {
    fn emit_enum<F>(&mut self, _name: &str, f: F) -> EncodeResult where
        F: FnOnce(&mut Encoder<'a>) -> EncodeResult
    {
        f(self)
    }
}
```

[breaking-change]

---

### How the `Fn*` bound has been selected

I've chosen the bounds to make the functions/structs as "generic as possible", i.e. to let them allow the maximum amount of input.

- An `F: FnOnce` bound accepts the three kinds of closures: `|:|`, `|&mut:|` and `|&:|`.
- An `F: FnMut` bound only accepts "non-consuming" closures: `|&mut:|` and `|&:|`.
- An `F: Fn` bound only accept the "immutable environment" closures: `|&:|`.

This means that whenever possible the `FnOnce` bound has been used, if the `FnOnce` bound couldn't be used, then the `FnMut` was used. The `Fn` bound was never used in the whole repository.

The `FnMut` bound was the most used, because it resembles the semantics of the current boxed closures: the closure can modify its environment, and the closure may be called several times.

The `FnOnce` bound allows new semantics: you can move out the upvars when the closure is called. This can be effectively paired with the `move || {}` syntax to transfer ownership from the environment to the closure caller.

In the case of trait methods, is hard to select the "right" bound since we can't control how the trait may be implemented by downstream users. In these cases, I have selected the bound based on how we use these traits in the repository. For this reason the selected bounds may not be ideal, and may require tweaking before stabilization.

r? @aturon

librustc_borrowck: add `#![feature(unboxed_closures)]`

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

libstd: add missing imports

Remove some unnecessary `move` keywords

libtest: use unboxed closures

librustc_driver: use unboxed closures

librustc_typeck: use unboxed closures

librustdoc: use unboxed closures

librustc_trans: use unboxed closures

librustc_trans: fix fallout

librustc_typeck: fix fallout

librustc: use unboxed closures

librustc_llvm: use unboxed closures

librustc_trans: fix fallout

librustc_back: use unboxed closures

librustc: fix fallout

libsyntax: use unboxed closures

Fix benches

libstd: use unboxed closures

librustrt: use unboxed closures

libregex_macros: use unboxed closures

libcollections: use unboxed closures

libserialize: use unboxed closures

libregex: use unboxed closures

libarena: use unboxed closures

libregex: fix fallout in doc tests

libregex: impl Replacer for FnMut(&Captures) -> String implementors

librustc: fix fallout

librbml: use unboxed closures in free functions