Also stabilize constctlz for const ctlz_nonzero.
The public methods stabilized const by this commit are:
* `{i*,u*}::checked_pow`
* `{i*,u*}::saturating_pow`
* `{i*,u*}::wrapping_pow`
* `{i*,u*}::overflowing_pow`
* `{i*,u*}::pow`
* `u*::next_power_of_two`
* `u*::checked_next_power_of_two`
* `u*::wrapping_next_power_of_two` (the method itself is still unstable)
Insta-stabilize the methods `is_ipv4` and `is_ipv6` of `IpAddr`.
Possible because of the recent stabilization of const control flow.
Also adds a test for these methods in a const context.
Change `-Z fewer-names` into an optional boolean flag and allow using it
to either discard value names when true or retain them when false,
regardless of other settings.
This also required adding a loop guard in case clone panics
Add specialization for copy
There is a better version for copy, so I've added specialization for that function
and hopefully that should speed it up even more.
Switch FromIter<slice::Iter> to use `to_vec`
Test different unrolling version for to_vec
Revert to impl
From benchmarking, it appears this version is faster
BTreeMap: swap the names of NodeRef::new and Root::new_leaf
#78104 preserved the name of Root::new_leaf to minimize changes, but the resulting names are confusing.
r? `@Mark-Simulacrum`
Add test for eval order for a+=b
Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.
I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.
Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.
Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
BTreeMap: address namespace conflicts
Fix an annoyance popping up whenever synchronizing the test cases with a version capable of miri-track-raw-pointers.
r? `@Mark-Simulacrum`
Stabilize refcell_take
Tracking Issue: #71395
``@KodrAus`` nominated this for FCP, so here's a PR!
I've never made a stabilization PR, so please mention if there's anything I can improve, thanks.
Stabilize alloc::Layout const functions
Stabilizes #67521. In particular the following stable methods are stabilized as `const fn`:
* `size`
* `align`
* `from_size_align`
Stabilizing `size` and `align` should not be controversial as they are simple (usize and NonZeroUsize) fields and I don't think there's any reason to make them not const compatible in the future. That being true, the other methods are trivially `const`. The only other issue being returning a `Result` from a `const fn` but this has been made more usable by recent stabilizations.
Split each iterator adapter and source into individual modules
This PR creates individual modules for each iterator adapter and iterator source.
This is done to enhance the readability of corresponding modules (`adapters/mod.rs` and `sources.rs`) which were hard to navigate and read because of lots of repeated lines (e.g.: `adapters/mod.rs` was 3k lines long). This is also in line with some adapters which already had their own modules (`Flatten`, `FlatMap`, `Chain`, `Zip`, `Fuse`).
This PR also makes `Take`s adapter fields private (I have no idea why they were `pub(super)` before).
r? ``@LukasKalbertodt``
Add f{32,64}::is_subnormal
The docs recommend that you use dedicated methods instead of calling `classify` directly, although there isn't actually a way of checking if a number is subnormal without calling classify. There are dedicated methods for all other forms, excluding `is_zero` (which is just `== 0.0` anyway).
Consolidate exhaustiveness-related tests
I hunted for tests that only exercised the match exhaustiveness algorithm and regrouped them. I also improved integer-range tests since I had found them lacking while hacking around.
The interest is mainly so that one can pass `--test-args patterns` and catch most relevant tests.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
This gets rid of a bunch of `unwrap()`s and makes it a little more clear
what's going on.
Originally I wanted to make `fold_item` non-nullable too, which would
have been a lot nicer to work with, but unfortunately `stripper` does
actually return `None` in some places. I might make a follow-up moving
stripper to be special and not a pass so that passes can be
non-nullable.
Rollup of 4 pull requests
Successful merges:
- #78670 (Remove FIXME comment in some incremental test suite)
- #79292 (Fix typo in doc comment for report_too_many_hashes)
- #79300 (Prevent feature information to be hidden if it's on the impl directly)
- #79302 (Add regression test for issue 73899)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Small grammar, punctuation, and code style improvements to docs
changelog: Made small grammar, punctuation, and code style improvements to docs
I recently found some places in rust-lang/rust that had lists without spaces after commas, which led me to look for more places, which led me over here to find:
- Some similar lists in code examples that could use spaces after commas to be idiomatic Rust style
- Some lists in documentation text that didn't have spaces after commas, needed an Oxford comma (fight me), or were otherwise misformatted
- Some other grammar improvements in the area of the other changes
These changes should only be in user-facing documentation or output.
Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.
I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.
Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.
Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
Stabilize clamp
Tracking issue: https://github.com/rust-lang/rust/issues/44095
Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?
