Handle inline asm outputs as write-only in liveness, borrowck and trans.
auto merge of #9922 : alexcrichton/rust/less-sys, r=thestinger

More progress on #2240
Fix starts_with() and ends_with().

d4a32386f3b6 broke these since slice_to() and slice_from() must get character
boundaries, and arbitrary needle lengths don't necessarily map to character
boundaries of the haystack.

This also adds new tests that would have caught this bug.
auto merge of #9850 : eddyb/rust/inline-asm-constraints, r=luqmana

I've implemented analysis support for the [GCC '=' write-only inline asm constraint modifier](http://gcc.gnu.org/onlinedocs/gcc/Modifiers.html). I had more changes, for '+' (read+write) as well, but it turns out LLVM doesn't support '+' at all.

I've removed the need for wrapping each output in ExprAddrOf, as that would require unwrapping almost everywhere and it was harder to reason about in borrowck than ExprAssign's LHS.

With this change, rustc will treat (in respect to validity of accessing a local) code like this:
```rust
let x: int;
unsafe {
    asm!("mov $1, $0" : "=r"(x) : "r"(5u));
}
```
as if it were this:
```rust
let x : int;
x = 5;
```

Previously, the local was required to be both mutable and initialized, and the write effect wasn't recorded.
auto merge of #9924 : metajack/rust/fix-starts-with-ends-with, r=huonw

d4a32386f3b6 broke these since slice_to() and slice_from() must get character
boundaries, and arbitrary needle lengths don't necessarily map to character
boundaries of the haystack.

This also adds new tests that would have caught this bug.
Made `std::task::TaskBuilder::future_result()` easier to use
auto merge of #9926 : Kimundi/rust/future_result_bad_sig, r=huonw
Fix extra::url::to_str to include the port.

Fixes #9451.
Fixes chris-morgan/rust-http#16.
Update prelude items in Vim syntax.
Highlight \0 in strings and chars in Vim.
auto merge of #9927 : chris-morgan/rust/fix-url-to_str-so-it-includes-the-port, r=huonw

Fixes #9451.
Fixes chris-morgan/rust-http#16.
auto merge of #9929 : chris-morgan/rust/2013-10-19-vim-updates, r=sanxiyn

- Update prelude items specially highlighted.
- Highlight `
Optimize include_bin! for large inputs

Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test

    before:
        time: 469s
        memory: 6GB
        assertion failure in LLVM (section too large)

    after:
        time: 2.50s
        memory: 124MB

Closes #2598
Fix an off-by-one in managed::refcount

This fixes a bug I accidentally introduced in #9922
auto merge of #9851 : alexcrichton/rust/include_bin, r=huonw

Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test

    before:
        time: 469s
        memory: 6GB
        assertion failure in LLVM (section too large)

    after:
        time: 2.50s
        memory: 124MB

Closes #2598
Remove jemalloc from the runtime

As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.

Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.

Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.

Closes #9925
auto merge of #9930 : alexcrichton/rust/refcount-tests, r=thestinger

This fixes a bug I accidentally introduced in #9922
Make fields in std::comm private
auto merge of #9935 : reedlepee123/rust/my_new_branch, r=bstrie
auto merge of #9933 : alexcrichton/rust/no-jemalloc, r=brson

As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.

Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.

Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.

Closes #9925