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.
Stabilize const for integer {to,from}_{be,le,ne}_bytes methods
All of these functions can be implemented simply and naturally as const functions, e.g. `u32::from_le_bytes` can be implemented as
```rust
(bytes[0] as u32)
| (bytes[1] as u32) << 8
| (bytes[2] as u32) << 16
| (bytes[3] as u32) << 24
```
So stabilizing the constness will not expose that internally they are implemented using transmute which is not const in stable.
Stabilize assoc_int_consts associated int/float constants
The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325.
* Stabilize all constants under the `assoc_int_consts` feature flag.
* Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred.
* Update documentation examples to use new constants.
* Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway.
r? @LukasKalbertodt
Make `u8::is_ascii` a stable `const fn`
`char::is_ascii` was already stabilized as `const fn` in #55278, so there is no reason for `u8::is_ascii` to go through an unstable period.
cc @rust-lang/libs
All of these functions can be implemented simply and naturally as
const functions, e.g. u32::from_le_bytes can be implemented as
(bytes[0] as u32)
| (bytes[1] as u32) << 8
| (bytes[2] as u32) << 16
| (bytes[3] as u32) << 24
So stabilizing the constness will not expose that internally they are
implemented using transmute which is not const in stable.
Make integer exponentiation methods unstably const
cc #53718
This makes the following inherent methods on integer primitives into unstable `const fn`:
- `pow`
- `checked_pow`
- `wrapping_pow`
- `overflowing_pow`
- `saturating_pow`
- `next_power_of_two`
- `checked_next_power_of_two`
- `wrapping_next_power_of_two`
Only two changes were made to the implementation of these methods. First, I had to switch from the `?` operator, which is not yet implemented in a const context, to a `try_opt` macro. Second, `next_power_of_two` was using `ops::Add::add` (see the first commit) to "get overflow checks", so I switched to `#[rustc_inherit_overflow_checks]`. I'm not quite sure why the attribute wasn't used in the first place.
The contents were always UTF-8 anyway, and &str has an equivalent representation
to &[u8], so this should not affect performance while removing unsafety at
edges.
It may be worth exploring a further adjustment that stores a single byte
(instead of 16) as the contents are always "", "-", or "+".
Move numeric consts to associated consts step1
A subset of #67913. Implements the first step of RFC https://github.com/rust-lang/rfcs/pull/2700
This PR adds the new constants as unstable constants and defines the old ones in terms of the new ones. Then fix a tiny bit of code that started having naming collisions because of the new assoc consts.
Removed a test that did not seem relevant any longer. Since doing just `u8::MIN` should now indeed be valid.
