Not checking for 32/64 bit, since `uname -s` no longer contains an indicator (and `uname -m` returns correct results)

fixes #23080

r? @nikomatsakis
cc @FlaPer87

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

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

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.

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

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.

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]

 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.

 Fixes #23059

 No more alphas, please.

 This should fix #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).

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

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

 r? @steveklabnik

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

Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

fixes #23080

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!

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

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

Fixes #11530

 Closes #23089

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

[breaking-change]

 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]: https://github.com/rust-lang/rfcs/issues/941
[breaking-change]

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

 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 #20007.

 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.