This caused several performance regressions because of existing code
which uses `Read::read` and therefore requires full buffer
initialization. This is particularly a problem when the same buffer is
re-used for multiple read calls since this means it needs to be fully
re-initialized each time.
There is still some benefit to landing the API changes, but we will have
to add private APIs so that the existing infrastructure can
track and avoid redundant initialization.
test: update duplicate many_digits test to use f64 instead of f32
Replace the f32 test case with an f64 equivalent to improve coverage for parsing large digit counts in double-precision floating-point conversion. Specifically, this PR updates the `many_digits` test in `library/coretests/tests/num/dec2flt/parse.rs` to test f64 (double-precision) parsing instead of f32 (single-precision).
The test verifies that decimal strings with an excessive number of digits (beyond `Decimal::MAX_DIGITS`) are parsed correctly, ensuring proper truncation of insignificant digits. Previously, the same test was repeated twice (see comment https://github.com/rust-lang/rust/pull/86761#issuecomment-3623334228 by `@Viatorus).`
## Changes
- Replaced the duplicated f32 test case with an equivalent f64 test case.
- Updated the expected bit pattern and input string to a very long decimal with many trailing zeros, testing the limits of f64 precision.
Constify `DropGuard::dismiss` and trait impls
Feature: `drop_guard` (rust-lang/rust#144426), `const_convert` (rust-lang/rust#143773), `const_drop_guard` (no tracking issue yet)
Constifies `DropGuard::dismiss` and trait impls.
I reused `const_convert` (rust-lang/rust#143773) for the `Deref*` impls.
Additional test for uN::{gather,scatter}_bits
Feature gate: #![feature(uint_gather_scatter_bits)]
Tracking issue: https://github.com/rust-lang/rust/issues/149069
Accepted ACP: https://github.com/rust-lang/libs-team/issues/695#issuecomment-3549284861
Adds an additional runtime test for `uN::gather_bits` and `uN::scatter_bits` in coretests. They are each other's inverses in a sense, so a shared test can test both with relative ease.
I plan to follow up with optimized implementations for these functions.
Remove an outdated test
This... is a weird test.
It has two impls:
- `impl<T> From<Foo<T>> for Box<T>` (commented out, more on that later), and
- `impl<T> Into<Vec<T>> for Foo<T>`
The idea of that test is to show that the first impl doesn't compile, but the second does, thus `TryFrom` should be using `Into` and not `From` (because `Into` is more general, since the `From` impl doesn't compile).
However:
1. The types are different -- `Box` vs `Vec`, which is significant b/c `Box` is fundamental
2. The commented out impl actually compiles! (which wasn't detected b/c it's commented out :\ )
Here is a table for compilation of the impls:
| | `Vec` | `Box` |
|--------|--------------|----------------|
| `From` | since 1.41.0 | never |
| `Into` | always | not since 1.28 |
[godbolt used to test this](https://godbolt.org/z/T38E3jGKa)
Order of events:
1. in `1.28` the `incoherent_fundamental_impls` lint becomes deny by default (this is *not* mentioned in the changelog yay)
2. `1.32` changed absolutely nothing, even though this version is credited in the test
3. the test was added (I'm not exactly sure when) (see https://github.com/rust-lang/rust/pull/56796)
4. in `1.41` coherence was relaxed to allow `From`+`Vec` to compile
To conclude: since `1.41` this test does nothing (and before that it was written in a way which did not detect this change). It looks to me like today (since `1.41`) we *could* bound `TryFrom` impl with `From` (but now it'd be a useless breaking change of course).
Am I missing anything? Is there a useful version of this test that could be written?
Remove initialized-bytes tracking from `BorrowedBuf` and `BorrowedCursor`
As discussed extensively in libs-api, the initialized-bytes tracking primarily benefits calls to `read_buf` that end up initializing the buffer and calling `read`, at the expense of calls to `read_buf` that *don't* need to initialize the buffer. Essentially, this optimizes for the past at the expense of the future. If people observe performance issues using `read_buf` (or something that calls it) with a given `Read` impl, they can fix those performance issues by implementing `read_buf` for that `Read`.
Update the documentation to stop talking about initialized-but-unfilled bytes.
Remove all functions that just deal with those bytes and their tracking, and remove usage of those methods.
Remove `BorrowedCursor::advance` as there's no longer a safe case for advancing within initialized-but-unfilled bytes. Rename `BorrowedCursor::advance_unchecked` to `advance`.
Update tests.
r? ``@Amanieu``
As discussed extensively in libs-api, the initialized-bytes tracking
primarily benefits calls to `read_buf` that end up initializing the
buffer and calling `read`, at the expense of calls to `read_buf` that
*don't* need to initialize the buffer. Essentially, this optimizes for
the past at the expense of the future. If people observe performance
issues using `read_buf` (or something that calls it) with a given `Read`
impl, they can fix those performance issues by implementing `read_buf`
for that `Read`.
Update the documentation to stop talking about initialized-but-unfilled
bytes.
Remove all functions that just deal with those bytes and their tracking,
and remove usage of those methods.
Remove `BorrowedCursor::advance` as there's no longer a safe case for
advancing within initialized-but-unfilled bytes. Rename
`BorrowedCursor::advance_unchecked` to `advance`.
Update tests.
Rename `DropGuard::into_inner` to `DropGuard::dismiss`
Tracking issue: https://github.com/rust-lang/rust/issues/144426
One of the open questions blocking the stabilization of `DropGuard` is what to name the associated method that prevents the destructor from running, and returns the captured value. This method is currently called `into_inner`, but most people (including myself) feel like this would benefit from a method that calls more attention to itself.
This PR proposes naming this method `dismiss`, after the Linux kernel's [`ScopeGuard::dismiss`](https://rust.docs.kernel.org/kernel/types/struct.ScopeGuard.html#method.dismiss). Which crucially does not evoke images of violence or weaponry the way alternatives such as "disarm" or "defuse" do. And personally I enjoy the visual metaphor of "dismissing a guard" (e.g. a person keeping watch over something) - a job well done, they're free to go.
This PR also changes the signature from an static method to an instance method. This also matches the Linux kernel's API, and seems alright since `dismiss` is not nearly as ubiquitous as `into_inner`. This makes it more convenient to use, with a much lower risk of conflicting. Though in the rare case there might be ambiguity, the explicit notation is available as a fallback.
```rust
let x = DropGuard::into_inner(guard); // ← current
let x = guard.dismiss(); // ← proposed
Stabilize `maybe_uninit_write_slice`
Stabilize feature `maybe_uninit_write_slice` (closes https://github.com/rust-lang/rust/issues/79995).
Note that this also const-stabilizes `<[MaybeUninit<_>]>::write_copy_of_slice`. That method depends on `<[_]>::copy_from_slice`, which is already const-stable, and `<[MaybeUninit<_>]>::assume_init_mut` which is now also stable.
feat: Add `bit_width` for unsigned `NonZero<T>`
- Tracking issue: rust-lang/rust#142326
This pull request adds a method to the unsigned `NonZero<T>` that return the minimum number of bits required to represent a value.
This can be achieved by using the `get` method and the methods added in rust-lang/rust#142328, but I think adding the `NonZero::bit_width` method is useful because it accomplishes the same thing a little more succinctly.
819247f1 changed <str as Debug>::fmt such that it does not escape single
quotes, but neglected to apply the same choice to OsString. This commit
does that.
This PR reverts RUST-147622 for several reasons:
1. The RUST-147622 PR would format the generated core library code using
an arbitrary `rustfmt` picked up from `PATH`, which will cause
hard-to-debug failures when the `rustfmt` used to format the
generated unicode data code versus the `rustfmt` used to format the
in-tree library code.
2. Previously, the `unicode-table-generator` tests were not run under CI
as part of `coretests`, and since for `x86_64-gnu-aux` job we run
library `coretests` with `miri`, the generated tests unfortunately
caused an unacceptably large Merge CI time regression from ~2 hours
to ~3.5 hours, making it the slowest Merge CI job (and thus the new
bottleneck).
3. This PR also has an unintended effect of causing a diagnostic
regression (RUST-148387), though that's mostly an edge case not
properly handled by `rustc` diagnostics.
Given that these are three distinct causes with non-trivial fixes, I'm
proposing to revert this PR to return us to baseline. This is not
prejudice against relanding the changes with these issues addressed, but
to alleviate time pressure to address these non-trivial issues.
`unicode_data` refactors
Minor refactors to `unicode_data` that occured to me while trying to reduce the size of the tables. Splitting into a separate PR. NFC
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!
Amanieu d'Antras