| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Be more direct about borrow contract
I always was confused by the difference between Borrow and AsRef, despite the fact that I've read all available docs at least a dozen of times.
I finally grokked the difference between the two when I realized the Borrow invariant:
> If you implement Borrow, you **must** make sure that Eq, Ord and Hash implementations are equivalent for borrowed and owned data
My problem was that this invariant is not stated explicitly in documentation, and instead some vague and philosophical notions are used.
So I suggest to mention the requirements of `Borrow` very explicitly: instead of "use Borrow when X and use AsRef when Y", let's phrase this as `Borrow` differs from `AsRef` in `W`, so that's why `Borrow` is for `X` and `AsRef` is for `Y`.
Note that this change could be seen as tightening contract of the Borrow. Let's say Alice has written the following code:
```rust
#[derive(PartialEq, Eq, Hash, PartialOrd, Ord)]
struct Person {
first_name: String,
last_name: String,
}
impl Borrow<str> for Person {
fn borrow(&self) -> &str { self.first_name.as_str() }
}
```
Now Bob uses this `Person` struct, puts it into `HashMap` and tries to look it up using `&str` for the first name. Bob's code naturally fails.
The question is, who is to blame: Alice, who has written the impl, or Bob, who uses the HashMap. If I read the current docs literally, I would say that `Bob` is to blame: `Eq` and `Hash` bounds appear on HashMap, so it is the HashMap which requires that they are consistent. By using a type for which the `Borrow` impl does not yield well-behaved `Eq`, Bob is violating contract of HashMap.
If, as this PR proposes, we unconditionally require that Eq & friends for borrow should be valid, then the blame shifts to Alice, which I think is more reasonable.
closes https://github.com/rust-lang/rust/issues/44868
|
|
|
|
core::sync::spin_loop_hint
|
|
|
|
Add 'partition_at_index/_by/_by_key' for slices.
This is an analog to C++'s std::nth_element (a.k.a. quickselect).
Corresponds to tracking bug #55300.
|
|
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
|
|
Implement useful steps_between for all integers
We can use `usize::try_from` to convert steps from any size of integer.
This enables a meaningful `size_hint()` for larger ranges, rather than
always just `(0, None)`. Now they return the true `(len, Some(len))`
when it fits, otherwise `(usize::MAX, None)` for overflow.
|
|
Remove duplicated code from Iterator::{ne, lt, le, gt, ge}
This PR delegates `Iterator::ne` to `Iterator::eq` and `Iterator::{lt, le, gt, ge}` to `Iterator::partial_cmp`.
Oddly enough, this change actually simplifies the generated assembly [in some cases](https://rust.godbolt.org/z/riBtNe), although I don't understand assembly well enough to see if the longer assembly is doing something clever.
I also added two extremely simple benchmarks:
```
// before
test iter::bench_lt ... bench: 98,404 ns/iter (+/- 21,008)
test iter::bench_partial_cmp ... bench: 62,437 ns/iter (+/- 5,009)
// after
test iter::bench_lt ... bench: 61,757 ns/iter (+/- 8,770)
test iter::bench_partial_cmp ... bench: 62,151 ns/iter (+/- 13,753)
```
I have no idea why the current `lt`/`le`/`gt`/`ge` implementations don't seem to be compiled optimally, but simply having them call `partial_cmp` seems to be an improvement.
See #44729 for a previous discussion.
|
|
and added a comment with the solution.
|
|
closes #56286
|
|
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.
|
|
Stabilize refcell_replace_swap feature
Please be kind, this is my first time contributing. :smile:
I noticed #43570 only needs stabilizing (and I need it for a side project I'm working on), so I followed the [guide](https://rust-lang.github.io/rustc-guide/stabilization_guide.html#stabilization-pr) to move things forward.
I'm happy to amend things if needed, let me know!
|
|
|
|
|
|
|
|
values is computed internally.
|
|
This was incorrectly copypasta'd from RepeatWith.
|
|
|
|
ffi: rename VaList::copy to VaList::with_copy
Rename `VaList::copy` to `VaList::with_copy`
r? @joshtriplett
|
|
Add FromStr impl for NonZero types
This is a WIP implementation because I do have some questions regarding the solution.
Somebody should ping the lang team on this I guess.
Please see the annotations on the code for more details.
Closes #58604
|
|
Rollup of 12 pull requests
Successful merges:
- #57987 (Fix some AArch64 typos)
- #58581 (Refactor generic parameter encoder functions)
- #58803 (fs::copy() unix: set file mode early)
- #58848 (Prevent cache issues on version updates)
- #59198 (Do not complain about unmentioned fields in recovered patterns)
- #59351 (Include llvm-ar with llvm-tools component)
- #59413 (HirIdify hir::ItemId)
- #59441 (Remove the block on natvis for lld-link.)
- #59448 (Use consistent phrasing for all macro summaries)
- #59456 (Add documentation about `for` used as higher ranked trait bounds)
- #59472 (Document that `std::io::BufReader` discards contents on drop)
- #59474 (Fix link capitalization in documentation of std::io::BufWriter.)
Failed merges:
r? @ghost
|
|
Use consistent phrasing for all macro summaries
None
|
|
Fix some AArch64 typos
cc @dlrobertson
|
|
Moves test::black_box to core::hint and fix black_box on wasm32 and asm.js
This changes removes a cyclic dependency between the "test" and "libtest"
crates, where "libtest" depends on "test" for "black_box", but "test" depends on
"libtest" for everything else.
I've chosen the "hint" module because there seems to be enough consensus in the
discussion of RFC2360 that this module is where such an intrinsic would belong,
but this PR does not implement that RFC! If that RFC ever gets merged, the API, docs,
etc. of this API will need to change. This PR just move the implementation of the
already existing API.
For backwards compatibility reasons I've chosen to also keep the "test" feature
gate for these instead of adding a new feature gate. If we change the feature
gate, we'll potentially all benchmarks, and while that's something that we could
do, it seems unnecessary to do that now - if RFC2360 gets merged, we'll need to
do that anyways. Backwards compatibility is also why we continue to re-export
"black_box" from the "test" crate.
This PR also fixes black_box on the wasm32 target, which now supports inline assembly, and uses volatile loads on the asm.js target.
r? @Amanieu (cc @rust-lang/libs)
|
|
Refactor tuple comparison tests
|
|
Make `ptr::eq` documentation mention fat-pointer behavior
Resolves #59214
|
|
add rustfix-able suggestions to trim_{left,right} deprecations
Fixes #53802 (technically already fixed by #58002, but that issue is about these methods).
|
|
adjust MaybeUninit API to discussions
uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
|
|
Make ASCII case conversions more than 4× faster
Reformatted output of `./x.py bench src/libcore --test-args ascii` below. The `libcore` benchmark calls `[u8]::make_ascii_lowercase`. `lookup` has code (effectively) identical to that before this PR, and ~~`branchless`~~ `mask_shifted_bool_match_range` after this PR.
~~See [code comments](https://github.com/rust-lang/rust/pull/59283/commits/ce933f77c865a15670855ac5941fe200752b739f#diff-01076f91a26400b2db49663d787c2576R3796) in `u8::to_ascii_uppercase` in `src/libcore/num/mod.rs` for an explanation of the branchless algorithm.~~
**Update:** the algorithm was simplified while keeping the performance. See `branchless` v.s. `mask_shifted_bool_match_range` benchmarks.
Credits to @raphlinus for the idea in https://twitter.com/raphlinus/status/1107654782544736261, which extends this algorithm to “fake SIMD” on `u32` to convert four bytes at a time. The `fake_simd_u32` benchmarks implements this with [`let (before, aligned, after) = bytes.align_to_mut::<u32>()`](https://doc.rust-lang.org/std/primitive.slice.html#method.align_to_mut). Note however that this is buggy when addition carries/overflows into the next byte (which does not happen if the input is known to be ASCII).
This could be fixed (to optimize `[u8]::make_ascii_lowercase` and `[u8]::make_ascii_uppercase` in `src/libcore/slice/mod.rs`) either with some more bitwise trickery that I didn’t quite figure out, or by using “real” SIMD intrinsics for byte-wise addition. I did not pursue this however because the current (incorrect) fake SIMD algorithm is only marginally faster than the one-byte-at-a-time branchless algorithm. This is because LLVM auto-vectorizes the latter, as can be seen on https://rust.godbolt.org/z/anKtbR.
Benchmark results on Linux x64 with Intel i7-7700K: (updated from https://github.com/rust-lang/rust/pull/59283#issuecomment-474146863)
```rust
6830 bytes string:
alloc_only ... bench: 112 ns/iter (+/- 0) = 62410 MB/s
black_box_read_each_byte ... bench: 1,733 ns/iter (+/- 8) = 4033 MB/s
lookup_table ... bench: 1,766 ns/iter (+/- 11) = 3958 MB/s
branch_and_subtract ... bench: 417 ns/iter (+/- 1) = 16762 MB/s
branch_and_mask ... bench: 401 ns/iter (+/- 1) = 17431 MB/s
branchless ... bench: 365 ns/iter (+/- 0) = 19150 MB/s
libcore ... bench: 367 ns/iter (+/- 1) = 19046 MB/s
fake_simd_u32 ... bench: 361 ns/iter (+/- 2) = 19362 MB/s
fake_simd_u64 ... bench: 361 ns/iter (+/- 1) = 19362 MB/s
mask_mult_bool_branchy_lookup_table ... bench: 6,309 ns/iter (+/- 19) = 1107 MB/s
mask_mult_bool_lookup_table ... bench: 4,183 ns/iter (+/- 29) = 1671 MB/s
mask_mult_bool_match_range ... bench: 339 ns/iter (+/- 0) = 20619 MB/s
mask_shifted_bool_match_range ... bench: 339 ns/iter (+/- 1) = 20619 MB/s
32 bytes string:
alloc_only ... bench: 15 ns/iter (+/- 0) = 2133 MB/s
black_box_read_each_byte ... bench: 29 ns/iter (+/- 0) = 1103 MB/s
lookup_table ... bench: 24 ns/iter (+/- 4) = 1333 MB/s
branch_and_subtract ... bench: 16 ns/iter (+/- 0) = 2000 MB/s
branch_and_mask ... bench: 16 ns/iter (+/- 0) = 2000 MB/s
branchless ... bench: 16 ns/iter (+/- 0) = 2000 MB/s
libcore ... bench: 15 ns/iter (+/- 0) = 2133 MB/s
fake_simd_u32 ... bench: 17 ns/iter (+/- 0) = 1882 MB/s
fake_simd_u64 ... bench: 16 ns/iter (+/- 0) = 2000 MB/s
mask_mult_bool_branchy_lookup_table ... bench: 42 ns/iter (+/- 0) = 761 MB/s
mask_mult_bool_lookup_table ... bench: 35 ns/iter (+/- 0) = 914 MB/s
mask_mult_bool_match_range ... bench: 16 ns/iter (+/- 0) = 2000 MB/s
mask_shifted_bool_match_range ... bench: 16 ns/iter (+/- 0) = 2000 MB/s
7 bytes string:
alloc_only ... bench: 14 ns/iter (+/- 0) = 500 MB/s
black_box_read_each_byte ... bench: 22 ns/iter (+/- 0) = 318 MB/s
lookup_table ... bench: 16 ns/iter (+/- 0) = 437 MB/s
branch_and_subtract ... bench: 16 ns/iter (+/- 0) = 437 MB/s
branch_and_mask ... bench: 16 ns/iter (+/- 0) = 437 MB/s
branchless ... bench: 19 ns/iter (+/- 0) = 368 MB/s
libcore ... bench: 20 ns/iter (+/- 0) = 350 MB/s
fake_simd_u32 ... bench: 18 ns/iter (+/- 0) = 388 MB/s
fake_simd_u64 ... bench: 21 ns/iter (+/- 0) = 333 MB/s
mask_mult_bool_branchy_lookup_table ... bench: 20 ns/iter (+/- 0) = 350 MB/s
mask_mult_bool_lookup_table ... bench: 19 ns/iter (+/- 0) = 368 MB/s
mask_mult_bool_match_range ... bench: 19 ns/iter (+/- 0) = 368 MB/s
mask_shifted_bool_match_range ... bench: 19 ns/iter (+/- 0) = 368 MB/s
```
|
|
Add suggestion to use `&*var` when `&str: From<String>` is expected
Fix #53879.
|
|
|
|
|
|
|
|
Link to PhantomData in NonNull documentation
|
|
r=steveklabnik
Improve the documentation for std::convert (From, Into, AsRef and AsMut)
# Description
In this PR I updated the documentation of From, Into, AsRef and AsMut, as well as the general std::convert module documentation. The discussion in #59163 provided information that was not yet present in the docs, or was not expressed clearly enough. I tried to clarify the examples that were already present in the docs as well as add more information about considered best-practices that came out of the discussion in #59163
@steveklabnik I hope I didn't change too much. This is an initial version! I will scan through everything tomorrow as well again to see if I made any typo's or errors, and maybe make some small changes here and there.
All suggestions are welcome!
closes #59163
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #59150 (Expand suggestions for type ascription parse errors)
- #59232 (Merge `Promoted` and `Static` in `mir::Place`)
- #59267 (Provide suggestion when using field access instead of path)
- #59315 (Add no_hash to query macro and move some queries over)
- #59334 (Update build instructions in README.md)
- #59362 (Demo `FromIterator` short-circuiting)
- #59374 (Simplify checked_duration_since)
- #59389 (replace redundant note in deprecation warning)
- #59410 (Clarify `{Ord,f32,f64}::clamp` docs a little)
- #59419 (Utilize `?` instead of `return None`.)
Failed merges:
r? @ghost
|
|
We can use `usize::try_from` to convert steps from any size of integer.
This enables a meaningful `size_hint()` for larger ranges, rather than
always just `(0, None)`. Now they return the true `(len, Some(len))`
when it fits, otherwise `(usize::MAX, None)` for overflow.
|
|
|
|
|
|
|
|
|
|
uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
|
|
Utilize `?` instead of `return None`.
None
|
|
Clarify `{Ord,f32,f64}::clamp` docs a little
Explicitly call out when it returns NaN, adhere to the panic doc
guidelines.
|
|
Demo `FromIterator` short-circuiting
while looking at a FIXME in `FromIterator for Option` and `FromIterator for Result`, I realized that the current documentation does not have example code showing exactly what is meant by "no further elements are taken."
The code snippets provided here are meant to correct that.
|
|
|
|
|
|
|
|
|
