Move `std::io::ErrorKind` to `core::io`
* Update `rustdoc-html` tests for the new path
* Add `core_io` feature to control stability. This replaces the use of `core_io_borrowed_buf` on the `core::io` module itself.
* Re-export `core::io::ErrorKind` in `std::io::error`
deprecate `std::char` constants and functions
similar to how constants in those modules for numeric types have been deprecated. The `std::char` module contains:
Three stable constants that this PR deprecates. These already link to their associated constant equivalents.
- `MAX`
- `REPLACEMENT_CHARACTER`
- `UNICODE_VERSION`
two unstable constants that this PR removes. The constants are already stablized as associated constants on `char`.
- `MAX_LEN_UTF8`
- `MAX_LEN_UTF16`
Four stable functions that this PR deprecates. These already link to their method equivalents.
- `fn decode_utf16`
- `fn from_digit`
- `fn from_u32`
- `fn from_u32_unchecked⚠`
discussion at [#t-libs > should `std::char::{MIN, MAX}` be deprecated?](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/should.20.60std.3A.3Achar.3A.3A.7BMIN.2C.20MAX.7D.60.20be.20deprecated.3F/with/579444750).
r? libs-api
`impl Default for RepeatN`
This creates an empty iterator, like `repeat_n(value, 0)` but without
needing any such value at hand. There's precedent in many other
iterators that the `Default` is empty, like `slice::Iter`.
I found myself wanting this for rayon's `RepeatN` as it lowers to a
sequential iterator [here][1]. Since rayon is also optimizing to avoid
extra clones, it may end up with parallel splits that have count 0 and
no item value. Calling `std::iter::repeat_n(x, 0)` just drops that
value, but there's no way to construct the same result without a value
yet. This would be straightforward with an empty `Default`.
[1]: https://github.com/rayon-rs/rayon/blob/ae07384e3e0b238cea89f0c14891f351c65a5cee/src/iter/repeat.rs#L201-L202
r? libs-api (insta-stable)
Add `TryFromIntError::kind` method and `IntErrorKind::NotAPowerOfTwo` variant
- ACP: rust-lang/libs-team#746
- Tracking issue: rust-lang/rust#153978
This pull request adds `kind` method to [`TryFromIntError`](https://doc.rust-lang.org/core/num/struct.TryFromIntError.html), which outputs the detailed cause of converting an integer failing.
This is primarily intended for use in cases where there are multiple causes for failure, such as converting from a large signed integer type to a small signed integer type.
At the moment, this method returns [`&IntErrorKind`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html). This type implements the `Copy` trait and could return `IntErrorKind`, but returns a reference to align with the behavior of [`ParseIntError::kind`](https://doc.rust-lang.org/core/num/struct.ParseIntError.html#method.kind). If it is not necessary to align the behavior of `TryFromIntError::kind` with `ParseIntError::kind`, I'll change this method to return `IntErrorKind`.
Before this pull request, `IntErrorKind` was only used by [`ParseIntError`](https://doc.rust-lang.org/core/num/struct.ParseIntError.html), but I changed it to be used by `TryFromIntError` as well, so I updated `IntErrorKind`'s documentation.
[`impl TryFrom<usize> for Alignment`](https://doc.rust-lang.org/std/ptr/struct.Alignment.html#impl-TryFrom%3Cusize%3E-for-Alignment) returns `TryFromIntError` as an error if the given value is not a power of two. However, `IntErrorKind` does not have a variant that represents this. So I added the variant `NotAPowerOfTwo` to represent this. For this variant to stabilize, both `try_from_int_error_kind` and `ptr_alignment_type` features must be stabilized.
This creates an empty iterator, like `repeat_n(value, 0)` but without
needing any such value at hand. There's precedent in many other
iterators that the `Default` is empty, like `slice::Iter`.
I found myself wanting this for rayon's `RepeatN` as it lowers to a
sequential iterator [here][1]. Since rayon is also optimizing to avoid
extra clones, it may end up with parallel splits that have count 0 and
no item value. Calling `std::iter::repeat_n(x, 0)` just drops that
value, but there's no way to construct the same result without a value
yet. This would be straightforward with an empty `Default`.
[1]: https://github.com/rayon-rs/rayon/blob/ae07384e3e0b238cea89f0c14891f351c65a5cee/src/iter/repeat.rs#L201-L202
coretests: add argument order regression tests for min_by/max_by/minmax_by
PR rust-lang/rust#136307 introduced a regression in min_by, max_by, and minmax_by:
the compare closure received arguments as (v2, v1) instead of (v1, v2),
contrary to the documented contract.
Although this was fixed in rust-lang/rust#139357, no regression tests were added.
This PR adds regression tests for all three functions, verifying that compare
always receives arguments in the documented order (v1, v2).
As a bonus: first coretests coverage for minmax_by.
`BorrowedCursor`: make `init` a boolean
This PR changes uninitialized bytes tracking in `BorrowedBuf` from being byte-wise to being buffer-wise.
I've put all the API around `init` a new unstable feature `borrowed_buf_init`, to split the part that needs it and the part that doesn't. It will avoids accidental stabilization of this part.
I'm not really convinced of the rename of `advance_unchecked` to `advance`, but I did it anyway. The old `advance` was kept as `advance_checked`.
Alternative of rust-lang/rust#148937
Cc rust-lang/rust#78485rust-lang/rust#117693
Cc @joshtriplett
r? @Amanieu
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#147552 ([Debugger Visualizers] Optimize lookup behavior)
- rust-lang/rust#154052 (float: Fix panic at max exponential precision)
- rust-lang/rust#154706 (fix compilation of time/hermit.rs)
- rust-lang/rust#154707 (Make `substr_range` and `subslice_range` return the new `Range` type)
- rust-lang/rust#154767 (triagebot: roll library reviewers for `{coretests,alloctests}`)
- rust-lang/rust#154797 (bootstrap: Include shorthand aliases in x completions)
float: Fix panic at max exponential precision
Rust's formatting machinery allows precision values of up to u16::MAX. Exponential formatting works out the number of significant digits to use by adding one (for the integral digit before the decimal point).
This previously used usize precision, so the maximum validated precision did not overflow, but in commit fb9ce02976 ("Limit formatting width and precision to 16 bits.") the precision type was narrowed to u16 without widening that addition first.
As a result an exponential precision value of 65535 is no longer handled correctly, because the digit count wraps to 0, and thus "{:.65535e}" panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits > 0". Other formats (and the parser) accept values up to u16::MAX.
A naive fix would be to widen that addition back to usize, but that still does not properly address 16-bit targets, where usize is only guaranteed to be able to represent values up to u16::MAX. The real issue is that this internal API is expressed in the wrong units for the formatter.
Fix this by changing exact exponential formatting to take fractional digits internally as well, and compute the temporary significant digit bound only when sizing the scratch buffer. To support that let's also make formatted length accounting saturate so that extremely large rendered outputs do not reintroduce overflows in padding logic.
This preserves the existing intent and keeps FormattingOptions compact while making formatting work consistently again.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#149868 (rustc: Stop passing `--allow-undefined` on wasm targets)
- rust-lang/rust#153555 (Clarified docs in std::sync::RwLock + added test to ensure that max reader count is respected)
- rust-lang/rust#152851 (Fix SGX delayed host lookup via ToSocketAddr)
- rust-lang/rust#154051 (use libm for acosh and asinh)
- rust-lang/rust#154581 (More informative `Debug for vec::ExtractIf`)
- rust-lang/rust#154461 (Edit the docs new_in() and with_capacity_in())
- rust-lang/rust#154526 (Panic/return false on overflow in no_threads read/try_read impl)
- rust-lang/rust#154798 (rustdoc-search: match path components on words)
Rust's formatting machinery allows precision values of up to u16::MAX.
Exponential formatting works out the number of significant digits to use
by adding one (for the integral digit before the decimal point).
This previously used usize precision, so the maximum validated precision
did not overflow, but in commit fb9ce02976 ("Limit formatting width
and precision to 16 bits.") the precision type was narrowed to u16
without widening that addition first.
As a result an exponential precision value of 65535 is no longer handled
correctly, because the digit count wraps to 0, and thus "{:.65535e}"
panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits >
0". Other formats (and the parser) accept values up to u16::MAX.
A naive fix would be to widen that addition back to usize, but that
still does not properly address 16-bit targets, where usize is only
guaranteed to be able to represent values up to u16::MAX. The real issue
is that this internal API is expressed in the wrong units for the
formatter.
Fix this by changing exact exponential formatting to take fractional
digits internally as well, and compute the temporary significant digit
bound only when sizing the scratch buffer. To support that let's also
make formatted length accounting saturate so that extremely large
rendered outputs do not reintroduce overflows in padding logic.
This preserves the existing intent and keeps FormattingOptions compact
while making formatting work consistently again.
A recent regression swapped the argument order passed to the compare
closure in min_by, max_by and minmax_by (compare(&v2, &v1) instead of
compare(&v1, &v2)). This was fixed, but no regression test was added.
Add tests that record the arguments the compare closure receives and
assert they match (v1, v2) — the documented contract.
Implement Step for NonZero unsigned integers as discussed in
[libs-team#130][1].
[1]: https://github.com/rust-lang/libs-team/issues/130
`step_nonzero_impls` was adapted from `step_integer_impls` and the tests
were adapted from the step tests.
Signed-off-by: Jalil David Salamé Messina <jalil.salame@gmail.com>
stabilizes `core::range::Range`
stabilizes `core::range::RangeIter`
stabilizes `std::range` which was missed in prior PRs
Updates docs to reflect stabilization (removed "experimental")
`RangeIter::remainder` is excluded from stabilization
Don't fuse in `MapWindows`
cc https://github.com/rust-lang/rust/issues/87155
Fusing makes the iterator larger, slower, more complicated, and less useful. Users who need fusing behavior can always use `.fuse()`, but there is no way to get non-fusing behavior from the fused version.
@rustbot label A-iterators
Also, delete impls on non-Deref types.
Pin doesn't do anything useful for non-Deref types, so PinCoerceUnsized
on such types makes no sense.
This is a breaking change, since stable code can observe the deleted
`PinCoerceUnsized` impls by uselessly coercing between such types
inside a `Pin`.
There is still some strange behavior, such as `Pin<&mut i32>` being
able to coerce to `Pin<&dyn Send>`, but not being able to coerce to
`Pin<&i32>`. However, I don't think it's possible to fix this.
Fixes https://github.com/rust-lang/rust/issues/145081
constify const Fn*: Destruct
makes closures const destruct where their upvars are. i think this makes sense
and is how this should be implemented.
r? @oli-obk
Add APIs for dealing with titlecase
ACP: https://github.com/rust-lang/libs-team/issues/354
Tracking issue: https://github.com/rust-lang/rust/issues/153892
r? libs-api
@rustbot label T-libs -T-libs-api A-unicode
~~The last commit has some insta-stable `PartialEq` impls, therefore: @rustbot label -needs-fcp
Alternatively, I could split those out into a follow-up PR.~~ (Edit: will do in follow-up)
Lifted intersperse and intersperse_with Fused transformation and updated documentation + tests
This PR once again builds on top of rust-lang/rust#152855. From the discussion in rust-lang/rust#152855, libs team came to the conclusion that `intersperse`/`intersperse_with` shouldn't transform the given iterator to a fused iterator always and a separator should be emitted between `Some(_)` items for non fused iterators (particularly just right before the subsequent `Some(_)`).
On top of the change Zakarumych added in the PR, I lifted the `FusedIterator` trait and transformation of the inner `iter` for `Intersperse`/`IntersperseWith`, so that we can display this behavior. I've adjusted the documentation and tests accordingly to reflect this change as well.
r? @jhpratt
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.
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
Jacob Pratt