Automated conversion using the untry tool [1] and the following command:

```
$ find -name '*.rs' -type f | xargs untry
```

at the root of the Rust repo.

[1]: https://github.com/japaric/untry

This pushes the implementation detail of proxying `read_to_end` through to
`read_to_end_uninitialized` all the way down to the `FileDesc` and `Handle`
implementations on Unix/Windows. This way intermediate layers will also be able
to take advantage of this optimized implementation.

This commit also adds the optimized implementation for `ChildStdout` and
`ChildStderr`.

Because we no longer use `GetFileAttributesExW` FileAttr is never created
directly from `WIN32_FILE_ATTRIBUTE_DATA` anymore.
So we should no longer store FileAttr's attributes in that c struct.

Fix `read_link` to also be able to read the target of junctions on Windows.
Also the path returned should not include a NT namespace, and there were
some problems with permissions.

See #29412

These accessors are used to get at the last modification, last access, and
creation time of the underlying file. Currently not all platforms provide the
creation time, so that currently returns `Option`.

The deny(warnings) attribute is now enabled for tests so we need to weed out
these warnings as well.

Otherwise it is not Send and Sync anymore

Tracking issue: #30014

This implements the RFC and makes a few other changes.
I have added a few extra tests, and made the Windows and
Unix code as similar as possible.

Part of the RFC mentions the unstable OpenOptionsExt trait
on Windows (see #27720). I have added a few extra methods
to future-proof it for CreateFile2.

This check is necessary, because the underlying API only reads strings
until the first NUL.

On Windows: Previously these paths were silently truncated at these NUL
characters, now they fail with `ErrorKind::InvalidInput`.

* Delete `sys::unix::{c, sync}` as these are now all folded into libc itself
* Update all references to use `libc` as a result.
* Update all references to the new flat namespace.
* Moves all windows bindings into sys::c

This commit adds #[derive(Clone)] to std::fs::Metadata, making that struct
cloneable. Although the exact contents of that struct differ between OSes,
they all have it contain only value types, meaning that the data can be re-used without repercussions.

It also adds #[derive(Clone)] to every type used by that struct across all
OSes, including the various Unix `stat` structs and Windows's
`WIN32_FILE_ATTRIBUTE_DATA`.

Signed-off-by: NPeter Atashian <retep998@gmail.com>

This commit removes all unstable and deprecated functions in the standard
library. A release was recently cut (1.3) which makes this a good time for some
spring cleaning of the deprecated functions.

* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed

This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.

[rfc]: https://github.com/rust-lang/rfcs/pull/1184

Adds a path field if a path could be obtained
Signed-off-by: NPeter Atashian <retep998@gmail.com>

This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:

* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1174-into-raw-fd-socket-handle-traits.md

Closes #27062

Previously on Windows a directory junction would return false from `is_dir`,
causing various odd behavior, specifically calls to `create_dir_all` might fail
when they would otherwise continue to succeed.

Closes #26716

Adds a couple more tests for fs::copy
Signed-off-by: NPeter Atashian <retep998@gmail.com>

This commit enables executables linked against the standard library to run on
Windows XP. There are two main components of this commit:

* APIs not available on XP are shimmed to have a fallback implementation and use
  runtime detection to determine if they are available.
* Mutexes on Windows were reimplemented to use critical sections on XP where
  rwlocks are not available.

The APIs which are not available on XP are:

* SetFileInformationByHandle - this is just used by `File::truncate` and that
  function just returns an error now.
* SetThreadStackGuarantee - this is used by the stack overflow support on
  windows, but if this isn't available then it's just ignored (it seems
  non-critical).
* All condition variable APIs are missing - the shims added for these apis
  simply always panic for now. We may eventually provide a fallback
  implementation, but for now the standard library does not rely on condition
  variables for normal use.
* RWLocks, like condition variables, are missing entirely. The same story for
  condition variables is taken here. These APIs are all now panicking stubs as
  the standard library doesn't rely on RWLocks for normal use.

Currently, as an optimization, we use SRWLOCKs for the standard `sync::Mutex`
implementation on Windows, which is indeed required for normal operation of the
standard library. To allow the standard library to run on XP, this commit
reimplements mutexes on Windows to use SRWLOCK instances *if available* and
otherwise a CriticalSection is used (with some checking for recursive
locking).

With all these changes put together, a 32-bit MSVC-built executable can run on
Windows XP and print "hello world"

Closes #12842
Closes #19992
Closes #24776

Since all those flags are u32 anyway, avoid unnecessary conversions
[breaking change]
Signed-off-by: NPeter Atashian <retep998@gmail.com>

Now that `std::old_io` has been removed for quite some time the naming real
estate here has opened up to allow these modules to move back to their proper
names.

Currently if a standard I/O handle is set to inherited on Windows, no action is
taken and the slot in the process information description is set to
`INVALID_HANDLE_VALUE`. Due to our passing of `STARTF_USESTDHANDLES`, however,
this means that the handle is actually set to nothing and if a child tries to
print it will generate an error.

This commit fixes this behavior by explicitly creating stdio handles to be
placed in these slots by duplicating the current process's I/O handles. This is
presumably what previously happened silently by using a file-descriptor-based
implementation instead of a `HANDLE`-centric implementation.

Along the way this cleans up a lot of code in `Process::spawn` for Windows by
ensuring destructors are always run, using more RAII, and limiting the scope of
`unsafe` wherever possible.

This is the last remaining portion of #24796

This commit is an implementation of [RFC 1044][rfc] which adds additional
surface area to the `std::fs` module. All new APIs are `#[unstable]` behind
assorted feature names for each one.

[rfc]: https://github.com/rust-lang/rfcs/pull/1044

The new APIs added are:

* `fs::canonicalize` - bindings to `realpath` on unix and
  `GetFinalPathNameByHandle` on windows.
* `fs::symlink_metadata` - similar to `lstat` on unix
* `fs::FileType` and accessor methods as `is_{file,dir,symlink}`
* `fs::Metadata::file_type` - accessor for the raw file type
* `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows
  but requires a syscall on unix.
* `fs::DirEntry::file_type` - access the file type which may not require a
  syscall on most platforms.
* `fs::DirEntry::file_name` - access just the file name without leading
  components.
* `fs::PathExt::symlink_metadata` - convenience method for the top-level
  function.
* `fs::PathExt::canonicalize` - convenience method for the top-level
  function.
* `fs::PathExt::read_link` - convenience method for the top-level
  function.
* `fs::PathExt::read_dir` - convenience method for the top-level
  function.
* `std::os::raw` - type definitions for raw OS/C types available on all
  platforms.
* `std::os::$platform` - new modules have been added for all currently supported
  platforms (e.g. those more specific than just `unix`).
* `std::os::$platform::raw` - platform-specific type definitions. These modules
  are populated with the bare essentials necessary for lowing I/O types into
  their raw representations, and currently largely consist of the `stat`
  definition for unix platforms.

This commit also deprecates `Metadata::{modified, accessed}` in favor of
inspecting the raw representations via the lowering methods of `Metadata`.

This API was exercised in a few tests and mirrors the `from_str_radix`
functionality of the integer types.

On Windows, when you create a symbolic link you must specify whether it
points to a directory or a file, even if it is created dangling, while
on Unix, the same symbolic link could point to a directory, a file, or
nothing at all.  Furthermore, on Windows special privilege is necessary
to use a symbolic link, while on Unix, you can generally create a
symbolic link in any directory you have write privileges to.

This means that it is unlikely to be able to use symbolic links purely
portably; anyone who uses them will need to think about the cross
platform implications.  This means that using platform-specific APIs
will make it easier to see where code will need to differ between the
platforms, rather than trying to provide some kind of compatibility
wrapper.

Furthermore, `soft_link` has no precedence in any other API, so to avoid
confusion, move back to the more standard `symlink` terminology.

Create a `std::os::unix::symlink` for the Unix version that is
destination type agnostic, as well as `std::os::windows::{symlink_file,
symlink_dir}` for Windows.

Because this is a stable API, leave a compatibility wrapper in
`std::fs::soft_link`, which calls `symlink` on Unix and `symlink_file`
on Windows, preserving the existing behavior of `soft_link`.

This patch adds a `Debug` impl for `std::fs::File`.

On all platforms (Unix and Windows) it shows the file descriptor.

On Linux, it displays the path and access mode as well.

Ideally we should show the path/mode for all platforms, not just Linux,
but this will do for now.

cc #24570

The current implementation of using GetFinalPathNameByHandle actually reads all
intermediate links instead of just looking at the current link. This commit
alters the behavior of the function to use a different API which correctly reads
only one level of the soft link.

[breaking-change]