Feed enum field offsets to type vistors.
Export adt::trans_get_discr abstractly to the type visitor.
When repr'ing an enum value, assert that it matched some variant.
Make the enum visit callback generator more readable
Make intrinsic::Opaque more opaque
add rustdoc comments with examples for the string versions of to_base64 and from_base64
rustpkg: Factor out tests; use a condition instead of returning an option

Pulled out tests into their own modules inside the files they test,
as per the draft style guidelines.

Started a new module, path_util, for utility functions to do with
paths and directories.

Changed default_dest_dir to use a condition and return Path
instead of Option<Path>.
Add comments for the implementations of from_base64 and to_base64 for .
fix index out of bounds error of x86_64 ABI
initial iterator object library
librusti: only use std::rl if stdin is connected to a tty.
move rustdoc comments so that they attach to the functions rather than the impl blocks.
Avoid excessive allocations and copies in iter::to_vec

The foldl based implementation allocates lots of unneeded vectors.
iter::map_to_vec is already optimized to avoid these.
Doc review, as requested :-).

Mostly just phrasing things differently, which is a matter of taste. Feel free to use or not use any of the changes I'm suggesting.

I would say this one thing should be changed, though, not necessarily the way I changed it here.

     * Convert any string (literal, `@`, `&`, `~`)
     * that contains a base64 encoded value, to the byte values it encodes.

If this structure is going to be used, either the entire clause, 'that contains a base64 encoded value', should be bracketed by commas, or the comma at the end of the clause should be removed.
auto merge of #5869 : bjz/rust/master, r=graydon

This restores the trait that was lost in 216e85fadf465c25fe7bc4a9f06f8162ec12b552. `Num` will eventually be broken up into a more fine-grained trait hierarchy in the future once a design can be agreed upon.

To contribute to the discussion about the future of Rust's numeric traits, please see issue #4819 and the [wiki page](https://github.com/mozilla/rust/wiki/Bikeshed-Numeric-Traits).

I have also switched to [implementing NumCast using macros](https://github.com/bjz/rust/commit/353ce872e287edf3764ca416d2a8cd8e1f54329b). This removes a significant number of lines of code.
auto merge of #5810 : thestinger/rust/iterator, r=graydon

The current protocol is very comparable to Python, where `.__iter__()` returns an iterator object which implements `.__next__()` and throws `StopIteration` on completion. `Option` is much cleaner than using a exceptions as a flow control hack though. It requires that the container is frozen so there's no worry about invalidating them.

Advantages over internal iterators, which are functions that are passed closures and directly implement the iteration protocol:

* Iteration is stateful, so you can interleave iteration over arbitrary containers. That's needed to implement algorithms like zip, merge, set union, set intersection, set difference and symmetric difference. I already used this internally in the `TreeMap` and `TreeSet` implementations, but regions and traits weren't solid enough to make it generic yet.
* They provide a universal, generic interface. The same trait is used for a forward/reverse iterator, an iterator over a range, etc. Internal iterators end up resulting in a trait for each possible way you could iterate.
* They can be composed with adaptors like `ZipIterator`, which also implement the same trait themselves.

The disadvantage is that they're a pain to write without support from the compiler for compiling something like `yield` to a state machine. :)

This can coexist alongside internal iterators since both can use the current `for` protocol. It's easier to write an internal iterator, but external ones are far more powerful/useful so they should probably be provided whenever possible by the standard library.

## Current issues

#5801 is somewhat annoying since explicit type hints are required.

I just wanted to get the essentials working well, so I haven't put much thought into making the naming concise (free functions vs. static `new` methods, etc.).

Making an `Iterable` trait seems like it will have to be a long-term goal, requiring type system extensions. At least without resorting to objects which would probably be unacceptably slow.
auto merge of #5864 : huonw/rust/rusti-detect-tty, r=graydon

This is a fairly large hack, just passing an extra argument through, and I can't test it at all, since rusti doesn't work here to begin with.
Merge pull request #1 from danluu/silly_style_changes

Doc review, as requested :-).
auto merge of #5867 : dotdash/rust/reduce_reallocs, r=graydon

The foldl based implementation allocates lots of unneeded vectors.
iter::map_to_vec is already optimized to avoid these.

One place that benefits quite a lot from this is the metadata decoder, helping with compile times for tiny programs.
Add a lint mode for unused unsafe blocks/functions