Add a type_id intrinsic

Closes #9913
Remove unnecessary unwind messages

Now that the type_id intrinsic is working across crates, all of these
unnecessary messages can be removed to have the failure type for a task truly be
~Any and only ~Any
Stop extra buffering when stdout isn't a tty

Right now if you're running a program with its output piped to some location and
the program decides to go awry, when you kill the program via some signal none
of the program's last 4K of output will get printed to the screen. In theory the
solution to this would be to register a signal handler as part of the runtime
which then flushes the output stream.

I believe that the current behavior is far enough from what's expected that we
shouldn't be providing this sort of "super buffering" by default when stdout
isn't attached to a tty.
Relax the constraints on a debuginfo test

The snapshot just failed due to a debuginfo test failing, and according to its
output at
http://buildbot.rust-lang.org/builders/snap3-linux/builds/564/steps/test/logs/stdio
it appears to be because the printed lines has a little less information than
the original lines were checking for. I would suspect that this is just because
of a slightly different version of gdb, but it's not that serious regardless.
auto merge of #10276 : alexcrichton/rust/fix-debug-info, r=jdm

The snapshot just failed due to a debuginfo test failing, and according to its
output at
http://buildbot.rust-lang.org/builders/snap3-linux/builds/564/steps/test/logs/stdio
it appears to be because the printed lines has a little less information than
the original lines were checking for. I would suspect that this is just because
of a slightly different version of gdb, but it's not that serious regardless.
auto merge of #10182 : alexcrichton/rust/typeid-intrinsic, r=nikomatsakis

This isn't quite as fancy as the struct in #9913, but I'm not sure we should be exposing crate names/hashes of the types. That being said, it'd be pretty easy to extend this (the deterministic hashing regardless of what crate you're in was the hard part).
Allow --cfg on rustpkg test

Closes #10238
libsyntax/librustc: Allow calling variadic foreign functions.
Add tests for variadic foreign functions.
auto merge of #10064 : luqmana/rust/vvv, r=nikomatsakis

Fixes #2057.

Example:
```Rust
#[no_std];

type c_char = u8;
type c_int = i32;
type size_t = uint;

extern {
    fn printf(format: *c_char, ...) -> c_int;
}

#[lang="fail_bounds_check"]
fn fail_bounds_check(_: *c_char, _: size_t, _: size_t, _: size_t) {}

#[start]
#[fixed_stack_segment]
fn main(_: int, _: **u8) -> int {
    unsafe {
        let msg = bytes!("Hello World!
Remove #[deriving]s on impls

They seem to have been added by accident.
auto merge of #10270 : alexcrichton/rust/no-super-buffer, r=brson

Right now if you're running a program with its output piped to some location and
the program decides to go awry, when you kill the program via some signal none
of the program's last 4K of output will get printed to the screen. In theory the
solution to this would be to register a signal handler as part of the runtime
which then flushes the output stream.

I believe that the current behavior is far enough from what's expected that we
shouldn't be providing this sort of "super buffering" by default when stdout
isn't attached to a tty.
auto merge of #10282 : sfackler/rust/rustpkg-test-cfg, r=alexcrichton

Closes #10238
auto merge of #10285 : sfackler/rust/weird-derivings, r=huonw

They seem to have been added by accident.
Move implementation for threads to Rust

This binds to the appropriate pthreads_* and Windows specific functions
and calls them from Rust. This allows for removal of the C++ support
code for threads.

Fixes #10162
auto merge of #10290 : dbussink/rust/thread_in_rust, r=alexcrichton

This binds to the appropriate pthreads_* and Windows specific functions
and calls them from Rust. This allows for removal of the C++ support
code for threads.

This needs to be reviewed for the Windows parts, I've tested on OS X and Linux.

Fixes #10162
Refactor TypeContents to be more scrutable. In particular, create coarser bits
than the current ones, which were very fine-grained.  Also, cleanly distinguish
when properties must be found in *owned* types vs *reachable* types.

Fixes #10157
Fixes #10278
Rename misleading contains_managed to owns_managed
Make TypeContents consider the type `T` to be reachable via `*T` pointers

Fixes #9509
Use loader_path instead of executable_path for osx

According to apple's documentation of rpath semantics, @executable_path means
that the path is relative the the *process executable*, not necessarily the
library in question. On the other hand, @loader_path is the path that points to
the library which contains the @loader_path reference. All of our rpath usage is
based off the library or executable, not just the executable. This means that on
OSX we should be using @loader_path instead of @executable_path to achieve the
same semantics as linux's $ORIGIN.