std::at_vec: add benchmarks
librustc: Allow vector repeat exprs in statics.
Add RngUtils::sample() method for reservoir sampling from iterators
Remove unused automatic cfg bindings Fixes #7169
Add test for repeat expr in statics.
rustc: allow @ as-patterns to move when the sub-pattern contains no bindings.

A pattern like `foo @ Foo(Bar(*), _)` should be legal, even if `foo` moves,
since the subpatterns are purely structural.

Fixes #3761.
std: Move the iterator param on FromIterator and Extendable to the method.

If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:

    fn foo<E: Extendable<int, Range<int>> +
              Extendable<int, Map<&'self int, int, VecIterator<int>>>
          (e: &mut E, ...) { ... }

since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).

This patch changes it to:

    fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
Rewrite Saturating in terms of CheckedAdd/CheckedSub
Switch to new <V:Visitor> visitor (rather than @Visitor).

Alpha-renamed top-level visit_* functions to walk_*.
(Motivation: Distinguish visit action and recursive traversal.)

Abstract over `&mut self` rather than over `@mut self`.

This required some acrobatics, notably the

  `impl<E> Visitor<E> for @mut Visitor<E>`

and corresponding introduction of `@mut Visitor` and some local `let
mut` bindings.

Remove oldvisit reference.

Added default implementations for all of the Visitor trait methods.

Note that both `visit_expr_post` and `visit_ty` are no-op's by
default, just like they are in `oldvisit::default_visitor`.

Refactoring: extract logic to ease swapping visit for oldvisit (hopefully).
Switch metadata::encoder to <V:Visitor> trait.

placate make tidy.  Remove dead code.
Switch borrowck::gather_loans to <V:Visitor> visit API.

Placate make tidy.  Remove unnecessary references to oldvisit.
Switch main borrowck to <V:Visitor> trait API.

fix borrowck/mod.rs to deal with fn_kind enum fallout.
auto merge of #8481 : cmr/rust/bench/std/at_vec, r=graydon
auto merge of #8483 : luqmana/rust/rexprs, r=catamorphism

Fixes #8152.
auto merge of #8490 : huonw/rust/fromiterator-extendable, r=catamorphism



If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:

    fn foo<E: Extendable<int, Range<int>> +
              Extendable<int, Map<&'self int, int, VecIterator<int>>>
          (e: &mut E, ...) { ... }

since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).

This patch changes it to:

    fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
auto merge of #8527 : pnkfelix/rust/fsk-visitor-vpar-defaults-step1, r=nikomatsakis

Rewriting visit.rs to operate on a borrowed `&mut V` where `<V:Visitor>`

r? @nikomatsakis
r? @pcwalton

This is the first in a planned series of incremental pull requests.  (There will probably be five pull requests including this one, though they can be combined or split as necessary.)

Part of #7081.  (But definitely does *not* complete it, not on its own, and not even after all five parts land; there are still a few loose ends to tie up or trim afterwards.)

The bulk of this change for this particular PR is pnkfelix@3d83010, which has the changes necessary to visit.rs to support everything else that comes later.  The other commits are illustrating the standard mechanical transformation that I am applying.

One important point for nearly *all* of these pull requests: I was deliberately *not* trying to be intelligent in the transformation. 

 * My goal was to minimize code churn, and make the transformation as mechanical as possible.  
 * For example, I kept the separation between the Visitor struct (corresponding to the earlier vtable of functions that were potentially closed over local state) and the explicitly passed (and clones) visitor Env.  I am certain that this is almost always unnecessary, and a later task will be to go through an meld the Env's into the Visitors as appropriate.  (My original goal had been to make such melding part of this task; that's why I turned them into a (Env, vtable) tuple way back when.  But I digress.)
 * Also, my main goal here was to get rid of the record of `@fn`'s as described by the oldvisit.rs API.  (This series gets rid of all but one such case; I'm still investigating that.)  There is *still* plenty of `@`-boxing left to be removed, I'm sure, and even still some `@fn`'s too; removing all of those is not the goal here; its just to get rid of the encoded protocol of `@fn`'s in the (old)visit API.

To see where things will be going in the future (i.e., to get a sneak-preview of future pull-requests in the series), see:

 * https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step1 (that's this one)
 * https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step2
 * https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step3
 * https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step4
 * https://github.com/pnkfelix/rust/commits/fsk-visitor-vpar-defaults-step5
    * Note that between step 4 and step 5 there is just a single commit, but its a doozy because its the only case where my mechanical transformation did not apply, and thus more serious rewriting was necessary.  See commit pnkfelix@da902b2ff3b1e0bee9fc63cf00c449cceea8abf7
auto merge of #8491 : robertknight/rust/7722-reservoir_sampling, r=graydon

Fixes #7722

I had a couple of queries:
- Should this return an array or an iterator?
- Should this be a method on iterators or on the rng? I implemented it in RngUtils as it seemed to belong with shuffle().
auto merge of #8499 : nickdesaulniers/rust/issue7169, r=graydon

review? @brson 
tests are green
auto merge of #8515 : kballard/rust/saturating-checked, r=thestinger

r? @thestinger