Unstable `gen_future` Feature Tracking
This PR removes the reference to the closed tracking issue **#50547** for the `gen_future` feature. Since `gen_future` is an internal feature used in async block desugaring, it does not require a public tracking issue.
#### Changes:
- Replaced `issue = "50547"` with `issue = "none"` in **library/core/src/future/mod.rs**.
- Ensures that it is correctly identified as an internal feature.
#### Rationale:
With this change, the Unstable Book will now state:
> *"This feature has no tracking issue and is therefore likely internal to the compiler, not being intended for general use."*
Closes **#76249**. 🚀🦀
Fixed issue with usage of generics and moved feature gate to crate root
Removed const tag
Fixed alphabetical ordering of feature gate, added same to doctest
Removed crate-level declaration of feature gate control_flow_into_value
Used const_precise_live_drops to constify into_value without issue of a drop
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic
LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that.
Suggested by `@hanna-kruppe` in https://github.com/rust-lang/rust/issues/136459; Cc `@tgross35`
try-job: test-various
Add #[track_caller] to Duration Div impl
Previously the location of the divide-by-zero error condition would be attributed to the code in the rust standard library, eg:
thread 'main' panicked at /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/time.rs:1172:31:
divide by zero error when dividing duration by scalar
With #[track_caller] the error is correctly attributed to the callee.
libcore/net: `IpAddr::as_octets()`
[ACP](https://github.com/rust-lang/libs-team/issues/535)
[Tracking issue](https://github.com/rust-lang/rust/issues/137259)
Adds `const` `core::net::IpAddr{,v4,v6}::as_octets()` methods to provide reference access to IP address contents.
The concrete usecase for me is allowing the `IpAddr` to provide an extended lifetime in contexts that want a `&[u8]`:
```rust
trait AddrSlice {
fn addr_slice(&self) -> &[u8];
}
impl AddrSlice for IpAddrV4 {
fn addr_slice(&self) -> &[u8] {
// self.octets() doesn't help us here, because we can't return a reference to the owned array.
// Instead we want the IpAddrV4 to continue owning the memory:
self.as_octets()
}
}
```
(Notably, in this case we can't parameterize `AddrSlice` by a `const N: usize` (such that `fn addr_slice(&self) -> [u8; N]`) and maintain object-safety.)
Optionally add type names to `TypeId`s.
This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation.
It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)
Example usage and output:
```
fn main() {
use std::any::{Any, TypeId};
dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```
```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```
Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.
Related issues:
* #68379
* #61533
Stabilize `num_midpoint_signed` feature
This PR proposes that we stabilize the signed variants of [`iN::midpoint`](https://github.com/rust-lang/rust/issues/110840#issue-1684506201), the operation is equivalent to doing `(a + b) / 2` in a sufficiently large number.
The stabilized API surface would be:
```rust
/// Calculates the middle point of `self` and `rhs`.
///
/// `midpoint(a, b)` is `(a + b) / 2` as if it were performed in a
/// sufficiently-large signed integer type. This implies that the result is
/// always rounded towards zero and that no overflow will ever occur.
impl i{8,16,32,64,128,size} {
pub const fn midpoint(self, rhs: Self) -> Self;
}
```
T-libs-api previously stabilized the unsigned (and float) variants in #131784, the signed variants were left out because of the rounding that should be used in case of negative midpoint.
This stabilization proposal proposes that we round towards zero because:
- it makes the obvious `(a + b) / 2` in a sufficiently-large number always true
- using another rounding for the positive result would be inconsistent with the unsigned variants
- it makes `midpoint(-a, -b)` == `-midpoint(a, b)` always true
- it is consistent with `midpoint(a as f64, b as f64) as i64`
- it makes it possible to always suggest `midpoint` as a replacement for `(a + b) / 2` expressions *(which we may want to do as a future work given the 21.2k hits on [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%5C%28%5Ba-zA-Z_%5D*+%5C%2B+%5Ba-zA-Z_%5D*%5C%29+%5C%2F+2%2F&type=code&p=1))*
`@scottmcm` mentioned a drawback in https://github.com/rust-lang/rust/pull/132191#issuecomment-2439891200:
> I'm torn, because rounding towards zero makes it "wider" than other values, which `>> 1` avoids -- `(a + b) >> 1` has the nice behaviour that `midpoint(a, b) + 2 == midpoint(a + 2, b + 2)`.
>
> But I guess overall sticking with `(a + b) / 2` makes sense as well, and I do like the negation property 🤷
Which I think is outweigh by the advantages cited above.
Closes#110840
cc `@rust-lang/libs-api`
cc `@scottmcm`
r? `@dtolnay`
Implement accepted ACP for functions that isolate the most significant
set bit and least significant set bit on unsigned, signed, and NonZero
integers.
Add function `isolate_most_significant_one`
Add function `isolate_least_significant_one`
Add tests
Use more explicit and reliable ptr select in sort impls
Using `if ...` with the intent to avoid branches can be surprising to readers and carries the risk of turning into jumps/branches generated by some future compiler version, breaking crucial optimizations.
This commit replaces their usage with the explicit and IR annotated `bool::select_unpredictable`.
Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants
This pull request adds the `MAX_LEN_UTF8` and `MAX_LEN_UTF16` constants as per #45795, gated behind the `char_max_len` feature.
The constants are currently applied in the `alloc`, `core` and `std` libraries.
Adds `const` `Ip*Addr::as_octets` methods providing reference access to
`Ip*Addr` octets contents.
See https://github.com/rust-lang/libs-team/issues/535 for accepted ACP
with a more detailed justification.
fix docs for inherent str constructors
related to #131114
when implementing inherent str constructors in #136517, i forgot to change the docs, so the code examples still imported the `std::str` module and used the constructor from there, instead of using "itself" (the inherent constructor).
Make ub_check message clear that it's not an assert
I've seen a user assume that their unsound code was *safe*, because ub_check prevented the program from performing the unsafe operation.
This PR makes the panic message clearer that ub_check is a bug detector, not run-time safety protection.
Previously the location of the divide-by-zero error condition would be
attributed to the code in the rust standard library, eg:
thread 'main' panicked at /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/time.rs:1172:31:
divide by zero error when dividing duration by scalar
With #[track_caller] the error is correctly attributed to the callee.
