Add a test for #11552

Closes #11552
std: Switch stdout/stderr to buffered by default

Similarly to #12422 which made stdin buffered by default, this commit makes the
output streams also buffered by default. Now that buffered writers will flush
their contents when they are dropped, I don't believe that there's no reason why
the output shouldn't be buffered by default, which is what you want in 90% of
cases.

As with stdin, there are new stdout_raw() and stderr_raw() functions to get
unbuffered streams to stdout/stderr.
auto merge of #12641 : sfackler/rust/issue-11552, r=huonw

Closes #11552
auto merge of #12630 : alexcrichton/rust/flush-buffered, r=brson

Now that we can call `flush()` in destructors, I think that it's appropriate for stdout/stderr to return buffered writers by default.

This doesn't enable certain functionality like a buffered stdin does, but it's what you want 90% of the time for performance reasons.
Merge pull request #12308 from kballard/vim-nested-comments

vim: Tweak how comment nesting works

Reviewed-by: brson
rustdoc: syntax highlight macro definitions, colour $... substitutions.

Macro definitions are just their raw source code, and so should be
highlighted where possible. Also, $ident non-terminal substitutions are
special, and so are worth of a little special treatment.
Merge pull request #12636 from chromatic/fixup_trans_fail

Cleaned up trans_fail(), per eddyb request.

Reviewed-by: huonw
libstd: Add some functionality to `Vec<T>`
libsyntax: Mechanically change `~[T]` to `Vec<T>`
libsyntax: Fix errors arising from the automated `~[T]` conversion
librustc: Fix errors arising from the automated `~[T]` conversion
librustdoc: Fix errors arising from the automated `~[T]` conversion
libfourcc: Fix errors arising from the automated `~[T]` conversion
rustc: Better error when loading invalid libraries

When the metadata format changes, old libraries often cause librustc to abort
when reading their metadata. This should all change with the introduction of SVH
markers, but the loader for crates should gracefully handle libraries without
SVH markers still.

This commit adds support for tripping fewer assertions when loading libraries by
using maybe_get_doc when initially parsing metadata. It's still possible for
some libraries to fall through the cracks, but this should deal with a fairly
large number of them up front.
auto merge of #12645 : alexcrichton/rust/invalid-libraries, r=brson

When the metadata format changes, old libraries often cause librustc to abort
when reading their metadata. This should all change with the introduction of SVH
markers, but the loader for crates should gracefully handle libraries without
SVH markers still.

This commit adds support for tripping fewer assertions when loading libraries by
using maybe_get_doc when initially parsing metadata. It's still possible for
some libraries to fall through the cracks, but this should deal with a fairly
large number of them up front.
auto merge of #12647 : huonw/rust/rustdoc-highlight-macros, r=alexcrichton

Macro definitions are just their raw source code, and so should be
highlighted where possible. Also, $ident non-terminal substitutions are
special, and so are worthy of a little special treatment.
librustc: add LLVM LDFLAGS to deps

This commit let librustc automatically pickup LDFLAGS dependencies
inherited from LLVM, which may otherwise result in undefined
references to external symbols under certain linking environment.

A symptom of this issue is eg. a failure when trying to link against
librustc (due to unresolved ffi_*i symbols), while using a system-wide
LLVM.

Signed-off-by: Luca Bruno <lucab@debian.org>
auto merge of #12637 : pcwalton/rust/devecing, r=alexcrichton

r? @alexcrichton
travis: remove manually added RUSTFLAGS

Indirect dependencies should now be picked up through the
autogenerated llvmdeps.rs instead.

Signed-off-by: Luca Bruno <lucab@debian.org>
auto merge of #12651 : lucab/rust/llvmdep-ldflags, r=alexcrichton

This commit let librustc automatically pickup LDFLAGS dependencies
inherited from LLVM, which may otherwise result in undefined
references to external symbols under certain linking environment.

A symptom of this issue is eg. a failure when trying to link against
librustc (due to unresolved ffi_* symbols), while using a system-wide
LLVM.

Signed-off-by: Luca Bruno <lucab@debian.org>