Add `{f32,f64}::approx_unchecked_to<Int>` unsafe methods
As discussed in https://github.com/rust-lang/rust/issues/10184
Currently, casting a floating point number to an integer with `as` is Undefined Behavior if the value is out of range. `-Z saturating-float-casts` fixes this soundness hole by making `as` “saturate” to the maximum or minimum value of the integer type (or zero for `NaN`), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an `unsafe fn` alternative for users who know through some other mean that their values are in range.
<del>The “fit” wording is copied from https://llvm.org/docs/LangRef.html#fptoui-to-instruction, but I’m not certain what it means exactly. Presumably this is after rounding towards zero, and the doc-test with `i8::MIN` seems to confirm this.</del> Clang presumably uses those LLVM intrinsics to implement C and C++ casts, whose respective standard specify that the value *after truncating to keep its integral part* must be representable in the target type.
As discussed in https://github.com/rust-lang/rust/issues/10184
Currently, casting a floating point number to an integer with `as` is Undefined Behavior if the value is out of range. `-Z saturating-float-casts` fixes this soundness hole by making `as` “saturate” to the maximum or minimum value of the integer type (or zero for `NaN`), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an `unsafe fn` alternative for users who know through some other mean that their values are in range.
Make const-qualification look at more `const fn`s
As explained in a lot more detail in #67053 this makes const-qualification not ignore the unstable const fns in libcore.
r? @oli-obk cc @ecstatic-morse
(Still a bit unsure about the `cfg`s here, for bootstrapping, does that seem correct ?)
Fixes#67053.
Add `enclosing scope` parameter to `rustc_on_unimplemented`
Adds a new parameter to `#[rustc_on_unimplemented]`, `enclosing scope`, which highlights the function or closure scope with a message.
The wip part refers to adding this annotation to `Try` trait to improve ergonomics (which I don't know how to do since I change both std and librustc)
Closes#61709.
Layout::pad_to_align is infallible
As per [this comment](https://github.com/rust-lang/rust/issues/55724#issuecomment-441421651) (cc @glandium).
> Per eb981a1/src/libcore/alloc.rs (L63-L65), `layout.size()` is always <= `usize::MAX - (layout.align() - 1)`.
>
> Which means:
>
> * The maximum value `layout.size()` can have is already aligned for `layout.align()` (`layout.align()` being a power of two, `usize::MAX - (layout.align() - 1)` is a multiple of `layout.align()`)
> * Incidentally, any value smaller than that maximum value will align at most to that maximum value.
>
> IOW, `pad_to_align` can not return `Err(LayoutErr)`, except for the layout not respecting its invariants, but we shouldn't care about that.
This PR makes `pad_to_align` return `Layout` directly, representing the fact that it cannot fail.
libunwind_panic: adjust miri panic hack
We adjust the Miri hack in libpanic_unwind such that even with `cfg(miri)`, we build a version of libpanic_unwind that actually works.
This is needed to resolve https://github.com/integer32llc/rust-playground/issues/548.
r? @oli-obk @alexcrichton
Remove unneeded prelude imports in libcore tests
These three lines are from c82da7a54b dating back to 2015.
They cause problems when applying rustfmt to the codebase, because reordering wildcard imports can trigger new unused import warnings.
As a minimized example, the following program compiles successfully:
```rust
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use std::prelude::v1::*;
use super::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
```
but putting it through rustfmt produces a program that fails to compile:
```rust
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use super::*;
use std::prelude::v1::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
```
The error is:
```console
error: unused import: `std::prelude::v1::*`
--> src/main.rs:8:9
|
8 | use std::prelude::v1::*;
| ^^^^^^^^^^^^^^^^^^^
```
Make python-generated source files compatible with rustfmt
This PR adjusts the generators for src/libcore/num/dec2flt/table.rs, src/libcore/unicode/printable.rs, and src/libcore/unicode/tables.rs to make it so running `rustfmt` on the generated files no longer needs to apply any changes.
This involves tweaking the python scripts where reasonable to better match rustfmt's style, and adding `#[rustfmt::skip]` to big constant tables that there's no point having rustfmt rewrap.
r? @Dylan-DPC
Atomic as_mut_ptr
I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type).
It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477
Transmuting the pointer directly:
```rust
let atomic = AtomicI32::new(1);
let ptr = &atomic as *const AtomicI32 as *mut i32;
unsafe {
ffi(ptr);
}
```
A dance with `UnsafeCell`:
```rust
let atomic = AtomicI32::new(1);
unsafe {
let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get();
ffi(ptr);
}
```
Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library?
An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race."
The standard library could make use this method in a few places in the WASM module.
cc @RalfJung as you answered my original question.
These three lines are from c82da7a54b in
2015.
They cause problems when applying rustfmt to the codebase, because
reordering wildcard imports can trigger new unused import warnings.
As a minimized example, the following program compiles successfully:
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use std::prelude::v1::*;
use super::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
but putting it through rustfmt produces a program that fails to compile:
#![deny(unused_imports)]
use std::fmt::Debug;
use std::marker::Send;
pub mod repro {
use super::*;
use std::prelude::v1::*;
pub type D = dyn Debug;
pub type S = dyn Send;
}
pub type S = dyn Send;
The error is:
error: unused import: `std::prelude::v1::*`
--> src/main.rs:8:9
|
8 | use std::prelude::v1::*;
| ^^^^^^^^^^^^^^^^^^^
Clarify `{f32,f64}::EPSILON` docs
The doc for `EPSILON` says:
> This is the difference between `1.0` and the next **largest** representable number.
Which is a bit unclear.
[Wikipedia](https://en.wikipedia.org/wiki/Machine_epsilon) says
> Machine epsilon is defined as the difference between 1 and the next **larger** floating point number
So this PR update the docs to match the Wikipedia version.
The original PR also has this in a [comment](https://github.com/rust-lang/rust/pull/50919#discussion_r192600209).
Panic machinery comments and tweaks
This is mostly more comments, but I also renamed some things:
* `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
* `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points.
r? @Dylan-DPC @SimonSapin
Implement Debug for MaybeUninit
Precedent: `UnsafeCell` implements `Debug` even though it can't actually display the value. I noticed this omission while writing the following:
```
#[derive(Debug)]
pub struct SliceInitializer<'a, T> {
marker: PhantomData<&'a mut T>,
uninit: &'a mut [MaybeUninit<T>],
written: usize,
}
```
...which currently unergonomically fails to compile.
`UnsafeCell` does require `T: Debug`. Because of things like the above I think it'd be better to leave that requirement off. In fact, I'd also suggest removing that requirement for `UnsafeCell` too, which again I noticed in some low-level real world code.
