The bitshifts were wrong in that they invoked undefined behavior and
only passed the lower byte of the presumed-to-be-32bit errno value.
Apparently all actually possible values for errno happen to be easily
under 256, so this didn't cause any actual problems.
This commit fixes the bitshifts, but doesn't generalize to errno types
that aren't 32bit.
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.
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.
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]
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`.
prefer `Deref` over `DerefMut` in all other circumstances.
Because the compiler now prefers `Deref`, this can break code that
looked like:
let mut foo = bar.borrow_mut();
(*foo).call_something_that_requires_mutable_self();
Replace this code with:
let mut foo = bar.baz();
(&mut *foo).call_something_that_requires_mutable_self();
Closes#12825.
[breaking-change]
r? @nikomatsakis
Modify ast::ExprMatch to include a new value of type ast::MatchSource,
making it easy to tell whether the match was written literally or
produced via desugaring. This allows us to customize error messages
appropriately.
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.
This is the bare minimum to stop using split stacks on Windows, fixing https://github.com/rust-lang/rust/issues/13259 and #14742, by turning on stack probes for all functions and disabling compiler and runtime support for split stacks on Windows.
It does not restore the out-of-stack error message, which requires more runtime work.
This includes a test that the Windows TCB is no longer being clobbered, but the out-of-stack test itself is pretty weak, only testing that the program exits abnormally, not that it isn't writing to bogus memory, so I haven't truly verified that this is providing the safety we claim.
A more complete solution is in https://github.com/rust-lang/rust/pull/16388, which has some unresolved issues yet.
cc @Zoxc @klutzy @vadimcn
