use SecRandomCopyBytes on macOS in Miri
This is a hack to fix https://github.com/rust-lang/miri/issues/686: on macOS, rustc will open `/dev/urandom` to initialize a `HashMap`. That's quite hard to emulate properly in Miri without a full-blown implementation of file descriptors. However, Miri needs an implementation of `SecRandomCopyBytes` anyway to support [getrandom](https://crates.io/crates/getrandom), so using it here should work just as well.
This will only have an effect when libstd is compiled specifically for Miri, but that will generally be the case when people use `cargo miri`.
This is clearly a hack, so I am opening this to start a discussion about whether we are okay with such a hack or not.
Cc @oli-obk
Add const generics to infer (and transitive dependencies)
Split out from #53645. This work is a collaborative effort with @yodaldevoid.
There are a number of stubs. These are mainly to ensure we don't overlook them when completing the implementation, but are not necessary for the initial implementation. We plan to address these in follow up PRs.
r? @eddyb / @nikomatsakis
Rollup of 7 pull requests
Successful merges:
- #59634 (Added an explanation for the E0704 error.)
- #60348 (move some functions from parser.rs to diagostics.rs)
- #60385 (Emit metadata files earlier)
- #60428 (Refactor `eval_body_using_ecx` so that it doesn't need to query for MIR)
- #60437 (Ensure that drop order of `async fn` matches `fn` and that users cannot refer to generated arguments.)
- #60439 (doc: Warn about possible zombie apocalypse)
- #60452 (Remove Context and ContextKind)
Failed merges:
r? @ghost
doc: Warn about possible zombie apocalypse
Extend the std::process::Child docs with warning about possible zombies.
The previous version mentioned that when dropping the Child, the
process is not killed. However, the wording gave the impression that
such behaviour is fine to do (leaving the reader believe low-level
details like reaping zombies of the dead processes is taken over by std
somehow; or simply leaving the reader unaware about the problem).
Ensure that drop order of `async fn` matches `fn` and that users cannot refer to generated arguments.
Fixes#60236 and fixes#60438.
This PR modifies the lowering of `async fn` arguments so that the
drop order matches the equivalent `fn`.
Previously, async function arguments were lowered as shown below:
async fn foo(<pattern>: <ty>) {
async move {
}
} // <-- dropped as you "exit" the fn
// ...becomes...
fn foo(__arg0: <ty>) {
async move {
let <pattern> = __arg0;
} // <-- dropped as you "exit" the async block
}
After this PR, async function arguments will be lowered as:
async fn foo(<pattern>: <ty>, <pattern>: <ty>, <pattern>: <ty>) {
async move {
}
} // <-- dropped as you "exit" the fn
// ...becomes...
fn foo(__arg0: <ty>, __arg1: <ty>, __arg2: <ty>) {
async move {
let __arg2 = __arg2;
let <pattern> = __arg2;
let __arg1 = __arg1;
let <pattern> = __arg1;
let __arg0 = __arg0;
let <pattern> = __arg0;
} // <-- dropped as you "exit" the async block
}
If `<pattern>` is a simple ident, then it is lowered to a single
`let <pattern> = <pattern>;` statement as an optimization.
This PR also stops users from referring to the generated `__argN`
identifiers.
r? @nikomatsakis
Refactor `eval_body_using_ecx` so that it doesn't need to query for MIR
This is the first step toward removing the `mir` field of `ConstPropagator` which will eventually allow us to actually const propagate in MIR.
r? @oli-obk
Added an explanation for the E0704 error.
# Description
Adds an explanation on the E0704 error. I tried to stick as closely to the message that the compiler generates. It's the first time I am fixing error messages here, so if there is something I did wrong or should improve, please let me know.
closes#55398
bors