This test has recently been failing on the bots, and I'm not entirely sure why.
I haven't been able to reproduce locally or on the bots, so I'm adding some
messages to help diagnose the problem hopefully.
Previously it output `partially moved` to eagerly. This updates it to be more
accurate and output `collaterally moved` for use of values that were invalidated
by moves out of different fields in the same struct.
Closes#15630.
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.
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.
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]
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]
CFG_RELEASE, CFG_VER_HASH and CFG_VER_DATE were only available as an output
to stdout from the driver::version() function that had an inconvenient
signature.
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]
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]
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
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`.
