Having come back to rust recently after > 6months I was looking for docs
on tasks and stumbled upon this broken link.

The new `io` module has had some time to bake and this commit stabilizes some of
the utilities associated with it. This commit also deprecates a number of
`std::old_io::util` functions and structures.

These items are now `#[stable]`

* `Cursor`
* `Cursor::{new, into_inner, get_ref, get_mut, position, set_position}`
* Implementations of I/O traits for `Cursor<T>`
* Delegating implementations of I/O traits for references and `Box` pointers
* Implementations of I/O traits for primitives like slices and `Vec<T>`
* `ReadExt::bytes`
* `Bytes` (and impls)
* `ReadExt::chain`
* `Chain` (and impls)
* `ReadExt::take` (and impls)
* `BufReadExt::lines`
* `Lines` (and impls)
* `io::copy`
* `io::{empty, Empty}` (and impls)
* `io::{sink, Sink}` (and impls)
* `io::{repeat, Repeat}` (and impls)

These items remain `#[unstable]`

* Core I/O traits. These may want a little bit more time to bake along with the
  commonly used methods like `read_to_end`.
* `BufReadExt::split` - this function may be renamed to not conflict with
  `SliceExt::split`.
* `Error` - there are a number of questions about its representation,
  `ErrorKind`, and usability.

These items are now `#[deprecated]` in `old_io`

* `LimitReader` - use `take` instead
* `NullWriter` - use `io::sink` instead
* `ZeroReader` - use `io::repeat` instead
* `NullReader` - use `io::empty` instead
* `MultiWriter` - use `broadcast` instead
* `ChainedReader` - use `chain` instead
* `TeeReader` - use `tee` instead
* `copy` - use `io::copy` instead

[breaking-change]

It had been a source of huge bloat in rustdoc outputs. Of course,
we can simply disable compiler docs (as `rustc` generates over 90M
of HTML) but this approach fares better even after such decision.

Each directory now has `sidebar-items.js`, which immediately calls
`initSidebarItems` with a JSON sidebar data. This file is shared
throughout every item in the sidebar. The current item is
highlighted via a separate JS snippet (`window.sidebarCurrent`).
The JS file is designed to be loaded asynchronously, as the sidebar
is rendered before the content and slow sidebar loading blocks
the entire rendering. For the minimal accessibility without JS,
links to the parent items are left in HTML.

In the future, it might also be possible to integrate crates data
with the same fashion: `sidebar-items.js` at the root path will do
that. (Currently rustdoc skips writing JS in that case.)

This has a huge impact on the size of rustdoc outputs. Originally
it was 326MB uncompressed (37.7MB gzipped, 6.1MB xz compressed);
it is 169MB uncompressed (11.9MB gzipped, 5.9MB xz compressed) now.
The sidebar JS only takes 10MB uncompressed & 0.3MB gzipped.

According to Apple arm64 calling convention varargs always are passed
through stack. Since `open` is actually a vararg function on Darwin's,
it means that older declaration caused permissions to be taken from
stack, while passed through register => it set file permissions
to garbage and it was simply impossible to read/delete files after they
were created.

They way this commit handles it is to preserve compatibility with
existing code - it simply creates a shim unsafe function so all existing
callers continue work as nothing happened.

This concretely improves type inference of some cases (see included
test). I assume the compiler struggles to reason about multiple layers
of generic type parameters (even with associated-type equalities) but
*can* understand pure associated types, since they are always directly
computable from the input types.

... and use it to fix a debug-location issue with constants.

This module is now superseded by the `std::process` module. This module still
has some room to expand to get quite back up to parity with the `old_io`
version, and there is a [tracking issue][issue] for feature requests as well as
known room for expansion.

[issue]: rust-lang/rfcs#941
[breaking-change]

Fixes rust-lang#22615.

Closes rust-lang#23089

This commit is an implementation of [RFC 563][rfc] which adds a new
`cfg(debug_assertions)` directive which is specially recognized and calculated
by the compiler. The flag is turned off at any optimization level greater than 1
and may also be explicitly controlled through the `-C debug-assertions`
flag.

[rfc]: rust-lang/rfcs#563

The `debug_assert!` and `debug_assert_eq!` macros now respect this instead of
the `ndebug` variable and `ndebug` no longer holds any meaning to the standard
library.

Code which was previously relying on `not(ndebug)` to gate expensive code should
be updated to rely on `debug_assertions` instead.

Closes rust-lang#22492
[breaking-change]

The two main sub-modules, `c_str` and `os_str`, have now had some time to bake
in the standard library. This commits performs a sweep over the modules adding
various stability tags.

The following APIs are now marked `#[stable]`

* `OsString`
* `OsStr`
* `OsString::from_string`
* `OsString::from_str`
* `OsString::new`
* `OsString::into_string`
* `OsString::push` (renamed from `push_os_str`, added an `AsOsStr` bound)
* various trait implementations for `OsString`
* `OsStr::from_str`
* `OsStr::to_str`
* `OsStr::to_string_lossy`
* `OsStr::to_os_string`
* various trait implementations for `OsStr`
* `CString`
* `CStr`
* `NulError`
* `CString::new` - this API's implementation may change as a result of
  rust-lang/rfcs#912 but the usage of `CString::new(thing)` looks like it is
  unlikely to change. Additionally, the `IntoBytes` bound is also likely to
  change but the set of implementors for the trait will not change (despite the
  trait perhaps being renamed).
* `CString::from_vec_unchecked`
* `CString::as_bytes`
* `CString::as_bytes_with_nul`
* `NulError::nul_position`
* `NulError::into_vec`
* `CStr::from_ptr`
* `CStr::as_ptr`
* `CStr::to_bytes`
* `CStr::to_bytes_with_nul`
* various trait implementations for `CStr`

The following APIs remain `#[unstable]`

* `OsStr*Ext` traits remain unstable as the organization of `os::platform` is
  uncertain still and the traits may change location.
* `AsOsStr` remains unstable as generic conversion traits are likely to be
  rethought soon.

The following APIs were deprecated

* `OsString::push_os_str` is now called `push` and takes `T: AsOsStr` instead (a
  superset of the previous functionality).

No more alphas, please.

Bind on non-local IP address is essentially the same test, and it works
same way on all platforms.

Fixes rust-lang#11530

This commit performs a stabilization pass over the `std::fs` module now that
it's had some time to bake. The change was largely just adding `#[stable]` tags,
but there are a few APIs that remain `#[unstable]`.

The following apis are now marked `#[stable]`:

* `std::fs` (the name)
* `File`
* `Metadata`
* `ReadDir`
* `DirEntry`
* `OpenOptions`
* `Permissions`
* `File::{open, create}`
* `File::{sync_all, sync_data}`
* `File::set_len`
* `File::metadata`
* Trait implementations for `File` and `&File`
* `OpenOptions::new`
* `OpenOptions::{read, write, append, truncate, create}`
* `OpenOptions::open` - this function was modified, however, to not attempt to
  reject cross-platform openings of directories. This means that some platforms
  will succeed in opening a directory and others will fail.
* `Metadata::{is_dir, is_file, len, permissions}`
* `Permissions::{readonly, set_readonly}`
* `Iterator for ReadDir`
* `DirEntry::path`
* `remove_file` - like with `OpenOptions::open`, the extra windows code to
  remove a readonly file has been removed. This means that removing a readonly
  file will succeed on some platforms but fail on others.
* `metadata`
* `rename`
* `copy`
* `hard_link`
* `soft_link`
* `read_link`
* `create_dir`
* `create_dir_all`
* `remove_dir`
* `remove_dir_all`
* `read_dir`

The following apis remain `#[unstable]`.

* `WalkDir` and `walk` - there are many methods by which a directory walk can be
  constructed, and it's unclear whether the current semantics are the right
  ones. For example symlinks are not handled super well currently. This is now
  behind a new `fs_walk` feature.
* `File::path` - this is an extra abstraction which the standard library
  provides on top of what the system offers and it's unclear whether we should
  be doing so. This is now behind a new `file_path` feature.
* `Metadata::{accessed, modified}` - we do not currently have a good
  abstraction for a moment in time which is what these APIs should likely be
  returning, so these remain `#[unstable]` for now. These are now behind a new
  `fs_time` feature
* `set_file_times` - like with `Metadata::accessed`, we do not currently have
  the appropriate abstraction for the arguments here so this API remains
  unstable behind the `fs_time` feature gate.
* `PathExt` - the precise set of methods on this trait may change over time and
  some methods may be removed. This API remains unstable behind the `path_ext`
  feature gate.
* `set_permissions` - we may wish to expose a more granular ability to set the
  permissions on a file instead of just a blanket "set all permissions" method.
  This function remains behind the `fs` feature.

The following apis are now `#[deprecated]`

* The `TempDir` type is now entirely deprecated and is [located on
  crates.io][tempdir] as the `tempdir` crate with [its source][github] at
  rust-lang/tempdir.

[tempdir]: https://crates.io/crates/tempdir
[github]: https://github.com/rust-lang/tempdir

The stability of some of these APIs has been questioned over the past few weeks
in using these APIs, and it is intentional that the majority of APIs here are
marked `#[stable]`. The `std::fs` module has a lot of room to grow and the
material is [being tracked in a RFC issue][rfc-issue].

[rfc-issue]: rust-lang/rfcs#939

[breaking-change]

The `rsplitn` call was called with 2 instead of 1 so the iterator would yield 3
items in some cases, not the 2 that it should have.

Closes rust-lang#23076

Fixes rust-lang#23059

Signed-off-by: Lai Jiangshan <[email protected]>

 According to Apple's [arm64 calling convention](https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html#//apple_ref/doc/uid/TP40013702-SW1) varargs always are passed
through stack. Since `open` is actually a vararg function on Darwin,
it means that older declaration caused permissions to be taken from
stack, while passed through register => it set file permissions
to garbage and it was simply impossible to read/delete files after they
were created.

They way this commit handles it is to preserve compatibility with
existing code - it simply creates a shim unsafe function so all existing
callers continue work as nothing happened.

 Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.

E.g.

    #[allow_internal_unstable]
    macro_rules! foo {
        ($e: expr) => {{
            $e;
            unstable(); // no warning
            only_called_by_foo!();
        }}
    }

    macro_rules! only_called_by_foo {
        () => { unstable() } // warning
    }

    foo!(unstable()) // warning

The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).

In the process this makes the stability tracking much more precise,
e.g. previously `println!(\"{}\", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.

The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.

---

This updates `thread_local!` macro to use the attribute, since it uses
unstable features internally (initialising a struct with unstable
fields).

…kfelix

 This commit is an implementation of [RFC 563][rfc] which adds a new
`cfg(debug_assertions)` directive which is specially recognized and calculated
by the compiler. The flag is turned off at any optimization level greater than 1
and may also be explicitly controlled through the `-C debug-assertions`
flag.

[rfc]: rust-lang/rfcs#563

The `debug_assert!` and `debug_assert_eq!` macros now respect this instead of
the `ndebug` variable and `ndebug` no longer holds any meaning to the standard
library.

Code which was previously relying on `not(ndebug)` to gate expensive code should
be updated to rely on `debug_assertions` instead.

Closes rust-lang#22492
[breaking-change]

… r=aturon

 The new `io` module has had some time to bake and this commit stabilizes some of
the utilities associated with it. This commit also deprecates a number of
`std::old_io::util` functions and structures.

These items are now `#[stable]`

* `Cursor`
* `Cursor::{new, into_inner, get_ref, get_mut, position, set_position}`
* Implementations of I/O traits for `Cursor<T>`
* Delegating implementations of I/O traits for references and `Box` pointers
* Implementations of I/O traits for primitives like slices and `Vec<T>`
* `ReadExt::bytes`
* `Bytes` (and impls)
* `ReadExt::chain`
* `Chain` (and impls)
* `ReadExt::take` (and impls)
* `BufReadExt::lines`
* `Lines` (and impls)
* `io::copy`
* `io::{empty, Empty}` (and impls)
* `io::{sink, Sink}` (and impls)
* `io::{repeat, Repeat}` (and impls)

These items remain `#[unstable]`

* Core I/O traits. These may want a little bit more time to bake along with the
  commonly used methods like `read_to_end`.
* `BufReadExt::split` - this function may be renamed to not conflict with
  `SliceExt::split`.
* `Error` - there are a number of questions about its representation,
  `ErrorKind`, and usability.

These items are now `#[deprecated]` in `old_io`

* `LimitReader` - use `take` instead
* `NullWriter` - use `io::sink` instead
* `ZeroReader` - use `io::repeat` instead
* `NullReader` - use `io::empty` instead
* `MultiWriter` - use `broadcast` instead
* `ChainedReader` - use `chain` instead
* `TeeReader` - use `tee` instead
* `copy` - use `io::copy` instead

[breaking-change]

…richton

…r=alexcrichton

 It had been a source of huge bloat in rustdoc outputs. Of course, we can simply disable compiler docs (as `rustc` generates over 90M of HTML) but this approach fares better even after such decision.

Each directory now has `sidebar-items.js`, which immediately calls `initSidebarItems` with a JSON sidebar data. This file is shared throughout every item in the sidebar. The current item is highlighted via a separate JS snippet (`window.sidebarCurrent`). The JS file is designed to be loaded asynchronously, as the sidebar is rendered before the content and slow sidebar loading blocks the entire rendering. For the minimal accessibility without JS, links to the parent items are left in HTML.

In the future, it might also be possible to integrate crates data with the same fashion: `sidebar-items.js` at the root path will do that. (Currently rustdoc skips writing JS in that case.)

This has a huge impact on the size of rustdoc outputs. Originally it was 326MB uncompressed (37.7MB gzipped, 6.1MB xz compressed); it is 169MB uncompressed (11.9MB gzipped, 5.9MB xz compressed) now. The sidebar JS only takes 10MB uncompressed & 0.3MB gzipped.

 This separates definitions of struct stat and other typedefs between Android and Linux on ARM (Android has a non-standard one). This makes functions such as `File::metadata()` work correctly and makes one able to check file's size. All tests from std (and also run-pass: stat.rs) now pass on ARM Linux. Fixes rust-lang#20007.

…cs, r=alexcrichton

 With this PR in-place constants are handled correctly with respect to debug location assignment.
The PR also adds an (unrelated) test case for debug locations in `extern \"C\"` functions.

Fixes rust-lang#22432

…turon

 This module is now superseded by the `std::process` module. This module still
has some room to expand to get quite back up to parity with the `old_io`
version, and there is a [tracking issue][issue] for feature requests as well as
known room for expansion.

[issue]: rust-lang/rfcs#941
[breaking-change]

 This commit performs a stabilization pass over the `std::fs` module now that
it's had some time to bake. The change was largely just adding `#[stable]` tags,
but there are a few APIs that remain `#[unstable]`.

The following apis are now marked `#[stable]`:

* `std::fs` (the name)
* `File`
* `Metadata`
* `ReadDir`
* `DirEntry`
* `OpenOptions`
* `Permissions`
* `File::{open, create}`
* `File::{sync_all, sync_data}`
* `File::set_len`
* `File::metadata`
* Trait implementations for `File` and `&File`
* `OpenOptions::new`
* `OpenOptions::{read, write, append, truncate, create}`
* `OpenOptions::open` - this function was modified, however, to not attempt to
  reject cross-platform openings of directories. This means that some platforms
  will succeed in opening a directory and others will fail.
* `Metadata::{is_dir, is_file, len, permissions}`
* `Permissions::{readonly, set_readonly}`
* `Iterator for ReadDir`
* `DirEntry::path`
* `remove_file` - like with `OpenOptions::open`, the extra windows code to
  remove a readonly file has been removed. This means that removing a readonly
  file will succeed on some platforms but fail on others.
* `metadata`
* `rename`
* `copy`
* `hard_link`
* `soft_link`
* `read_link`
* `create_dir`
* `create_dir_all`
* `remove_dir`
* `remove_dir_all`
* `read_dir`

The following apis remain `#[unstable]`.

* `WalkDir` and `walk` - there are many methods by which a directory walk can be
  constructed, and it's unclear whether the current semantics are the right
  ones. For example symlinks are not handled super well currently. This is now
  behind a new `fs_walk` feature.
* `File::path` - this is an extra abstraction which the standard library
  provides on top of what the system offers and it's unclear whether we should
  be doing so. This is now behind a new `file_path` feature.
* `Metadata::{accessed, modified}` - we do not currently have a good
  abstraction for a moment in time which is what these APIs should likely be
  returning, so these remain `#[unstable]` for now. These are now behind a new
  `fs_time` feature
* `set_file_times` - like with `Metadata::accessed`, we do not currently have
  the appropriate abstraction for the arguments here so this API remains
  unstable behind the `fs_time` feature gate.
* `PathExt` - the precise set of methods on this trait may change over time and
  some methods may be removed. This API remains unstable behind the `path_ext`
  feature gate.
* `set_permissions` - we may wish to expose a more granular ability to set the
  permissions on a file instead of just a blanket \"set all permissions\" method.
  This function remains behind the `fs` feature.

The following apis are now `#[deprecated]`

* The `TempDir` type is now entirely deprecated and is [located on
  crates.io][tempdir] as the `tempdir` crate with [its source][github] at
  rust-lang/tempdir.

[tempdir]: https://crates.io/crates/tempdir
[github]: https://github.com/rust-lang/tempdir

The stability of some of these APIs has been questioned over the past few weeks
in using these APIs, and it is intentional that the majority of APIs here are
marked `#[stable]`. The `std::fs` module has a lot of room to grow and the
material is [being tracked in a RFC issue][rfc-issue].

[rfc-issue]: rust-lang/rfcs#939

Closes rust-lang#22879

[breaking-change]

 Closes rust-lang#23089

…ichton

 Bind on non-local IP address is essentially the same test, and it works
same way on all platforms.

Fixes rust-lang#11530

Being a person who somehow has taken a liking to premature optimisation, my knee-jerk reaction to
locking in std handles was preamble resembling following snippet:

    let stdout = stdout();
    let lstdout = stdout.lock();
    let stdin = stdin();
    let lstdin = stdin.lock();

and then reading from the locked handle like this:

    let mut letter = [0; 1];
    lstdin.read(&mut letter).unwrap();

As it is now this code will deadlock because the `read` method attempts to lock stdout as well!

fixes rust-lang#23080

 Signed-off-by: Lai Jiangshan <[email protected]>

 This concretely improves type inference of some cases (see included
test). I assume the compiler struggles to reason about multiple layers
of generic type parameters (even with associated-type equalities) but
*can* understand pure associated types, since they are always directly
computable from the input types.

Thanks to @shepmaster for noticing the issue with `Cloned` (I took that example as a test case).

 r? @steveklabnik

… r=brson

 Having come back to rust recently after > 6months I was looking for docs
on tasks and stumbled upon this broken link.

 The compiler even tells us this won't work.
```
let mut i = s.len();
while i < 0 { ... }
```

 This should fix rust-lang#22615. Previously, the playpen links grabbed the content of all `.rusttest` containers on the same level to build the URL. Now they just select the one before the `pre` they are shown in.

I have only tested this by changing the file in my local build of the docs (not by running rustdoc itself).

 No more alphas, please.

…r-fix, r=huonw

 Fixes rust-lang#23059

 Executing `configure` seems to create the following error due to how the script [parses Pandoc's version](https://github.com/rust-lang/rust/blob/master/configure#L705):

```text
./configure: line 705: [: pandoc: integer expression expected
./configure: line 705: [: 1.12.4.2: integer expression expected
```

This issue seems to stem from a discrepancy between BSD and GNU versions of sed. This patch changes the sed command to use an extended regex, which works with both flavours of sed.

The `std::net` primitives should be ready for use now and as a result the old
ones are now deprecated and slated for removal. Most TCP/UDP functionality is
now available through `std::net` but the `std::old_io::net::pipe` module is
removed entirely from the standard library.

Unix socket funtionality can be found in sfackler's [`unix_socket`][unix] crate
and there is currently no replacement for named pipes on Windows.

[unix]: https://crates.io/crates/unix_socket

[breaking-change]

This test is known to fail on windows.

The `std::net` primitives should be ready for use now and as a result the old
ones are now deprecated and slated for removal. Most TCP/UDP functionality is
now available through `std::net` but the `std::old_io::net::pipe` module is
removed entirely from the standard library.

Unix socket funtionality can be found in sfackler's [`unix_socket`][unix] crate
and there is currently no replacement for named pipes on Windows.

[unix]: https://crates.io/crates/unix_socket

[breaking-change]

Conflicts:
	src/librustc_trans/back/link.rs
	src/librustc_trans/lib.rs

Being a person who somehow has taken a liking to premature optimisation, my knee-jerk reaction to
locking in std handles was preamble resembling following snippet:

    let stdout = stdout();
    let lstdout = stdout.lock();
    let stdin = stdin();
    let lstdin = stdin.lock();

and then reading from the locked handle like this:

    let mut letter = [0; 1];
    lstdin.read(&mut letter).unwrap();

As it is now this code will deadlock because the `read` method attempts to lock stdout as well!

r? @alexcrichton

---

Either way, I find flushing stdout when stdin is used debatable. I believe people who write prompts should take care to flush stdout when necessary themselves.

Another idea: Would be cool if locks on std handles would be taken for a thread, rather than a handle, so given preamble (first code snippet)

    stdin.lock()

or more generally

    stdin.read(…)

worked fine. I.e. if more than a single lock are all taken inside the same thread, it would work, though not sure if our synchronisation primitives are expressive enough to make it possible.

r? @nikomatsakis See the cfail test, it compiles without this patch
cc rust-lang#13231

The `rsplitn` call was called with 2 instead of 1 so the iterator would yield 3
items in some cases, not the 2 that it should have.

Closes rust-lang#23076

fixes rust-lang#23080

r? @nikomatsakis
cc @flaper87