r? @alexcrichton or @aturon 

This still needs to somehow figure out how to avoid unstable warnings arising from the use of unstable functions. I tried to use `#[allow_internal_unstable]` but it still spits out warnings as far as I can see. @huonw (I think you implemented it) does `#[allow_internal_unstable]` not work for some reason or am I using it incorrectly?

This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.

The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.

The following items are now stable:

* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`

The following items remain unstable:

* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`

Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).

[breaking-change]

This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.

The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.

The following items are now stable:

* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`

The following items remain unstable:

* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`

Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).

[breaking-change]

- Successful merges: #23375, #23379, #23382, #23384
- Failed merges: 

r? @alexcrichton cc @vhbit

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

The usage of `an String` was introduced in https://github.com/rust-lang/rust/commit/a828e7948069f310dc5b33be8edb65e5e8e0cf9a#diff-b596503c7c33ce457b6d047e351ac12bR423, which changed `an OsString` to `an String`.

`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.

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

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 */`

Super minor change!

The `an String` was introduced in https://github.com/rust-lang/rust/commit/a828e7948069f310dc5b33be8edb65e5e8e0cf9a#diff-b596503c7c33ce457b6d047e351ac12bR423, which changed `an OsString` to `an String`.

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)

std::io does not currently expose the stdin_raw, stdout_raw, or
stderr_raw functions. According to the current plans for stdio (see RFC
#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.

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.

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

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.