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
`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.
In `Option::get_or_insert_with()`, forget the `None` instead of dropping it.
Per https://github.com/rust-lang/rust/pull/148486#issuecomment-3493665688
In `Option::get_or_insert_with()`, after replacing the `None` with `Some`, forget the `None` instead of dropping it.
This allows eliminating the `T: [const] Destruct` bounds, making the functions more flexible in (unstable) const contexts, and avoids generating an implicit `drop_in_place::<Option<T>>()` that will never do anything (and which might even persist after optimization).
Unicode data: reduce size of to_lower/to_upper tables
Reduces the combined size of to_lower and to_upper from 25,364 bytes to 3,110 bytes. Explained in detail in the doc comments
core: respect precision in `ByteStr` `Display`
Fixesrust-lang/rust#153022.
`ByteStr`'s `Display` implementation didn't respect the precision parameter. Just like `Formatter::pad`, this is fixed by counting off the characters in the string and truncating after the requested length – with the added complication that the `ByteStr` needs to be divided into chunks first. By including a fast path that avoids counting the characters when no parameters were specified this should also fix the performance regressions caused by rust-lang/rust#152865.
Instead of generating a standalone executable to test `unicode_data`,
generate normal tests in `coretests`. This ensures tests are always
generated, and will be run as part of the normal testsuite.
Also change the generated tests to loop over lookup tables, rather than
generating a separate `assert_eq!()` statement for every codepoint. The
old approach produced a massive (20,000 lines plus) file which took
minutes to compile!
num: Separate public API from internal implementations
Currently we have a single `core::num` module that contains both thin wrapper API and higher-complexity numeric routines. Restructure this by moving implementation details to a new `imp` module.
This results in a more clean separation of what is actually user-facing compared to items that have a stability attribute because they are public for testing.
The first commit does the actual change then the second moves a portion back.
Ralf Jung