This renames and stabilizes unsafe floating point to integer casts, which are
intended to be the substitute for the currently unsound `as` behavior, once that
changes to safe-but-slower saturating casts.

…:new.

Allow the `SimplifyLocals` pass to remove reads of discriminants if the
read is never used.

fith => fifth

…ts, r=SimonSapin

Stabilize float::to_int_unchecked

This renames and stabilizes unsafe floating point to integer casts, which are intended to be the substitute for the currently unsound `as` behavior, once that changes to safe-but-slower saturating casts. As such, I believe this also likely unblocks rust-lang#10184 (our oldest I-unsound issue!), as once this rolls out to stable it would be far easier IMO to change the behavior of `as` to be safe by default.

This does not stabilize the trait or the associated method, as they are deemed internal implementation details (and consumers should not, generally, want to expose them, as in practice all callers likely know statically/without generics what the return type is).

Closes rust-lang#67058

…ant_reads, r=oli-obk

Remove unused discriminant reads from MIR bodies

Allow the `SimplifyLocals` pass to remove reads of discriminants if the
read is never used.

Fixes rust-lang#70531

r? @oli-obk

…fix, r=Amanieu,RalfJung

Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new

While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour.

**Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung):

1.  The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`.
2.  The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic.
3.  Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free.

As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted.  The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB.

This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.

Improve docs in `AllocRef`

r? @RalfJung

Use Self over specific type in return position

…rk-Simulacrum

bootstrap: add `--json-output` for rust-analyzer

Motivation is that this allows us to customize rust-analyzer's "cargo watch" integration to run x.py. You simply have to set the command to run to be `x.py --json-output`

r? @Mark-Simulacrum -- feel free to make changes, this is quick and dirty for sure

…n-DPC

Expand on platform details of `include_xxx` macros

This is a small detail that is not explicitly mentioned, but it left me scratching my head for a while until I looked into its implementation details. Maybe worth mentioning.

… r=sfackler

Fix typo in u8::to_ascii_uppercase and u8::to_ascii_lowercase

Corrects misspelling of fifth.