Refactor `Vec::map_in_place` to move code out of `PartialVec`

Additionally, support zero-sized types.
Removed some unnecessary RefCells from resolve
Fixes ICE when using reexported unit-like structs

Fixes that unit-like structs cannot be used if they are reexported and
used in another crate. The compiler fails with an ICE, because unit-like
structs are exported as DefFn and the expression `UnitStruct` is
interpreted as function pointer instead of a call to the constructor.

To resolve this ambiguity tuple-like struct constructors are now exported
as CtorFn. When `rustc::metadata::decoder` finds a CtorFn it sets a new
flag `is_ctor` in DefFn to true.

Relevant changes are in `rustc::metadata::{encoder, decoder}` and in
`rustc::middle::ty`.

Closes #12660 and #16973.
libstd: Pass-through PATH in test_override_env

In some build environments (such as chrooted Nix builds), `env` can only
be found in the explicitly-provided PATH, not in default places such as
/bin or /usr/bin. So we need to pass-through PATH when spawning the
`env` sub-process.

Fixes #17617
Limit recursion depth for macro expansions, closes #17628
auto merge of #17653 : kaini/rust/master, r=alexcrichton

Fixes that unit-like structs cannot be used if they are re-exported and used in another crate. (ICE)
The relevant changes are in `rustc::metadata::{decoder, encoder}` and `rustc::middle::ty`.

A test case is included.

The problem is that the expressoin `UnitStruct` is an `ExprPath` to an `DefFn`, which is of expr kind `RvalueDatumExpr`, but for unit-struct ctors the expr kind should be `RvalueDpsExpr`. I fixed this (in a I guess clean way) by introducing `CtorFn` in the metadata and including a `is_ctor` flag in `DefFn`.
auto merge of #17654 : gereeter/rust/no-unnecessary-cell, r=alexcrichton

There is more that could be done, but this was the low hanging fruit.
auto merge of #17667 : wizeman/rust/fix-override-env, r=alexcrichton

In some build environments (such as chrooted Nix builds), `env` can only
be found in the explicitly-provided PATH, not in default places such as
/bin or /usr/bin. So we need to pass-through PATH when spawning the
`env` sub-process.

Fixes #17617
Remove all use of librustuv
Remove iotest macro

This commit removes the `iotest!` macro from `std::io`. The macro was
primarily used to ensure that all io-related tests were run on both
libnative and libgreen/librustuv. However, now that the librustuv stack
is being removed, the macro is no longer needed.

See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.

[breaking-change]
Remove librustuv

This commit removes the `librustuv` crate.

See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.

[breaking-change]
auto merge of #17678 : fhahn/rust/issue-17628-infinite-recursion, r=alexcrichton

This is a patch for #17628, thanks to @kmcallister for your helpful hints!
Remove libuv, gyp

This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230)

[breaking-change]
Remove std::io::signal

The `std::io::signal` API was only implemented under `librustuv`, which
is now being removed. Rather than keep around an unimplemented API, this
commit removes it altogether.

See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.

See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path for signal handling code, although in the long run we
plan to add native signal handling to `std::io`.

[breaking-change]
auto merge of #17673 : aturon/rust/remove-uv, r=alexcrichton

This PR begins the process of [runtime removal](https://github.com/rust-lang/rfcs/pull/230) by dismantling the `librustuv` crate and associated event loop.

The result is that, while `libgreen` can still be used for task scheduling purposes, it will no longer be feasible to use green-threaded I/O.

Removing the libuv-based event loop eases the transition away from the runtime system, which will be done incrementally.

In terms of visible API changes, this PR:

* Removes `std::io::signal`, which was never implemented on the native threading model.

* Removes the `iotest!` macro, which was previously used to run I/O tests on both green and native threading models.

* Removes the `green_start!` macro for starting an application with a `librustuv` event loop.

* Removes the `librustuv` crate itself.

It also removes the `libuv` and `gyp` submodules and adjusts the build system and copyright notices accordingly.

If you wish to continue using `librustuv` and green-threaded I/O, consider using [green-rs](https://github.com/alexcrichton/green-rs/), which provides its own I/O stack.
auto merge of #17381 : tbu-/rust/pr_mapinplace2, r=aturon

Additionally, support zero-sized types.

Now there isn't a safe interface of `PartialVec` anymore, it's just a bare data structure with destructor that assumes you handled everything correctly before.
start work on a new implementation of TLS

This begins the work towards a new TLS implementation. It will be useful
to have the initial work in-tree for test coverage across various
platforms and to allow for collaborative work on the API. The current
fast implementation using `#[thread_local]` is expected to work on
Linux, Windows (with #17563), OS X, FreeBSD and the current Android
version (but not the bot).

Coming up with a good API will need to wait until there's a full
implementation with destructor support (#17572) and a fallback path
(#17579) for platforms like iOS and old versions of Android. A set of 6
macros is probably not the ideal API... but it's an obvious way of
covering all of the use cases with minimal overhead.

Closes #17569
work around yet another MinGW-w64 ASLR bug