Typeck: Disallow scalar casts to bare_fn.

Bare functions are another example of a scalar but non-numeric
type (like char) that should be handled separately in casts.
This disallows expressions like `0 as extern "Rust" fn() -> int;`.

It might be advantageous to allow casts between bare functions
and raw pointers in unsafe code in the future, to pass function
pointers between Rust and C.

Closes #8728
Refine privacy error messages to be more accurate

This stops labeling everything as "is private" when in fact the destination may
be public. Instead, the clause "is inaccessible" is used and the private part of
the flag is called out with a "is private" message.

Closes #9793
Update prelude items in Vim syntax.
Highlight \0 in strings and chars in Vim.
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
Document traits and Default about format! better

Closes #9865
Closes #9808
Remove the fmt! syntax extension

It lived a good life, but its time has come. The groundwork is set for the
official transition after the next snapshot (removal of XXX2 macros)
auto merge of #9856 : alexcrichton/rust/privacy-errors, r=huonw

This stops labeling everything as "is private" when in fact the destination may
be public. Instead, the clause "is inaccessible" is used and the private part of
the flag is called out with a "is private" message.

Closes #9793
rustdoc: Strip methods correctly based on privacy

Beforehand the id of a method was the id of the 'self' argument, but this is not
the id which privacy was using (the id of the ast::method) struct, so by moving
the ids over to the privacy-target ones the methods are now stripped correctly.
auto merge of #9919 : alexcrichton/rust/fmt-begone, r=huonw

It lived a good life, but its time has come. The groundwork is set for the
official transition after the next snapshot (removal of XXX2 macros)
rustpkg: Make rustpkg tests stop comparing dates

Instead of scrutinizing modification times in rustpkg tests,
change output files to be read-only and detect attempts to write
to them (hack suggested by Jack). This avoids time granularity problems.

As part of this change, I discovered that some dependencies weren't
getting written correctly (involving built executables and library
files), so this patch fixes that too.

This partly addresses #9441, but one test (test_rebuild_when_needed)
is still ignored on Linux.
rustc: Check that the output file is writeable before linking

This is because on Linux, the linker will silently overwrite
a read-only file.