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.
I spent a while debugging a strage linker error about an outdated `glibc` version, only to discover that it was caused by a stale `obj` directory. It wasn't obviously to be that using the same obj dir with multiple Docker images (for the same target triple) could be a problem.
This commit adds a note to the README, which should hopefully be helpful to anyone else who runs into this issue.
Rename `bool::then_*` to `bool::to_option_*` and use where appropriate
Name change following https://github.com/rust-lang/rfcs/pull/2757. Also try it out throughout the compiler in places I think makes the code more readable.
We now only propagate a scalar pair if the Rvalue is a tuple with two
scalars. This for example avoids propagating a (u8, u8) value when
Rvalue has type `((), u8, u8)` (see the regression test). While this is
a correct thing to do, implementation is tricky and will be done later.
Fixes#66971Fixes#66339Fixes#67019
Migrate to LLVM{Get,Set}ValueName2
The deprecated `LLVM{Get,Set}ValueName` only work with NUL-terminated
strings, but the `2` variants use explicit lengths, which fits better
with Rust strings and slices. We now use these in new helper functions
`llvm::{get,set}_value_name` that convert to/from `&[u8]`.
Closes#64223.
r? @rkruppe
SGX: Fix target linker used by bootstrap
Bootstrap, for some reason, overrides the target linker. This is not correct for x86_64-fortanix-unknown-sgx. Add such targets to the list of exceptions.
r? @alexcrichton
Remove potential cfgs duplicates
Fixes https://github.com/rust-lang/rust/issues/66921.
Before going any further (the issue seems to be linked to metadata as far as I can tell). Do you think this is the good place to do it or should it be done before?
r? @eddyb
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.
The polonius output has one more error which should be displayed
in the regular case, but error reporting in the regular case stopped
at the first error.
Admittedly it would be nice to combine suggestions for the same source
lifetime so that `'a: 'b` and `'a: 'c` are not bothsuggested, but instead
a single `'a: 'b + 'c` is.
