std::rand: wrappers for floats from [0,1] and (0,1).

Provide `Closed01` and `Open01` that generate directly from the
closed/open intervals from 0 to 1, in contrast to the plain impls for
f32 and f64 which generate the half-open [0,1).

Fixes #7755.
Mark some derived methods as #[inline].

ToStr, Encodable and Decodable are not marked as such, since they're
already expensive, and lead to large methods, so inlining will bloat the
metadata & the binaries.

This means that something like

    #[deriving(Eq)]
    struct A { x: int }

creates an instance like

    #[doc = "Automatically derived."]
    impl ::std::cmp::Eq for A {
        #[inline]
        fn eq(&self, __arg_0: &A) -> ::bool {
            match *__arg_0 {
                A{x: ref __self_1_0} =>
                match *self {
                    A{x: ref __self_0_0} => true && __self_0_0.eq(__self_1_0)
                }
            }
        }
        #[inline]
        fn ne(&self, __arg_0: &A) -> ::bool {
            match *__arg_0 {
                A{x: ref __self_1_0} =>
                match *self {
                    A{x: ref __self_0_0} => false || __self_0_0.ne(__self_1_0)
                }
            }
        }
    }

(The change being the `#[inline]` attributes.)
Allow piped stdout/stderr use uv_tty_t

There are issues with reading stdin when it is actually attached to a pipe, but
I have run into no problems in writing to stdout/stderr when they are attached
to pipes.
libstd: Change all `~fn()`s to `proc`s in the standard library.

This makes `Cell`s no longer necessary in most cases.
libextra: Remove `~fn()` from libextra.
librustc: Remove the one use of `~fn()`
librustc: Convert `~fn()` to `proc()` everywhere.
libsyntax: Remove `~fn()` from the language
auto merge of #10561 : pcwalton/rust/procify, r=alexcrichton

r? @alexcrichton
auto merge of #10542 : huonw/rust/open01, r=alexcrichton

Provide `Closed01` and `Open01` that generate directly from the
closed/open intervals from 0 to 1, in contrast to the plain impls for
f32 and f64 which generate the half-open [0,1).

Fixes #7755.
auto merge of #10557 : huonw/rust/inline-deriving, r=pcwalton

ToStr, Encodable and Decodable are not marked as such, since they're
already expensive, and lead to large methods, so inlining will bloat the
metadata & the binaries.

This means that something like

    #[deriving(Eq)]
    struct A { x: int }

creates an instance like

    #[doc = "Automatically derived."]
    impl ::std::cmp::Eq for A {
        #[inline]
        fn eq(&self, __arg_0: &A) -> ::bool {
            match *__arg_0 {
                A{x: ref __self_1_0} =>
                match *self {
                    A{x: ref __self_0_0} => true && __self_0_0.eq(__self_1_0)
                }
            }
        }
        #[inline]
        fn ne(&self, __arg_0: &A) -> ::bool {
            match *__arg_0 {
                A{x: ref __self_1_0} =>
                match *self {
                    A{x: ref __self_0_0} => false || __self_0_0.ne(__self_1_0)
                }
            }
        }
    }

(The change being the `#[inline]` attributes.)
auto merge of #10558 : alexcrichton/rust/faster-stdout, r=pcwalton,pcwalton

There are issues with reading stdin when it is actually attached to a pipe, but
I have run into no problems in writing to stdout/stderr when they are attached
to pipes.
auto merge of #10495 : alexcrichton/rust/more-native-io, r=brson

This implements a fair amount of the unimpl() functionality in io::native
relating to filesystem operations. I've also modified all io::fs tests to run in
both a native and uv environment (so everything is actually tested).

There are a few bits of remaining functionality which I was unable to get
working:

* truncate on windows
* change_file_times on windows
* lstat on windows

I think that change_file_times may just need a better interface, but the other
two have large implementations in libuv which I didn't want to tackle trying to
copy. I found a `chsize` function to work for truncate on windows, but it
doesn't quite seem to be working out.
Add generation of static libraries to rustc

This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.

When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.

Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.

Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:

* If both a .dylib and .rlib are found for a rust library, the compiler will
  prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
  overridable by explicitly saying what flavor you'd like (rlib, staticlib,
  dylib).
* If no options are passed to the command line, and no crate_type is found in
  the destination crate, then an executable is generated

With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.

This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.

Closes #552
Statically link librustrt to libstd

This commit alters the build process of the compiler to build a static
librustrt.a instead of a dynamic version. This means that we can stop
distributing librustrt as well as default linking against it in the compiler.

This also means that if you attempt to build rust code without libstd, it will
no longer work if there are any landing pads in play. The reason for this is
that LLVM and rustc will emit calls to the various upcalls in librustrt used to
manage exception handling. In theory we could split librustrt into librustrt and
librustupcall. We would then distribute librustupcall and link to it for all
programs using landing pads, but I would rather see just one librustrt artifact
and simplify the build process.

The major benefit of doing this is that building a static rust library for use
in embedded situations all of a sudden just became a whole lot more feasible.

Closes #3361
Add a new run-make test directory

This infrastructure is meant to support runnings tests that involve various
interesting interdependencies about the types of crates being linked or possibly
interacting with C libraries. The goal of these make tests is to not restrict
them to a particular test runner, but allow each test to run its own tests.

To this end, there is a new src/test/run-make directory which has sub-folders of
tests. Each test requires a `Makefile`, and running the tests constitues simply
running `make` inside the directory. The new target is `check-stageN-rmake`.

These tests will have the destination directory (as TMPDIR) and the local rust
compiler (as RUSTC) passed along to them. There is also some helpful
cross-platform utilities included in src/test/run-make/tools.mk to aid with
compiling C programs and running them.

The impetus for adding this new test suite is to allow various interesting forms
of testing rust linkage. All of the tests initially added are various flavors of
compiling Rust and C with one another as well as just making sure that rust
linkage works in general.

Closes #10434
Make -Z gen-crate-map usable for I/O

In #10422, I didn't actually test to make sure that the '-Z gen-crate-map'
option was usable before I implemented it. The crate map was indeed generated
when '-Z gen-crate-map' was specified, but the I/O factory slot was empty
because of an extra check in trans about filling in that location.

This commit both fixes that location, and checks in a "fancy test" which does
lots of fun stuff. The test will use the rustc library to compile a rust crate,
and then compile a C program to link against that crate and run the C program.
To my knowledge this is the first test of its kind, so it's a little ad-hoc, but
it seems to get the job done. We could perhaps generalize running tests like
this, but for now I think it's fine to have this sort of functionality tucked
away in a test.