libcore: combine cmp::Ordering instances in lexical order.
libsyntax: derive Clone, Eq, TotalEq, Ord, TotalOrd with the new generic deriving code.

Closes #4269, #5588 and #5589.
testsuite: add tests for derived Eq, TotalEq, Ord, TotalOrd.
libsyntax: short-circuit on non-matching variants in deriving code.

Allow a deriving instance using the generic code to short-circuit for
any non-matching enum variants (grouping them all into a _ match),
reducing the number of arms required. Use this to speed up the Eq &
TotalEq implementations.
tutorial-ffi: add missing word
auto merge of #5850 : thestinger/rust/ffi, r=thestinger
Added xfail-fast to test so the windows buildbot doesn't choke
libsyntax: (maybe) fix deriving(TotalOrd) on windows
auto merge of #5809 : Aatch/rust/start-attr, r=thestinger

This implements #5158. Currently it takes the command line args and the crate map. Since it doesn't take a `main` function pointer, you can't actually start the runtime easily, but that seems to be a shim to allow the current `rust_start` function to call into main.

However, you can do an end-run round the io library and do this:

```rust
use core::libc::{write, c_int, c_void, size_t, STDOUT_FILENO};

#[start]
fn my_start(_argc:int, _argv: **u8, _crate_map: *u8) -> int {
    do str::as_buf("Hello World!\n") |s,len| {
        unsafe {
            write(STDOUT_FILENO, s as *c_void, len as size_t);
        }
    }
    return 0;
}
```

Which is the most basic "Hello World" you can do in rust without starting up the runtime (though that has quite a lot to do with the fact that `core::io` uses `@` everywhere...)
libsyntax: another fix for deriving on windows.
tutorial-ffi: add another missing word
auto merge of #5852 : thestinger/rust/ffi, r=thestinger
auto merge of #5640 : dbaupp/rust/syntax-generalise-deriving, r=thestinger

This refactors much of the ast generation required for `deriving` instances into a common interface, so that new instances only need to specify what they do with the actual data, rather than worry about naming function arguments and extracting fields from structs and enum. (This all happens in `generic.rs`. I've tried to make sure it was well commented and explained, since it's a little abstract at points, but I'm sure it's still a little confusing.)

It makes instances like the comparison traits and `Clone` short and easy to write.

Caveats:
- Not surprisingly, this slows the expansion pass (in some cases, dramatically, specifically deriving Ord or TotalOrd on enums with many variants).   However, this shouldn't be too concerning, since in a more realistic case (compiling `core.rc`) the time increased by 0.01s, which isn't worth mentioning. And, it possibly slows type checking very slightly (about 2% worst case), but I'm having trouble measuring it (and I don't understand why this would happen). I think this could be resolved by using traits and encoding it all in the type system so that monomorphisation handles everything, but that would probably be a little tricky to arrange nicely, reduce flexibility and make compiling rustc take longer. (Maybe some judicious use of `#[inline(always)]` would help too; I'll have a bit of a play with it.)
- The abstraction is not currently powerful enough for:
  - `IterBytes`: doesn't support arguments of type other than `&Self`.
  - `Encodable`/`Decodable` (#5090): doesn't support traits with parameters.
  - `Rand` & `FromStr`; doesn't support static functions and arguments of type other than `&Self`.
   - `ToStr`: I don't think it supports returning `~str` yet, but I haven't actually tried.

  (The last 3 are traits that might be nice to have: the derived `ToStr`/`FromStr` could just read/write the same format as `fmt!("%?", x)`, like `Show` and `Read` in Haskell.)
 
  I have ideas to resolve all of these, but I feel like it would essentially be a simpler version of the `mt` & `ty_` parts of `ast.rs`, and I'm not sure if the simplification is worth having 2 copies of similar code.

Also, makes Ord, TotalOrd and TotalEq derivable (closes #4269, #5588 and #5589), although a snapshot is required before they can be used in the rust repo.

If there is anything that is unclear (or incorrect) either here or in the code, I'd like to get it pointed out now, so I can explain/fix it while I'm still intimately familiar with the code.
add rustdoc comments with examples for the string versions of to_base64 and from_base64
Tidy
auto merge of #5847 : catamorphism/rust/rustpkg, r=catamorphism

r? @graydon This is preliminary work on bringing rustpkg up to conformance with #5679
and related issues.

This change makes rustpkg infer a package ID from its containing directory,
instead of requiring name and vers attributes in the code. Many aspects of it
are incomplete; I've only tested one package (see README.txt) and one command,
"build". So far it only works for local packages.

I also removed code for several of the package commands other than "build",
replacing them with stubs that fail, since they used package IDs in ways that
didn't jibe well with the new scheme. I will re-implement the commands one
at a time.
auto merge of #5827 : nikomatsakis/rust/issue-5656-change-meaning-of-borrowed-self, r=pcwalton

See #5656 for details.

r? @pcwalton
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 some more generated files to the .gitignore file
auto merge of #5859 : huonw/rust/gitignore, r=catamorphism