rustpkg: Build dependencies into the correct workspace when using --rust-path-hack

When invoked with the --rust-path-hack flag, rustpkg was correctly building
the package into the default workspace (and not into the build/ subdirectory of the
parent directory of the source directory), but not correctly putting the output
for any dependencies into the default workspace as well.

Spotted by Jack.
mark bounds check failures as the cold path

LLVM is unable to determine this for most cases.

http://llvm-reviews.chandlerc.com/D2034 needs to land upstream before
this is going to have an effect. It's harmless to start generating the
expect hint now.
syntax: remove dead @mut Visitor impl (only used in tests).

Also, move some code only uses in the tests into the test module, and
replace some needless @mut ~[] with plain ~[].
Handle another possible error in a unix pipe test

This cropped up on the bsd bot, and if it's an error that gets thrown then it's
fine to just whitelist another type of error in the test.
add support for the `cold` function attribute

This allows a function to marked as infrequently called, resulting in
any branch calling it to be considered colder.
Make some more rt components public

Primarily this makes the Scheduler and all of its related interfaces public. The
reason for doing this is that currently any extern event loops had no access to
the scheduler at all. This allows third-party event loops to manipulate the
scheduler, along with allowing the uv event loop to live inside of its own
crate.
auto merge of #10110 : catamorphism/rust/rustpkg-dependency-build-dir, r=metajack

r? @metajack When invoked with the --rust-path-hack flag, rustpkg was correctly building
the package into the default workspace (and not into the build/ subdirectory of the
parent directory of the source directory), but not correctly putting the output
for any dependencies into the default workspace as well.

Spotted by Jack.
auto merge of #10113 : thestinger/rust/expect, r=cmr

LLVM is unable to determine this for most cases.

http://llvm-reviews.chandlerc.com/D2034 needs to land upstream before
this is going to have an effect. It's harmless to start generating the
expect hint now.
Register new snapshots
auto merge of #10133 : alexcrichton/rust/another-error, r=thestinger

This cropped up on the bsd bot, and if it's an error that gets thrown then it's
fine to just whitelist another type of error in the test.
auto merge of #10117 : huonw/rust/dead-visits, r=sanxiyn

Used nowhere, and these are likely incorrect anyway: self needs to be
dereferenced once more otherwise the method calls will be reusing the
current impl... bam! Infinite recursion.
rt::task: Make current_stack_segment public again

This was done in 2145de8c and reverted in 0ada7c7f, but Servo needs it.

Closes #10065.
auto merge of #10127 : thestinger/rust/cold, r=pcwalton

This allows a function to marked as infrequently called, resulting in
any branch calling it to be considered colder.
Field identifiers now include specific spans (Closes #8263).
#8263 part 2: Adding struct name.
auto merge of #10135 : alexcrichton/rust/snapshots, r=thestinger

Plus some migration from `let mut this = self` to `mut self` (yay!)
auto merge of #10141 : kmcallister/rust/current_stack_segment, r=alexcrichton

This was done in 2145de8c and reverted in 0ada7c7f, but Servo needs it.

Closes #10065.

r? @brson
auto merge of #10142 : pythonesque/rust/issue-8263, r=catamorphism

This is, I think, the minimal change required.  I would have included a test but as far as I can tell there is currently no way to precisely test that the span for an error underlines the correct word.  I did verify it manually.
Move rust's uv implementation to its own crate

There are a few reasons that this is a desirable move to take:

1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable

Here's a quick summary of the points of this pull request which make this
possible:

* Two new lang items were introduced: event_loop, and event_loop_factory.
  The idea of a "factory" is to define a function which can be called with no
  arguments and will return the new event loop as a trait object. This factory
  is emitted to the crate map when building an executable. The factory doesn't
  have to exist, and when it doesn't then an empty slot is in the crate map and
  a basic event loop with no I/O support is provided to the runtime.

* When building an executable, then the rustuv crate will be linked by default
  (providing a default implementation of the event loop) via a similar method to
  injecting a dependency on libstd. This is currently the only location where
  the rustuv crate is ever linked.

* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
  implicitly linking to rustuv by default

Closes #5019
auto merge of #10058 : alexcrichton/rust/uv-crate, r=brson

This is one of the final steps needed to complete #9128. It still needs a little bit of polish before closing that issue, but it's in a pretty much "done" state now.

The idea here is that the entire event loop implementation using libuv is now housed in `librustuv` as a completely separate library. This library is then injected (via `extern mod rustv`) into executable builds (similarly to how libstd is injected, tunable via `#[no_uv]`) to bring in the "rust blessed event loop implementation."

Codegen-wise, there is a new `event_loop_factory` language item which is tagged on a function with 0 arguments returning `~EventLoop`. This function's symbol is then inserted into the crate map for an executable crate, and if there is no definition of the `event_loop_factory` language item then the value is null.

What this means is that embedding rust as a library in another language just got a little harder. Libraries don't have crate maps, which means that there's no way to find the event loop implementation to spin up the runtime. That being said, it's always possible to build the runtime manually. This request also makes more runtime components public which should probably be public anyway. This new public-ness should allow custom scheduler setups everywhere regardless of whether you follow the `rt::start `path.