This commit applies rustfmt with default settings to files in
src/libcore *that are not involved in any currently open PR* to minimize
merge conflicts. The list of files involved in open PRs was determined
by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in `outstanding_files`, the
relevant commands were:
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libcore.
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Use variant names rather than descriptions for identifying desugarings in `#[rustc_on_unimplemented]`.
Both are highly unstable, but variant name is at least a single identifier.
Forward formatter settings to bounds of `Range<T>` in `fmt::Debug` impl
Before this change, formatter settings were lost when printing a `Range`. For example, printing a `Range<f32>` with `{:.2?}` would not apply the precision modifier when printing the floats. Now the `Debug` impls look a bit more verbose, but modifier are not lost.
---
I assume the exact output of `Debug` impls in `std` cannot be relied on by users and thus can change, right?
Added documentation on the remainder (Rem) operator for floating points.
# Description
As has been explained in #57738 the remainder operator on floating points is not clear.
This PR requests adds some information on how the `Rem` / remainder operator on floating points works.
Note also that this description is for both `Rem<f32> for f32` and `Rem<f64> for f64` implementations.
Ps. I wasn't really sure on how to formulate things. So please suggest changes if you have better idea's!
closes#57738
Before this change, formatter settings were lost when printing a
`Range`. For example, printing a `Range<f32>` with `{:.2?}` would not
apply the precision modifier when printing the floats. Now the `Debug`
impls look a bit more verbose, but modifier are not lost.
consistent naming for Rhs type parameter in libcore/ops
Rename RHS type parameter occurrences RHS->Rhs to make it consistent throughout files and follow naming conventions.
Stabilize Range*::contains.
Closes https://github.com/rust-lang/rust/issues/32311. There's also a bit of rustfmt on range.rs thrown in for good measure (I forgot to turn off format-on-save in VSCode).
RangeInclusive internal iteration performance improvement.
Specialize `Iterator::try_fold` and `DoubleEndedIterator::try_rfold` to improve code generation in all internal iteration scenarios.
This changes brings the performance of internal iteration with `RangeInclusive` on par with the performance of iteration with `Range`:
- Single conditional jump in hot loop,
- Unrolling and vectorization,
- And even Closed Form substitution.
Unfortunately, it only applies to internal iteration. Despite various attempts at stream-lining the implementation of `next` and `next_back`, LLVM has stubbornly refused to optimize external iteration appropriately, leaving me with a choice between:
- The current implementation, for which Closed Form substitution is performed, but which uses 2 conditional jumps in the hot loop when optimization fail.
- An implementation using a `is_done` boolean, which uses 1 conditional jump in the hot loop when optimization fail, allowing unrolling and vectorization, but for which Closed Form substitution fails.
In the absence of any conclusive evidence as to which usecase matters most, and with no assurance that the lack of Closed Form substitution is not indicative of other optimizations being foiled, there is no way
to pick one implementation over the other, and thus I defer to the statu quo as far as `next` and `next_back` are concerned.
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
Specialize Iterator::try_fold and DoubleEndedIterator::try_rfold to
improve code generation in all internal iteration scenarios.
This changes brings the performance of internal iteration with
RangeInclusive on par with the performance of iteration with Range:
- Single conditional jump in hot loop,
- Unrolling and vectorization,
- And even Closed Form substitution.
Unfortunately, it only applies to internal iteration. Despite various
attempts at stream-lining the implementation of next and next_back,
LLVM has stubbornly refused to optimize external iteration
appropriately, leaving me with a choice between:
- The current implementation, for which Closed Form substitution is
performed, but which uses 2 conditional jumps in the hot loop when
optimization fail.
- An implementation using a "is_done" boolean, which uses 1
conditional jump in the hot loop when optimization fail, allowing
unrolling and vectorization, but for which Closed Form substitution
fails.
In the absence of any conclusive evidence as to which usecase matters
most, and with no assurance that the lack of Closed Form substitution
is not indicative of other optimizations being foiled, there is no way
to pick one implementation over the other, and thus I defer to the
statu quo as far as next and next_back are concerned.
