syntax: allow `trace_macros!` and `log_syntax!` in item position.

Previously

    trace_macros!(true)
    fn main() {}

would complain about `trace_macros` being an expression macro in item
position. This is a pointless limitation, because the macro is purely
compile-time, with no runtime effect. (And similarly for log_syntax.)

This also changes the behaviour of `trace_macros!` very slightly, it
used to be equivalent to

    macro_rules! trace_macros {
        (true $($_x: tt)*) => { true };
        (false $($_x: tt)*) => { false }
    }

I.e. you could invoke it with arbitrary trailing arguments, which were
ignored. It is changed to accept only exactly `true` or `false` (with no
trailing arguments) and expands to `()`.
native: Fix a possible deadlock in spawn

The OSX bots have been deadlocking recently in the rustdoc tests. I have only
been able to rarely reproduce the deadlock on my local setup. When reproduced,
it looks like the child process is spinning on the malloc mutex, which I
presume is locked with no other threads to unlock it.

I'm not convinced that this is what's happening, because OSX should protect
against this with pthread_atfork by default. Regardless, running as little code
as possible in the child after fork() is normally a good idea anyway, so this
commit moves all allocation to the parent process to run before the child
executes.

After running 6k iterations of rustdoc tests, this deadlocked twice before, and
after 20k iterations afterwards, it never deadlocked. I draw the conclusion that
this is either sweeping the bug under the rug, or it did indeed fix the
underlying problem.
std: Add an I/O reader method to fill a buffer

I've found a common use case being to fill a slice (not an owned vector)
completely with bytes. It's posible for short reads to happen, and if you're
trying to get an exact number of bytes then this helper will be useful.
rand: Use fill() instead of read()

It's possible for a reader to have a short read, and there's no reason the task
should fail in this scenario. By using fill(), this has a stronger guarantee
that the buffer will get filled with data.
rustc: Change the filename of compressed bitcode

Fixes #12992
Store compressed bitcode files in rlibs with a different extension. Compression doesn't interfere with --emit=bc.
Regression test compares outputs.
Make url::Url derive TotalEq.
serialize: Read/emit tuples with {read,emit}_tuple

This commit moves from {read,emit}_seq for tuples to {read,emit}_tuple, as well
as providing a generalized macro for generating these implementations from one
invocation.

Closes #13086
auto merge of #13103 : mozilla-servo/rust/url-totaleq, r=alexcrichton
auto merge of #13074 : pczarn/rust/build-rlib, r=alexcrichton

Fixes #12992

I tried to increase the number of deflate's probes. Reduction of 0.5% or 2% is not enough.
This commit cleans up a few test warnings
auto merge of #13095 : alexcrichton/rust/serialize-tuple, r=huonw

This commit moves from {read,emit}_seq for tuples to {read,emit}_tuple, as well
as providing a generalized macro for generating these implementations from one
invocation.

Closes #13086
auto merge of #13096 : sstewartgallus/rust/cleanup-test-warnings, r=huonw
Documentation sprint: Terminfo
auto merge of #12948 : olleolleolle/rust/master, r=huonw

Rust doc sprint: adding doc strings to the Terminfo library.

This is my very first Rust repository PR, so please do not hold back any formatting, nit-picky commentary. I need it.
Correct overly broad definition of `'static` kind bound.

While double-checking my understanding of the meaning of `'static`,
I made the following test program:

```rust
fn foo<X:'static>(_x: X) { }

#[cfg(not(acceptable))]
fn bar() {
    let a = 3;
    let b = &a;
    foo(b);
}

#[cfg(acceptable)]
fn bar() {
    static c : int = 4;;
    let d : &'static int = &c;
    foo(d);
}

fn main() {
    bar();
}
```

Transcript of compiling above program, illustrating that the `--cfg
acceptable` variant of `bar` compiles successfully, showing that the
`'static` kind bound only disallows non-`static` references, not *all*
references:

```
% rustc --version
/Users/fklock/opt/rust-dbg/bin/rustc 0.10-pre (caf17fe 2014-03-21 02:21:50 -0700)
host: x86_64-apple-darwin
% rustc /tmp/s.rs
/tmp/s.rs:7:5: 7:8 error: instantiating a type parameter with an incompatible type `&int`, which does not fulfill `'static`
/tmp/s.rs:7     foo(b);
                ^~~
error: aborting due to previous error
% rustc --cfg acceptable /tmp/s.rs
% ./s
%
```

(Note that the explicit type annotation on `let d : &'static int` is
necessary; it did not suffice for me to just write `let d = &'static
c;`.  That might be a latent bug, I am not sure yet.)

Anyway, a fix to the documentation seemed prudent.
auto merge of #12998 : huonw/rust/log_syntax, r=alexcrichton

syntax: allow `trace_macros!` and `log_syntax!` in item position.

Previously

    trace_macros!(true)
    fn main() {}

would complain about `trace_macros` being an expression macro in item
position. This is a pointless limitation, because the macro is purely
compile-time, with no runtime effect. (And similarly for log_syntax.)

This also changes the behaviour of `trace_macros!` very slightly, it
used to be equivalent to

    macro_rules! trace_macros {
        (true $($_x: tt)*) => { true };
        (false $($_x: tt)*) => { false }
    }

I.e. you could invoke it with arbitrary trailing arguments, which were
ignored. It is changed to accept only exactly `true` or `false` (with no
trailing arguments) and expands to `()`.
auto merge of #13113 : pnkfelix/rust/correct-static-kind-doc, r=huonw

While double-checking my understanding of the meaning of `'static`, I made the following test program:

```rust
fn foo<X:'static>(_x: X) { }

#[cfg(not(acceptable))]
fn bar() {
    let a = 3;
    let b = &a;
    foo(b);
}

#[cfg(acceptable)]
fn bar() {
    static c : int = 4;;
    let d : &'static int = &c;
    foo(d);
}

fn main() {
    bar();
}
```

Transcript of compiling above program, illustrating that the `--cfg acceptable` variant of `bar` compiles successfully, showing that the`'static` kind bound only disallows non-`static` references, not *all* references:

```
% rustc --version
/Users/fklock/opt/rust-dbg/bin/rustc 0.10-pre (caf17fe 2014-03-21 02:21:50 -0700)
host: x86_64-apple-darwin
% rustc /tmp/s.rs
/tmp/s.rs:7:5: 7:8 error: instantiating a type parameter with an incompatible type `&int`, which does not fulfill `'static`
/tmp/s.rs:7     foo(b);
                ^~~
error: aborting due to previous error
% rustc --cfg acceptable /tmp/s.rs
% ./s
%
```

(Note that the explicit type annotation on `let d : &'static int` is necessary; it did not suffice for me to just write `let d = &'static c;`. That might be a latent bug, I am not sure yet.)

Anyway, a fix to the documentation seemed prudent.
auto merge of #13049 : alexcrichton/rust/io-fill, r=huonw

This method can be used to fill a byte slice of data entirely, and it's considered an error if any error happens before its entirely filled.
auto merge of #13080 : alexcrichton/rust/possible-osx-deadlock, r=brson

The OSX bots have been deadlocking recently in the rustdoc tests. I have only
been able to rarely reproduce the deadlock on my local setup. When reproduced,
it looks like the child process is spinning on the malloc mutex, which I
presume is locked with no other threads to unlock it.

I'm not convinced that this is what's happening, because OSX should protect
against this with pthread_atfork by default. Regardless, running as little code
as possible in the child after fork() is normally a good idea anyway, so this
commit moves all allocation to the parent process to run before the child
executes.

After running 6k iterations of rustdoc tests, this deadlocked twice before, and
after 20k iterations afterwards, it never deadlocked. I draw the conclusion that
this is either sweeping the bug under the rug, or it did indeed fix the
underlying problem.