auto merge of #10676 : eddyb/rust/ast-box-in-enums, r=cmr

**Note**: I only tested on top of my #10670 PR, size reductions come from both change sets.

With this, [more enums are shrinked](https://gist.github.com/eddyb/08fef0dfc6ff54e890bc), the most significant one being `ast_node`, from 104 bytes (master) to 96 (#10670) and now to 32 bytes.

My own testcase requires **200MB** less when compiling (not including the other **200MB** gained in #10670), and rustc-stage2 is down by about **130MB**.

I believe there is more to gain by fiddling with the enums' layouts.

auto merge of #10746 : alexcrichton/rust/fix-make-install, r=cmr

It was only copying the host files, not the target rlib files.

auto merge of #10739 : DaGenix/rust/mut-chunks, r=alexcrichton

mut_chunks() returns an iterator that produces mutable slices. This is the mutable version of the existing chunks() method on the ImmutableVector trait.

EDIT: This uses only safe code now.

PREVIOUSLY:
I tried to get this working with safe code only, but I couldn't figure out how to make that work. Before #8624, the exact same code worked without the need for the transmute() call. With that fix and without the transmute() call, the compiler complains about the call to mut_slice(). I think the issue is that the mutable slice that is returned will live longer than the self parameter since the self parameter doesn't have an explicit lifetime. However, that is the way that the Iterator trait defines the next() method. I'm sure there is a good reason for that, although I don't quite understand why. Anyway, I think the interface is safe, since the MutChunkIter will only hand out non-overlapping pointers and there is no way to get it to hand out the same pointer twice.

Fix make install to install rlib files

It was only copying the host files, not the target rlib files.

auto merge of #10733 : alexcrichton/rust/ignore-on-windows, r=pcwalton

I've seen this fail on windows twice now, and it's not clear to me why it's
failing. For now, ignore it on that platform while investigation enuses.

auto merge of #10738 : sfackler/rust/buffered-fixes, r=alexcrichton

BufferedWriter::inner flushes before returning the underlying writer.

BufferedWriter::write no longer flushes the underlying writer.

LineBufferedWriter::write flushes up to the *last* newline in the input
string, not the first.

Implement DoubleEndedIterator for MutChunkIter.

Implement mut_chunks() method for MutableVector trait.

mut_chunks() returns an iterator that produces mutable slices. This is the
mutable version of the existing chunks() method on the ImmutableVector trait.

auto merge of #10731 : chris-morgan/rust/fix-double-slashing, r=metajack

CFG_BUILD_DIR, CFG_LLVM_SRC_DIR and CFG_SRC_DIR all have trailing
slashes, by definition, so this is correct.

(This is purely cosmetic; the doubled slash is ignored by all the tools we're using.)

auto merge of #10528 : alexcrichton/rust/static-linking-v2, r=pcwalton

In this series of commits, I've implemented static linking for rust. The scheme I implemented was the same as my [mailing list post](https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html).

The commits have more details to the nitty gritty of what went on. I've rebased this on top of my native mutex pull request (#10479), but I imagine that it will land before this lands, I just wanted to pre-emptively get all the rebase conflicts out of the way (becuase this is reorganizing building librustrt as well).

Some contentious points I want to make sure are all good:

* I've added more "compiler chooses a default" behavior than I would like, I want to make sure that this is all very clearly outlined in the code, and if not I would like to remove behavior or make it clearer.
* I want to make sure that the new "fancy suite" tests are ok (using make/python instead of another rust crate)

If we do indeed pursue this, I would be more than willing to write up a document describing how linking in rust works. I believe that this behavior should be very understandable, and the compiler should never hinder someone just because linking is a little fuzzy.

Test fixes and merge conflicts

Box Block, fn_decl, variant and Ty in the AST, as they were inflating critical enum sizes.

auto merge of #10737 : huonw/rust/with-cap, r=alexcrichton

This allows one to reduce the number of reallocs of the internal buffer
if one has an approximate idea of the size of the final output.

Fixes for BufferedWriter and LineBufferedWriter

BufferedWriter::inner flushes before returning the underlying writer.

BufferedWriter::write no longer flushes the underlying writer.

LineBufferedWriter::write flushes up to the *last* newline in the input
string, not the first.

auto merge of #10727 : erickt/rust/json, r=huonw

This PR does some small modernizations to the json library. First is to remove the `@` boxes, second is to rename the constructors to `new`.

std::io::mem: add a with_capacity constructor to MemWriter.

This allows one to reduce the number of reallocs of the internal buffer
if one has an approximate idea of the size of the final output.

auto merge of #10735 : alexcrichton/rust/issue-10734, r=cmr

Turns out `with_scope` already translates destructors, so by manually
translating destructors we end up running them all twice (bad).

Closes #10734

auto merge of #10722 : cmr/rust/type_id_opaque, r=alexcrichton

Closes #10594

Don't run cleanups twice in "if true" blocks

Turns out `with_scope` already translates destructors, so by manually
translating destructors we end up running them all twice (bad).

Closes #10734

Wrap the return value of the type_id intrinsic in an opaque box

Closes #10594

Ignore a deque test on windows

I've seen this fail on windows twice now, and it's not clear to me why it's
failing. For now, ignore it on that platform while investigation enuses.

extra: missed a couple `@` in json

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.

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

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 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

Fix double slashes in make paths.

CFG_BUILD_DIR, CFG_LLVM_SRC_DIR and CFG_SRC_DIR all have trailing
slashes, by definition, so this is correct.

auto merge of #10719 : Kimundi/rust/switch_to_multi_item_macros, r=alexcrichton

- Removed module reexport workaround for the integer module macros
- Removed legacy reexports of `cmp::{min, max}` in the integer module macros
- Combined a few macros in `vec` into one
- Documented a few issues

auto merge of #10678 : alexcrichton/rust/issue-4877, r=pcwalton

This adds an implementation of the Chase-Lev work-stealing deque to libstd
under std::rt::deque. I've been unable to break the implementation of the deque
itself, and it's not super highly optimized just yet (everything uses a SeqCst
memory ordering).

The major snag in implementing the chase-lev deque is that the buffers used to
store data internally cannot get deallocated back to the OS. In the meantime, a
shared buffer pool (synchronized by a normal mutex) is used to
deallocate/allocate buffers from. This is done in hope of not overcommitting too
much memory. It is in theory possible to eventually free the buffers, but one
must be very careful in doing so.

I was unable to get some good numbers from src/test/bench tests (I don't think
many of them are slamming the work queue that much), but I was able to get some
good numbers from one of my own tests. In a recent rewrite of select::select(),
I found that my implementation was incredibly slow due to contention on the
shared work queue. Upon switching to the parallel deque, I saw the contention
drop to 0 and the runtime go from 1.6s to 0.9s with the most amount of time
spent in libuv awakening the schedulers (plus allocations).

Closes #4877

Implement a lock-free work-stealing deque

This adds an implementation of the Chase-Lev work-stealing deque to libstd
under std::rt::deque. I've been unable to break the implementation of the deque
itself, and it's not super highly optimized just yet (everything uses a SeqCst
memory ordering).

The major snag in implementing the chase-lev deque is that the buffers used to
store data internally cannot get deallocated back to the OS. In the meantime, a
shared buffer pool (synchronized by a normal mutex) is used to
deallocate/allocate buffers from. This is done in hope of not overcommitting too
much memory. It is in theory possible to eventually free the buffers, but one
must be very careful in doing so.

I was unable to get some good numbers from src/test/bench tests (I don't think
many of them are slamming the work queue that much), but I was able to get some
good numbers from one of my own tests. In a recent rewrite of select::select(),
I found that my implementation was incredibly slow due to contention on the
shared work queue. Upon switching to the parallel deque, I saw the contention
drop to 0 and the runtime go from 1.6s to 0.9s with the most amount of time
spent in libuv awakening the schedulers (plus allocations).

Closes #4877

Removed module macro workaround for signed and unsigned integers

Removed useless cmp::{min, max} reexports from the integer modules

extra: json::Encoder should take a &mut io::Writer

extra: Rename json constructors into *::init

Remove some unnecessary impls from json

Remove @ from json::Error

auto merge of #10697 : pcwalton/rust/path-new, r=pcwalton

r+

(carrying over from @alexcrichton's review)

libstd: Change `Path::new` to `Path::init`.

auto merge of #10726 : pnkfelix/rust/fsk-remove-at-fn-artifact, r=thestinger

While tracking down how this function became dead, identified a spot
(@fn cannot happen) where we probably would prefer to ICE rather than
pass silently; so added fail! invocation.

Removed some dead code.

While tracking down how this function became dead, identified a spot
(@fn cannot happen) where we probably would prefer to ICE rather than
pass silently; so added fail! invocation.

Removed a few macro-expanding-to-module workarounds

Also documented a few issues

auto merge of #10715 : alexcrichton/rust/fix-log-twice, r=huonw

It may mislead you into thinking tasks are spawning twice, when in fact they are
not.

Fix initial debug statements printing twice

It may mislead you into thinking tasks are spawning twice, when in fact they are
not.

auto merge of #10709 : alexcrichton/rust/snapshot, r=pcwalton

Register new snapshots

auto merge of #10704 : TeXitoi/rust/spectralnorm-resurected, r=alexcrichton

shootout-spectralnorm resurection with parallelization

auto merge of #10519 : nikomatsakis/rust/issue-8624-borrowck-overly-permissive, r=pnkfelix

See #8624 for details.

r? @pnkfelix

Test that reborrowing contents of an `&'a mut &'b mut` pointer can only
be done for at most lifetime `'a`

Fixes #8624

Modify iterators to make them safe with the new rules.

auto merge of #10694 : klutzy/rust/rustdoc-closure, r=alexcrichton

auto merge of #10691 : g3xzh/rust/benchm, r=cmr

I have written some benchmark tests to `push`, `push_many`, `join`,
`join_many` and `ends_with_path`.

Let me know what you think (@cmr).
Thanks in advance.

auto merge of #10687 : alexcrichton/rust/issue-10686, r=thestinger

Turns out android doesn't support LLVM's thread_local attribute and accompanying
implementation.

Closes #10686

auto merge of #10621 : Florob/rust/unicode63, r=cmr

This update the unicode.rs file to the latest Unicode version released 2013-09-30.

auto merge of #10642 : cmr/rust/strict_doccomment, r=alexcrichton

Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.

Also update the manual for these changes, and modernify the EBNF for comments.

Closes #10638

Be more strict about doc comments

Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.

Also update the manual for these changes, and modernify the EBNF for comments.

Closes #10638

Fix handling of upper/lowercase, and whitespace

Update Unicode data to version 6.3

Update unicode.py to reflect language changes

auto merge of #10680 : alexcrichton/rust/relax-feature-gate, r=thestinger

Instead of forcibly always aborting compilation, allow usage of
 #[warn(unknown_features)] and related lint attributes to selectively abort
 compilation. By default, this lint is deny.

Use the native tls implementation on android

Turns out android doesn't support LLVM's thread_local attribute and accompanying
implementation.

Closes #10686

auto merge of #10685 : ebiggers/rust/ascii_fixes, r=alexcrichton

is_digit() incorrectly returned false for '0'.
is_control() incorrectly returned true for ' ' (space).

auto merge of #10662 : alexcrichton/rust/thread-detach, r=pcwalton

This has one commit from a separate pull request (because these commits depend on that one), but otherwise the extra details can be found in the commit messages. The `rt::thread` module has been generally cleaned up for everyday safe usage (and it's a bug if it's not safe).

Relax restrictions on unknown feature directives

Instead of forcibly always aborting compilation, allow usage of
 #[warn(unknown_features)] and related lint attributes to selectively abort
 compilation. By default, this lint is deny.

Improve the rt::thread module

* Added doc comments explaining what all public functionality does.
* Added the ability to spawn a detached thread
* Added the ability for the procs to return a value in 'join'

rustdoc: Use new ||/proc syntax

auto merge of #10693 : eddyb/rust/freeze-ast, r=thestinger

It's truly immutable now, which will allow us to remove some cloning in the parser and box parts of the AST in `Rc<T>` (if desired).

std::ascii:  Add tests for is_digit() and is_control()

Freeze the AST by removing a couple of unused @mut ~[T] from token_tree.

auto merge of #10684 : jld/rust/unstruct-unhack-typekind, r=alexcrichton

auto merge of #10688 : bjz/rust/recv_iter, r=brson

I've noticed I use this pattern quite a bit:

~~~rust
do spawn {
    loop {
        match port.try_recv() {
            Some(x) => ...,
            None => ...,
        }
    }
}
~~~

The `RecvIterator`, returned from a default `recv_iter` method on the `GenericPort` trait, allows you to reduce this down to:

~~~rust
do spawn {
    for x in port.recv_iter() {
        ...
    }
}
~~~

As demonstrated in the tests, you can also access the port from within the `for` block for further `recv`ing and `peek`ing with no borrow errors, which is quite nice.

Add benchmark tests to path/posix

I have written some benchmark tests to `push`, `push_many`, `join`,
`join_many` and `ends_with_path`.

auto merge of #10670 : eddyb/rust/node-u32, r=alexcrichton

### Rationale
There is no reason to support more than 2³² nodes or names at this moment, as compiling something that big (even without considering the quadratic space usage of some analysis passes) would take at least **64GB**.
Meanwhile, some can't (or barely can) compile rustc because it requires almost **1.5GB**.

### Potential problems
Can someone confirm this doesn't affect metadata (de)serialization? I can't tell myself, I know nothing about it.

### Results
Some structures have a size reduction of 25% to 50%: [before](https://gist.github.com/luqmana/3a82a51fa9c86d9191fa) - [after](https://gist.github.com/eddyb/5a75f8973d3d8018afd3).
Sadly, there isn't a massive change in the memory used for compiling stage2 librustc (it doesn't go over **1.4GB** as [before](http://huonw.github.io/isrustfastyet/mem/), but I can barely see the difference).
However, my own testcase (previously peaking at **1.6GB** in typeck) shows a reduction of **200**-**400MB**.

Clean up statically initialized data on shutdown

Whenever the runtime is shut down, add a few hooks to clean up some of the
statically initialized data of the runtime. Note that this is an unsafe
operation because there's no guarantee on behalf of the runtime that there's no
other code running which is using the runtime.

This helps turn down the noise a bit in the valgrind output related to
statically initialized mutexes. It doesn't turn the noise down to 0 because
there are still statically initialized mutexes in dynamic_lib and
os::with_env_lock, but I believe that it would be easy enough to add exceptions
for those cases and I don't think that it's the runtime's job to go and clean up
that data.

Add an iterator for receiving messages from GenericPorts

Shink NodeId, CrateNum, Name and Mrk down to 32 bits on x64.

auto merge of #10679 : alexcrichton/rust/no-routine, r=pcwalton

std::ascii:  Fix is_digit() and is_control()

is_digit() incorrectly returned false for '0'.
is_control() incorrectly returned true for ' ' (space).

Remove enum struct return workaround from LLVM bindings.

auto merge of #10677 : jld/rust/type-enum-discrim-rm, r=alexcrichton

Remove unused std::routine

auto merge of #10649 : sfackler/rust/multi-macro, r=alexcrichton

The majority of this change is modifying some of the `ast_visit` methods to return multiple values.

It's prohibitively expensive to allocate a `~[Foo]` every time a statement, declaration, item, etc is visited, especially since the vast majority will have 0 or 1 elements. I've added a `SmallVector` class that avoids allocation in the 0 and 1 element cases to take care of that.

Clean up SmallVector use a bit

Support multiple item macros

Closes #4375

Add SmallVector to libsyntax

auto merge of #10312 : thestinger/rust/thread_local, r=alexcritchton

This provides a building block for fast thread-local storage. It does
not change the safety semantics of `static mut`.

Closes #10310

auto merge of #10581 : pcwalton/rust/dedo, r=pcwalton

r? @alexcrichton

add a thread_local feature gate

port the runtime to `#[thread_local]`

add `#[thread_local]` attribute

This provides a building block for fast thread-local storage. It does
not change the safety semantics of `static mut`.

Closes #10310

librustc: Fix merge fallout.

auto merge of #10673 : klutzy/rust/quite, r=alexcrichton

Remove the unused obsolete enum_discrim type.

auto merge of #10664 : alexcrichton/rust/issue-10663, r=luqmana

It turns out that libuv was returning ENOSPC to us in our usage of the
uv_ipX_name functions. It also turns out that there may be an off-by-one in
libuv. For now just add one to the buffer size and handle the return value
correctly.

Closes #10663

Correctly handle libuv errors in addrinfo calls

It turns out that libuv was returning ENOSPC to us in our usage of the
uv_ipX_name functions. It also turns out that there may be an off-by-one in
libuv. For now just add one to the buffer size and handle the return value
correctly.

Closes #10663

libstd: Fix Win32 and other bustage.

librustc: Make `||` lambdas not infer to `proc`s

test: Remove all remaining non-procedure uses of `do`.

test: Remove non-procedure uses of `do` from compiletest, libstd tests,
compile-fail tests, run-fail tests, and run-pass tests.

librustc: Remove non-procedure uses of `do` from librustc, librustdoc,
and librustpkg.