mk: target triple rename arm-unknown-android->arm-linux-androideabi
Represent enums with regular structs; no more alignment-breaking casts.
Make &self permit explicit lifetimes, but don't really use them
(this will be needed for snapshotting at some point).
Enable arm error handling abi
Enable arm error handling abi 2
Use NDK for building android target objects
Rewrite arm/ccall.s
Allow custom messages on assert statements
auto merge of #5356 : jld/rust/enum-less-magic, r=graydon

Fixes #1645.
auto merge of #5426 : nikomatsakis/rust/issue-4846-lifetimes-in-expl-self, r=pcwalton

(this will be needed for snapshotting at some point)

r? @pcwalton
librustc: adjust logic for cfg attribute and add not predicate.
Tests for cfg attribute.
rewrite the tutorial section on boxes
librustc: Enforce privacy for static methods.

This starts moving a bunch of privacy checks into the privacy
checking phase and out of resolve.
auto merge of #5428 : thestinger/rust/tutorial, r=catamorphism

My goal is to explain the underlying concepts first (destructors and then ownership) with plenty of step-by-step examples, so that thoroughly explaining the semantics of mutability, boxes, moves, etc. is a breeze. I'm trying to avoid the comparisons with C++ that were done before, because this should be approachable for people coming from any language. C++ programmers already know these concepts so they aren't the audience that needs to be catered to. Comparisons with other languages can be done in separate documents (like [this one](https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers)).

This still needs examples for ownership (inherited mutability), owned boxes and managed boxes.
Update run-pass/cfg-on-items.rs

Make comment describe actual behaviour.
libsyntax: Accept `static` instead of `const` for globals
libsyntax: Accept the new `[T, ..N]` style for vec.
syntax: move ext/deriving.rs to ext/deriving/mod.rs
auto merge of #5436 : alexcrichton/rust/assert-message, r=pcwalton

This would close #2761. I figured that if you're supplying your own custom message, you probably don't mind the stringification of the condition to not be in the message.