LLVM_LIBDIR_<triple> is only defined for host triples, not target triples.

FWIW, the same is true for LLVM_STDCPP_RUSTFLAGS_<triple>, where we
explicitly define it as empty when --enable-llvm-static-stdcpp is not
specified, but it's still undefined for cross-compiled triples.

It wasn't clear to me that early_error was correct here, but it seems to
work. This code is reachable from `rustdoc`, which is problematic, because
early_error panics. rustc handles the panics gracefully (without ICEing or
crashing), but rustdoc does not. It's not the first such rustdoc problem,
though:

    $ rustdoc hello.rs --extern std=bad-std
    error: extern location for std does not exist: bad-std
    hello.rs:1:1: 1:1 error: can't find crate for `std`
    hello.rs:1
           ^
    error: aborting due to 2 previous errors
    thread '<unnamed>' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:151
    thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "rustc failed"', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:744
    thread '<main>' panicked at 'child thread None panicked', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/thread.rs:661

LLVM older that 3.6 has a bug that cause assertions when compiling certain
constructs. For 3.5 there's still a chance that the bug might get fixed
in 3.5.2, so let's keep allowing to compile with it for it for now.

In case that there is a destination for the array, like in
"let x = [expr; n]", we currently don't evaluate the given expression if
n is zero. That's inconsistent with all other cases, including "[expr;
0]" without a destination.

Fixes rust-lang#23354

Now that `old_io` is deprecated and `std::io` is stable, we should stop
recommending the use of `old_io` in the module documentation.

std::io does not currently expose the stdin_raw, stdout_raw, or
stderr_raw functions. According to the current plans for stdio (see RFC
rust-lang#517), raw access will likely be provided using the platform-specific
std::os::{unix,windows} modules. At the moment we don't expose any way
to do this. As such, delete all mention of the _raw functions from the
stdin/stdout/stderr function documentation.

While we're at it, remove a few `pub`s from items that aren't exposed.
This is done just to lessen the confusion experienced by anyone who
looks at the source in an attempt to find the _raw functions.

 Previously it would fail on a trivial case like

    /// Summary line
    /// <trailing space>
    /// Regular content

Compliant markdown preprocessor would render that as two separate paragraphs, but our summary line
extractor interprets both lines as the same paragraph and includes both into the short summary resulting in
![screenshot from 2015-03-13 22 47 08](https://cloud.githubusercontent.com/assets/679122/6648596/7ef792b2-c9e4-11e4-9c19-704c288ec4de.png)

 non_camel_case_types lint suggests `ONETWOTHREE` for non-camel type `ONE_TWO_THREE`, which doesn't look good.
This patch fixes it.

…chton

 This change closes rust-lang#23303 by rejecting an empty search path.

 LLVM older that 3.6 has a bug that cause assertions when compiling certain
constructs. For 3.5 there's still a chance that the bug might get fixed
in 3.5.2, so let's keep allowing to compile with it for it for now.

 There was a minor typo in the book's concurrency section (\"recieve\" instead of \"receive\").

 [expr; 0] currently exhibits inconsistent behaviour and [expr; n] with n > 1 triggers an LLVM assertion in case that \"expr\" diverges.

…book, r=steveklabnik

 It was using tabs.

…r, r=steveklabnik

   "body": null,

r? @Manishearth

…on-from-io, r=huonw

Now that `old_io` is deprecated and `std::io` is stable, we should stop
recommending the use of `old_io` in the module documentation.

…nstructors, r=alexcrichton

`std::io` does not currently expose the `stdin_raw`, `stdout_raw`, or
`stderr_raw` functions. According to the current plans for stdio (see
rust-lang/rfcs#517), raw access will likely be provided using the
platform-specific `std::os::{unix,windows}` modules. At the moment we
don't expose any way to do this. As such, delete all mention of the
`*_raw` functions from the `stdin`/`stdout`/`stderr` function
documentation.

While we're at it, remove a few `pub`s from items that aren't exposed.
This is done just to lessen the confusion experienced by anyone who
looks at the source in an attempt to find the `*_raw` functions.

This changed `an String` to `a String`. Very minor change!

The usage of `an String` was introduced in rust-lang@a828e79#diff-b596503c7c33ce457b6d047e351ac12bR423, which changed `an OsString` to `an String`.