coretests: Expand ieee754 parsing and printing tests to f16
Use `float_test!` to cover all types, with a note about f128 missing the traits. Also includes some minor reorganization.
two smaller feature cleanups
Remove an unneeded feature gate for a private macro and sort the used features correctly by whether they are language or library features.
Derive Macro Eq: link to more detailed documentation
Match the other derive macros in the module (Ord, PartialEq, PartialOrd) by linking to the section in the trait documentation about how the derive macro works.
Add is_disconnected functions to mpsc and mpmc channels
Add `is_disconnected()` functions to the `Sender` and `Receiver` of both `mpmc` an `mpsc` channels.
```rust
std::sync::mpmc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpmc::Receiver<T>::is_disconnected(&self) -> bool
std::sync::mpsc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpsc::Receiver<T>::is_disconnected(&self) -> bool
```
The `mpsc` methods are locked behind the `mpsc_is_disconnected` feature gate, which has no tracking issue yet.
ACP: https://github.com/rust-lang/libs-team/issues/748
Tracking issue: https://github.com/rust-lang/rust/issues/153668
Split the `dec2flt::RawFloat` trait for easier reuse
`RawFloat` is an internal trait with quite a few useful float properties. It currently resides in the `dec2flt` module but is also used in parsing, and would be nice to reuse other places. Unfortunately it cannot be implemented on `f128` because of limitations with how the parsing API is implemented (mantissa must fit into a u64).
To make the trait easier to work with, split it into the following:
* `Float`: Anything that is reasonably applicable to all floating point types.
* `FloatExt`: Items that should be part of `Float` but don't work for all float types. This will eventually be merged back into `Float` once it can be implemented on f128.
* `Lemire`: Items that are specific to the Lemire dec2flt algorithm.
These traits are then moved to places that make sense.
Builds on top of https://github.com/rust-lang/rust/pull/151900
Optimize 128-bit integer formatting
The compiler is unaware of the restricted range of the input, so it is unable to optimize out the final division and modulus. By doing this manually, we get a nontrivial performance gain.
r? @dtolnay
(copied from https://github.com/dtolnay/itoa/pull/68)
Add `Wake` diagnostic item for `alloc::task::Wake`
The symbol will be defined in Clippy, as Clippy will be the sole user of the diagnostic item so far.
Fix bootstrap rust build failure for vxworks
Fixesrust-lang/rust#153332
Starting with VxWorks 25.09, struct stat was updated to use struct timespec instead of time_t for timestamp fields.
The following changes were made in libc in the commit [libc](https://github.com/rust-lang/libc/pull/4781).
As a result, when performing a bootstrap build with VxWorks ≥ 25.09, libc no longer exposes the fields st_mtime, st_atime, and st_ctime, as they are conditionally compiled in src/vxworks/mod.rs here [libc](https://github.com/rust-lang/libc/blob/56caa81b6b433c49c5704bf0400a02d428cfacda/src/vxworks/mod.rs#L229). This causes the build to fail.
For VxWorks versions earlier than 25.09, the build completes successfully without errors.
This PR resolves the issue by detecting the WIND_RELEASE_ID environment variable (which is set in the VxWorks build environment) and conditionally guarding the affected functions in the two additional files where the errors originate.
Add missing `track_caller` to overflowing trait methods
Fixesrust-lang/rust#152599 by adding `#[track_caller]` to arithmetic trait methods (`Neg`, `Shl`, `ShlAssign`, `Shr` and `ShrAssign`) so overflow panics report the correct call site instead of the trait definition.
The compiler is unaware of the restricted range of the input, so it is
unable to optimize out the final division and modulus. By doing this
manually, we get a nontrivial performance gain.
Remove string content from panics
String content can be useful for debugging panics, particularly when you are working on a small codebase where you can infer more about the path taken through your program based on the content of the string.
In production deployments that upload crashes for centralized debugging, string content poses a risk to user privacy. The string can accidentally contain information that the user is not expecting to share with the development team.
On balance it seems like the risks outweigh the benefits. It is easy to add a `dbg!()` statement to gather more information in development; but comparatively tricky to ensure panics are sanitized by every rust app that monitors their production deployments.
Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067
r? @scottmcm
std: make `OsString::truncate` a no-op when `len > current_len`
Align `OsString::truncate` (and the underlying WTF-8 implementation) with `String::truncate` by making it a no-op when `len > self.len()`.
Previously, `OsString::truncate` would panic if `len > self.len()`, while `String::truncate` treats such cases as a no-op.
Tracking (`os_string_truncate`): https://github.com/rust-lang/rust/issues/133262
See also: https://github.com/rust-lang/rust/pull/32977
cc: @alexcrichton, @lolbinarycat
Add `From` impls for wrapper types
- ~`From<T: Copy> for ManuallyDrop<T>`~
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
- `From<T> for ThinBox<T>` (unstable)
- `From<T> for UniqueRc<T>` (unstable)
- `From<T> for UniqueArc<T>` (unstable)
@rustbot label T-libs-api needs-fcp
Also needs a crater run, as the insta-stable impls are technically breaking changes.
Gate `ConstParamTy_` trait behind `const_param_ty_trait` feature
Initially even when user wasn't using unsized const params, the only way to implement/name `ConstParamTy_` was to use `#![feature(unsized_const_params]`, now its gated under `const_param_ty_trait` feature, implied by `unsized_const_params`.
I've also changed use of `unsized_const_params` in tests which were using it only to implement `ConstParamTy_` without using unsized
r? BoxyUwU
Add overview documentation for `std::mem`.
I heard that `std::mem` sounds scary to some people, and how it’s described — “Basic functions for dealing with memory” — sounds even to me like something that should be avoided, not even because it would be unsafe, but because it is too low-level.
Let’s fix that by telling people about what they can actually find in the module, without having to read all the individual item descriptions.
The exact contents of the list are, of course, highly debatable, and I chose not to include any of the unstable or deprecated items, nor to include `Discriminant` as well as `discriminant`. I’m also not particularly happy with the wording of the introductory paragraph.
- `From<T> for ThinBox<T>`
- `From<T> for UniqueRc<T>`
- `From<T> for UniqueArc<T>`
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
We do handle signaling NaNs properly, with the exception of raising
exceptions as IEEE 754 requires. Add tests to this effect for
`fmin`, `fminimum`, `fminimum_num`, and the max variants.
Give more descriptive output in tests since we sometimes need to treat
these differently. We still don't parse `sNaN`/`qNaN` for now, though we
could in the future.
Make `Float::NAN` a qNaN, add sNaNs, and add operations to check whether
a NaN is quiet or signaling.
The MIPS values are checked against https://gcc.godbolt.org/z/1bhsd5ana.
`Float` and `FloatExt` are already used by both parsing and printing, so
move them out of `dec2flt` to a new module in `num::imp`. `Int` `Cast`
have the potential to be used more places in the future, so move them
there as well. `Lemire` is the only remaining trait; since it is small,
move it into the `dec2flt` root.
The `fmt::LowerExp` bound is removed from `Float` here since the trait
is moving into a module without `#[cfg(not(no_fp_fmt_parse))]` and it
isn't implemented with that config (it's not easily possible to add
`cfg` attributes to a single supertrait, unfortunately). This isn't a
problem since it isn't actually being used.
`RawFloat` is currently used specifically for the implementation of the
lemire algorithm, but it is useful for more than that. Split it into
three different traits:
* `Float`: Anything that is reasonably applicable to all floating point
types.
* `FloatExt`: Items that should be part of `Float` but don't work for
all float types. This will eventually be merged back into `Float`.
* `Lemire`: Items that are specific to the Lemire algorithm.
I heard that `std::mem` sounds scary to some people, and how it’s
described — “Basic functions for dealing with memory” — sounds even to
me like something that should be avoided, not even because it would be
unsafe, but because it is too low-level.
Let’s fix that by telling people about what they can actually find in
the module, without having to read all the individual item descriptions.
Fix grammar in Pin documentation
Changed "has an address-sensitive" to "has address-sensitive states" in the `Drop` implementation section of the documentation of `Pin` thereby making it grammatically complete.
core: remove FIXME comment in option.rs FromIterator
The referenced issue rust-lang/rust#11084 was closed in 2021, and the related PR rust-lang/rust#59605 was not merged due to inconclusive results. Similar code (in result.rs, for example) doesn't have this FIXME comment; this is the only reference to issue 11084 (or pull request 59605).
This FIXME was not mentioned in issue rust-lang/rust#44366.
Add missing safety doc for CString::from_vec_unchecked and async_drop_in_place
Add missing safety documentation for two unsafe APIs:
* `CString::from_vec_unchecked` – # Safety: the caller must ensure `v` contains no NUL bytes in its contents.
* `async_drop_in_place` – # Safety: see [`ptr::drop_in_place`] for safety requirements.
Jonathan Brouwer