use option_env! instead of env!
Pre-step towards issue #12624 and others: Introduce ExprUseVisitor, remove the
moves computation. ExprUseVisitor is a visitor that walks the AST for a
function and calls a delegate to inform it where borrows, copies, and moves
occur.

In this patch, I rewrite the gather_loans visitor to use ExprUseVisitor, but in
future patches, I think we could rewrite regionck, check_loans, and possibly
other passes to use it as well. This would refactor the repeated code between
those places that tries to determine where copies/moves/etc occur.
Convert delegate to use an object type and remove FIXME from closed issue
Remove default method implementations
Provide an implementation of DoubleEndedIterator for the results of &[T]::split and &[T]::rsplit

This makes the splitting functions in std::slice return DoubleEndedIterators. Unfortunately,
splitn and rsplitn cannot provide such an interface and so must return different types. As a
result, the following changes were made:

* RevSplits was removed in favor of explicitly using Rev
* Splits can no longer bound the number of splits done
* Splits now implements DoubleEndedIterator
* SplitsN was added, taking the role of what both Splits and RevSplits used to be
* rsplit returns Rev<Splits<'a, T>> instead of RevSplits<'a, T>
* splitn returns SplitsN<'a, T> instead of Splits<'a, T>
* rsplitn returns SplitsN<'a, T> instead of RevSplits<'a, T>

All functions that were previously implemented on each return value still are, so outside of changing
of type annotations, existing code should work out of the box. In the rare case that code relied
on the return types of split and splitn or of rsplit and rsplitn being the same, the previous
behavior can be emulated by calling splitn or rsplitn with a bount of uint::MAX.

The value of this change comes in multiple parts:

* Consistency. The splitting code in std::str is structured similarly to the new slice splitting code,
  having separate CharSplits and CharSplitsN types.
* Smaller API. Although this commit doesn't implement it, using a DoubleEndedIterator for splitting
  means that rsplit, path::RevComponents, path::RevStrComponents, Path::rev_components, and
  Path::rev_str_components are no longer needed - they can be emulated simply with .rev().
* Power. DoubleEndedIterators are able to traverse the list from both sides at once instead of only
  forwards or backwards.
* Efficiency. For the common case of using split instead of splitn, the iterator is slightly smaller
  and slightly faster.

[breaking-change]
Deprecate the rev_iter pattern in all places where a DoubleEndedIterator is provided (everywhere but treemap)

This commit deprecates rev_iter, mut_rev_iter, move_rev_iter everywhere (except treemap) and also
deprecates related functions like rsplit, rev_components, and rev_str_components. In every case,
these functions can be replaced with the non-reversed form followed by a call to .rev(). To make this
more concrete, a translation table for all functional changes necessary follows:

* container.rev_iter() -> container.iter().rev()
* container.mut_rev_iter() -> container.mut_iter().rev()
* container.move_rev_iter() -> container.move_iter().rev()
* sliceorstr.rsplit(sep) -> sliceorstr.split(sep).rev()
* path.rev_components() -> path.components().rev()
* path.rev_str_components() -> path.str_components().rev()

In terms of the type system, this change also deprecates any specialized reversed iterator types (except
in treemap), opting instead to use Rev directly if any type annotations are needed. However, since
methods directly returning reversed iterators are now discouraged, the need for such annotations should
be small. However, in those cases, the general pattern for conversion is to take whatever follows Rev in
the original reversed name and surround it with Rev<>:

* RevComponents<'a> -> Rev<Components<'a>>
* RevStrComponents<'a> -> Rev<StrComponents<'a>>
* RevItems<'a, T> -> Rev<Items<'a, T>>
* etc.

The reasoning behind this change is that it makes the standard API much simpler without reducing readability,
performance, or power. The presence of functions such as rev_iter adds more boilerplate code to libraries
(all of which simply call .iter().rev()), clutters up the documentation, and only helps code by saving two
characters. Additionally, the numerous type synonyms that were used to make the type signatures look nice
like RevItems add even more boilerplate and clutter up the docs even more. With this change, all that cruft
goes away.

[breaking-change]
regex: remove the use of ~[] & some unnecessary ~'s.

The AST doesn't need ~s everywhere, so we can save allocations this way
& the enum isn't particularly large (~4 words) nor are regexes
long (normally), so the space saved in the `Cat` vector is unlikely to
be very much.
regex: General style tweaks.

For loops are nicer than manual whiles, etc.
Add a bitflags! macro

The `bitflags!` macro generates a `struct` that holds a set of C-style bitmask flags. It is useful for creating typesafe wrappers for C APIs.

For example:

~~~rust
#[feature(phase)];
#[phase(syntax)] extern crate collections;

bitflags!(Flags: u32 {
    FlagA       = 0x00000001,
    FlagB       = 0x00000010,
    FlagC       = 0x00000100,
    FlagABC     = FlagA.bits
                | FlagB.bits
                | FlagC.bits
})

fn main() {
    let e1 = FlagA | FlagC;
    let e2 = FlagB | FlagC;
    assert!((e1 | e2) == FlagABC);   // union
    assert!((e1 & e2) == FlagC);     // intersection
    assert!((e1 - e2) == FlagA);     // set difference
}
~~~
Document how generated bitflags can be extended with type and trait implementations
Document derived traits for bitset! macro
rustdoc: fix overly broad selectors
auto merge of #13863 : huonw/rust/re-tweaks, r=pcwalton

Mostly code style e.g. avoiding `~` and using `for` + iterators.
Move bitflags module to libstd

This will allow us to provide type-safe APIs in libstd that are C-compatible.
Update for language changes
auto merge of #13072 : bjz/rust/bitset, r=alexcrichton

The `bitflags!` macro generates a `struct` that holds a set of C-style bitmask flags. It is useful for creating typesafe wrappers for C APIs.

For example:

~~~rust
#[feature(phase)];
#[phase(syntax)] extern crate collections;

bitflags!(Flags: u32 {
    FlagA       = 0x00000001,
    FlagB       = 0x00000010,
    FlagC       = 0x00000100,
    FlagABC     = FlagA.bits
                | FlagB.bits
                | FlagC.bits
})

fn main() {
    let e1 = FlagA | FlagC;
    let e2 = FlagB | FlagC;
    assert!((e1 | e2) == FlagABC);   // union
    assert!((e1 & e2) == FlagC);     // intersection
    assert!((e1 - e2) == FlagA);     // set difference
}
~~~
auto merge of #13864 : adrientetar/rust/fix-it-some-more, r=alexcrichton

Two selector fixes for rustdoc:

- links colored in blue (#13807) was also affecting headers, which are anchored to their respective ids
- the header unstyling from #13776 was being applied to all headers also

Additionally, remove a stray title in the documentation. This makes the crate title of prelude appear as header instead of an inline paragraph of text (all others work normally and do not have that header tag).

The design is unchanged from my previous template (e.g. [here](http://adrientetar.legtux.org/cached/rust-docs/struct.CChars.htm)), however it is now properly applied.  
The last fix remaining is to enable webfonts service from `static.rust-lang.org`, this is #13593.

r? @alexcrichton, @brson
auto merge of #13648 : gereeter/rust/removed-rev, r=alexcrichton

In the process, `Splits` got changed to be more like `CharSplits` in `str` to present the DEI interface.

Note that `treemap` still has a `rev_iter` function because it seems like it would be a significant interface change to expose a DEI - the iterator would have to gain an extra pointer, the completion checks would be more complicated, and it isn't easy to check that such an implementation is correct due to the use of unsafety to subvert the aliasing properties of `&mut`.

This fixes #9391.
Address nits from @pnkfelix
rustc: Fix def ids of xcrate-reexported items

This was just a typo in the decoder using the source crate's number rather than
the destination crate's number of a reexport.

Closes #13872