r? @alexcrichton cc @vhbit

It is a frequent pattern among I/O functions to take `P: AsPath + ?Sized` or
`AsOsStr` instead of `AsPath`. Most of these functions do not need to take
ownership of their argument, but for libraries in general it's much more
ergonomic to not deal with `?Sized` at all and simply require an argument `P`
instead of `&P`.

This change is aimed at removing unsightly `?Sized` bounds while retaining the
same level of usability as before. All affected functions now take ownership of
their arguments instead of taking them by reference, but due to the forwarding
implementations of `AsOsStr` and `AsPath` all code should continue to work as it
did before.

This is strictly speaking a breaking change due to the signatures of these
functions changing, but normal idiomatic usage of these APIs should not break in
practice.

[breaking-change]

`sys/ttycom.h` in both:
`#define TIOCGWINSZ  _IOR('t', 104, struct winsize)  /* get window size */`

It is a frequent pattern among I/O functions to take `P: AsPath + ?Sized` or
`AsOsStr` instead of `AsPath`. Most of these functions do not need to take
ownership of their argument, but for libraries in general it's much more
ergonomic to not deal with `?Sized` at all and simply require an argument `P`
instead of `&P`.

This change is aimed at removing unsightly `?Sized` bounds while retaining the
same level of usability as before. All affected functions now take ownership of
their arguments instead of taking them by reference, but due to the forwarding
implementations of `AsOsStr` and `AsPath` all code should continue to work as it
did before.

This is strictly speaking a breaking change due to the signatures of these
functions changing, but normal idiomatic usage of these APIs should not break in
practice.

[breaking-change]

r? @Manishearth

   "body": null,

 It was using tabs.

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

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

 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.

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

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

 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)

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)

The arity of `ref x` is always 1, so it needs to be dereferenced before being compared with some other type whose arity is not 1.

Fixes #23009.

This adds search by type (for functions/methods) support to Rustdoc. Target issue is at https://github.com/rust-lang/rfcs/issues/658.

I've described my approach here: https://github.com/rust-lang/rfcs/issues/658#issuecomment-76484200. I'll copy the text in here as well:

---

Hi, it took me longer than I wished, but I have implemented this in a not-too-complex way that I think can be extended to support more complex features (like the ones mentioned [here](https://github.com/rust-lang/rust/issues/12866#issuecomment-66945317)).

The idea is to generate a JSON representation of the types of methods/functions in the existing index, and then make the JS understand when it should look by type (and not by name).

I tried to come up with a JSON representation that can be extended to support generics, bounds, ref/mut annotations and so on. Here are a few samples:

Function:

```rust
fn to_uppercase(c: char) -> char
```

```json
{
    "inputs": [
        {"name": "char"}
    ],
    "output": {
        "name": "char",
    }
}
```

Method (implemented or defined in trait):

```rust
// in struct Vec
// self is considered an argument as well
fn capacity(&self) -> usize
```

```json
{
    "inputs": [
        {"name": "vec"}
    ],
    "output": {
        "name": "usize"
    }
}
```

This simple format can be extended by adding more fields, like `generic: bool`, a `bounds` mapping and so on.

I have a working implementation in https://github.com/rust-lang/rust/compare/master...mihneadb:rustdoc-search-by-type. You can check out a live demo [here](http://data.mihneadb.net/doc/std/index.html?search=charext%20-%3E%20char).

![screenshot from 2015-02-28 00 54 00](https://cloud.githubusercontent.com/assets/643127/6422722/7e5374ee-bee4-11e4-99a6-9aac3c9d5068.png)


The feature list is not that long:
- search by types (you *can* use generics as well, as long as you use the exact name - e.g. [`vec,t -> `](http://data.mihneadb.net/doc/std/index.html?search=vec%2C%20t%20-%3E))
- order of arguments does not matter
- `self` is took into account as well (e.g. search for `vec -> usize`)
- does not use "complex" annotations (e.g. you don't search for `&char -> char` but for `char -> char`)

My goal is to get a working, minimal "base" merged so that others can build upon it. How should I proceed? Do I open a PR (badly in need of code review since this is my first non "hello world"-ish rust code)?

---

Oops, merged #21468 by accident.

The arity of `ref x` is always 1, so it needs to be dereferenced before
being compared with some other type whose arity is not 1.

Fixes #23009.

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 #23354

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.

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 would interpret both lines as the same paragraph and include both into the short summary.

at least that's what the docs say: http://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

A few situations got prettier. In some situations the mutability of the resulting and source pointers differed (and was cast away by transmute), the mutability matches now.

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

This reverts commit b042ffc4.

Conflicts:
	src/librustc/middle/pat_util.rs

This reverts commit bce7a6f4.

Reduce code size overhead from core::panicking::panic

core::panicking::panic currently creates an Arguments structure using
format_args!("{}", expr), which formats the expr str using the Display::fmt.
Display::fmt pulls in Formatter::pad, which then also pulls in string-related
code for truncation and padding.

If core::panicking::panic instead creates an Arguments structure with a string
piece, it is possible that the Display::fmt function for str can be optimized
out of the program.

In my testing with a 32-bit x86 bare metal program, the change tended to save
between ~100 bytes and ~5500 bytes, depending on what other panic* functions
the program invokes and whether the panic_fmt lang item uses the Arguments
value.

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.

The new `std::io` module has had some time to bake now, and this commit
stabilizes its functionality. There are still portions of the module which
remain unstable, and below contains a summart of the actions taken.

This commit also deprecates the entire contents of the `old_io` module in a
blanket fashion. All APIs should now have a reasonable replacement in the
new I/O modules.

Stable APIs:

* `std::io` (the name)
* `std::io::prelude` (the name)
* `Read`
* `Read::read`
* `Read::{read_to_end, read_to_string}` after being modified to return a `usize`
  for the number of bytes read.
* `ReadExt`
* `Write`
* `Write::write`
* `Write::{write_all, write_fmt}`
* `WriteExt`
* `BufRead`
* `BufRead::{fill_buf, consume}`
* `BufRead::{read_line, read_until}` after being modified to return a `usize`
  for the number of bytes read.
* `BufReadExt`
* `BufReader`
* `BufReader::{new, with_capacity}`
* `BufReader::{get_ref, get_mut, into_inner}`
* `{Read,BufRead} for BufReader`
* `BufWriter`
* `BufWriter::{new, with_capacity}`
* `BufWriter::{get_ref, get_mut, into_inner}`
* `Write for BufWriter`
* `IntoInnerError`
* `IntoInnerError::{error, into_inner}`
* `{Error,Display} for IntoInnerError`
* `LineWriter`
* `LineWriter::{new, with_capacity}` - `with_capacity` was added
* `LineWriter::{get_ref, get_mut, into_inner}` - `get_mut` was added)
* `Write for LineWriter`
* `BufStream`
* `BufStream::{new, with_capacities}`
* `BufStream::{get_ref, get_mut, into_inner}`
* `{BufRead,Read,Write} for BufStream`
* `stdin`
* `Stdin`
* `Stdin::lock`
* `Stdin::read_line` - added method
* `StdinLock`
* `Read for Stdin`
* `{Read,BufRead} for StdinLock`
* `stdout`
* `Stdout`
* `Stdout::lock`
* `StdoutLock`
* `Write for Stdout`
* `Write for StdoutLock`
* `stderr`
* `Stderr`
* `Stderr::lock`
* `StderrLock`
* `Write for Stderr`
* `Write for StderrLock`
* `io::Result`
* `io::Error`
* `io::Error::last_os_error`
* `{Display, Error} for Error`

Unstable APIs:

(reasons can be found in the commit itself)

* `Write::flush`
* `Seek`
* `ErrorKind`
* `Error::new`
* `Error::from_os_error`
* `Error::kind`

Deprecated APIs

* `Error::description` - available via the `Error` trait
* `Error::detail` - available via the `Display` implementation
* `thread::Builder::{stdout, stderr}`

Changes in functionality:

* `old_io::stdio::set_stderr` is now a noop as the infrastructure for printing
  backtraces has migrated to `std::io`.

[breaking-change]

r? @Manishearth