Generalize stats from f64 to the Float trait
Use is_zero
docs: change compositionality to composability
vim: Fix indentation at global scope after non-semantic ([{/)]}

If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.

Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.
std: deprecate cast::transmute_mut.

Turning a `&T` into an `&mut T` carries a large risk of undefined
behaviour, and needs to be done very very carefully. Providing a
convenience function for exactly this task is a bad idea, just tempting
people into doing the wrong thing.

The right thing is to use types like `Cell`, `RefCell` or `Unsafe`.

For memory safety, Rust has that guarantee that `&mut` pointers do not
alias with any other pointer, that is, if you have a `&mut T` then that
is the only usable pointer to that `T`. This allows Rust to assume that
writes through a `&mut T` do not affect the values of any other `&` or
`&mut` references. `&` pointers have no guarantees about aliasing or
not, so it's entirely possible for the same pointer to be passed into
both arguments of a function like

    fn foo(x: &int, y: &int) { ... }

Converting either of `x` or `y` to a `&mut` pointer and modifying it
would affect the other value: invalid behaviour.

(Similarly, it's undefined behaviour to modify the value of an immutable
local, like `let x = 1;`.)

At a low-level, the *only* safe way to obtain an `&mut` out of a `&` is
using the `Unsafe` type (there are higher level wrappers around it, like
`Cell`, `RefCell`, `Mutex` etc.). The `Unsafe` type is registered with
the compiler so that it can reason a little about these `&` to `&mut`
casts, but it is still up to the user to ensure that the `&mut`s
obtained out of an `Unsafe` never alias.

(Note that *any* conversion from `&` to `&mut` can be invalid, including
a plain `transmute`, or casting `&T` -> `*T` -> `*mut T` -> `&mut T`.)

[breaking-change]
std::comm: use Unsafe to avoid U.B. & -> &mut transmutes.
Cleanup proc comment in guide-tasks.md.
Reverse #13034

It has been found that #13034 was flawed and caused regression #13867.
This patch reveres the changes made by it except the companion tests.
Adjust codegen logic for range and guarded arms

By carefully distinguishing falling back to the default arm from moving
on to the next pattern, this patch adjusts the codegen logic for range
and guarded arms of pattern matching expression. It is a more
appropriate way of fixing #12582 and #13027 without causing regressions
such as #13867.

Closes #13867
log: Logger receiveis a LogRecord

The logging macros now create a LogRecord, and pass that to the
Logger, instead of passing a `level` and `args`. The new signature is:

    trait Logger {
        fn log(&mut self, record: &LogRecord);
    }

The LogRecord includes additional values that may be useful to custom
loggers, and also allows for further expansion if not values are found
useful.

DefaultLogger's formatting was taken from Python's default formatting:
`LEVEL:from: message`

Also included: fmt::Arguments now implement Show, so they can be used to
extend format strings.

[breaking-change]
Updated CONTRIBUTING.md for 2014
Allow attributes in std::bitflags::bitflags!

The `std::bitflags::bitflags!` macro did not provide support for
adding attributes to the generated structure or flags, due to
limitations in the parser for macros. This patch works around the
parser limitations by requiring a `flags` keyword in the overall
`bitflags!` invocation, and a `static` keyword for each flag:

    bitflags!(
        #[deriving(Hash)]
        #[doc="Three flags"]
        flags Flags: u32 {
            #[doc="The first flag"]
            static FlagA       = 0x00000001,
            static FlagB       = 0x00000010,
            static FlagC       = 0x00000100
        }
    )
Add (unsafe) coercion from bits to std::bitflags

The intent of `std::bitflags` is to allow building type-safe wrappers
around C-style flags APIs. But in addition to construction these flags
from the Rust side, we need a way to convert them from the C
side. This patch adds a `from_bits` function, which is unsafe since
the bits in question may not represent a valid combination of flags.
Change std::io::FilePermission to a typesafe representation

This patch changes `std::io::FilePermissions` from an exposed `u32`
representation to a typesafe representation (that only allows valid
flag combinations) using the `std::bitflags`, thus ensuring a greater
degree of safety on the Rust side.

Despite the change to the type, most code should continue to work
as-is, sincde the new type provides bit operations in the style of C
flags. To get at the underlying integer representation, use the `bits`
method; to (unsafely) convert to `FilePermissions`, use
`FilePermissions::from_bits`.

Closes #6085.

[breaking-change]
auto merge of #13912 : seanmonstar/rust/logrecord, r=alexcrichton

The logging macros now create a LogRecord, and pass that to the Logger. This will allow custom loggers to change the formatting, and possible filter on more properties of the log record.

DefaultLogger's formatting was taken from Python's default formatting:
`LEVEL:from: message`

Also included: fmt::Arguments now implement Show, so they can be used to
extend format strings.

@alexcrichton r?
auto merge of #13934 : huonw/rust/transmute-mut, r=alexcrichton

Turning a `&T` into an `&mut T` is undefined behaviour, and needs to be
done very very carefully. Providing a convenience function for exactly
this task is a bad idea, just tempting people into doing the wrong
thing.

(The right thing is to use types like `Cell`, `RefCell` or `Unsafe`.)

cc https://github.com/mozilla/rust/issues/13933
auto merge of #13940 : edwardw/rust/refutable-match, r=pcwalton

By carefully distinguishing falling back to the default arm from moving
on to the next pattern, this patch adjusts the codegen logic for range
and guarded arms of pattern matching expression. It is a more
appropriate way of fixing #12582 and #13027 without causing regressions
such as #13867.
    
Closes #13867
auto merge of #13946 : pnkfelix/rust/fsk-cleanup-proc-comment-in-guide-tasks, r=alexcrichton

Followup to some recent feedback in PR #13676.
Add Richo Healey to contributors
auto merge of #13925 : kballard/rust/vim_indent_bracket_fix, r=thestinger

If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.

Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.