| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 7 pull requests
Successful merges:
- #83568 (update comment at MaybeUninit::uninit_array)
- #83571 (Constantify some slice methods)
- #83579 (Improve pointer arithmetic docs)
- #83645 (Wrap non-pre code blocks)
- #83656 (Add a regression test for issue-82865)
- #83662 (Update books)
- #83667 (Suggest box/pin/arc ing receiver on method calls)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve pointer arithmetic docs
* Add slightly more detailed definition of "allocated object" to the module docs, and link it from everywhere.
* Clarify the "remains attached" wording a bit (at least I hope this is clearer).
* Remove the sentence about using integer arithmetic; this seems to confuse people even if it is technically correct.
As usual, the edit needs to be done in a dozen places to remain consistent, I hope I got them all.
|
|
Constantify some slice methods
Tracking issue: #83570
This PR constantifies the following functions under feature `const_slice_first_last`:
- `slice::first`
- `slice::split_first`
- `slice::last`
- `slice::split_last`
Blocking on `#![feature(const_mut_refs)]`:
- `slice::first_mut`
- `slice::split_first_mut`
- `slice::last_mut`
- `slice::split_last_mut`
|
|
update comment at MaybeUninit::uninit_array
https://github.com/rust-lang/rust/issues/49147 is closed; this now instead needs inline const expressions (#76001).
|
|
Clean up Vec's benchmarks
The Vec benchmarks need a lot of love. I sort of noticed this in https://github.com/rust-lang/rust/pull/83357 but the overall situation is much less awesome than I thought at the time. The first commit just removes a lot of asserts and does a touch of other cleanup.
A number of these benchmarks are poorly-named. For example, `bench_map_fast` is not in fact fast, `bench_rev_1` and `bench_rev_2` are vague, `bench_in_place_zip_iter_mut` doesn't call `zip`, `bench_in_place*` don't do anything in-place... Should I fix these, or is there tooling that depend on the names not changing?
I've also noticed that `bench_rev_1` and `bench_rev_2` are remarkably fragile. It looks like poking other code in `Vec` can cause the codegen of this benchmark to switch to a version that has almost exactly half its current throughput and I have absolutely no idea why.
Here's the fast version:
```asm
0.69 │110: movdqu -0x20(%rbx,%rdx,4),%xmm0
1.76 │ movdqu -0x10(%rbx,%rdx,4),%xmm1
0.71 │ pshufd $0x1b,%xmm1,%xmm1
0.60 │ pshufd $0x1b,%xmm0,%xmm0
3.68 │ movdqu %xmm1,-0x30(%rcx)
14.36 │ movdqu %xmm0,-0x20(%rcx)
13.88 │ movdqu -0x40(%rbx,%rdx,4),%xmm0
6.64 │ movdqu -0x30(%rbx,%rdx,4),%xmm1
0.76 │ pshufd $0x1b,%xmm1,%xmm1
0.77 │ pshufd $0x1b,%xmm0,%xmm0
1.87 │ movdqu %xmm1,-0x10(%rcx)
13.01 │ movdqu %xmm0,(%rcx)
38.81 │ add $0x40,%rcx
0.92 │ add $0xfffffffffffffff0,%rdx
1.22 │ ↑ jne 110
```
And the slow one:
```asm
0.42 │9a880: movdqa %xmm2,%xmm1
4.03 │9a884: movq -0x8(%rbx,%rsi,4),%xmm4
8.49 │9a88a: pshufd $0xe1,%xmm4,%xmm4
2.58 │9a88f: movq -0x10(%rbx,%rsi,4),%xmm5
7.02 │9a895: pshufd $0xe1,%xmm5,%xmm5
4.79 │9a89a: punpcklqdq %xmm5,%xmm4
5.77 │9a89e: movdqu %xmm4,-0x18(%rdx)
15.74 │9a8a3: movq -0x18(%rbx,%rsi,4),%xmm4
3.91 │9a8a9: pshufd $0xe1,%xmm4,%xmm4
5.04 │9a8ae: movq -0x20(%rbx,%rsi,4),%xmm5
5.29 │9a8b4: pshufd $0xe1,%xmm5,%xmm5
4.60 │9a8b9: punpcklqdq %xmm5,%xmm4
9.81 │9a8bd: movdqu %xmm4,-0x8(%rdx)
11.05 │9a8c2: paddq %xmm3,%xmm0
0.86 │9a8c6: paddq %xmm3,%xmm2
5.89 │9a8ca: add $0x20,%rdx
0.12 │9a8ce: add $0xfffffffffffffff8,%rsi
1.16 │9a8d2: add $0x2,%rdi
2.96 │9a8d6: → jne 9a880 <<alloc::vec::Vec<T,A> as core::iter::traits::collect::Extend<&T>>::extend+0xd0>
```
|
|
Reduce the impact of Vec::reserve calls that do not cause any allocation
I think a lot of callers expect `Vec::reserve` to be nearly free when no resizing is required, but unfortunately that isn't the case. LLVM makes remarkably poor inlining choices (along the path from `Vec::reserve` to `RawVec::grow_amortized`), so depending on the surrounding context you either get a huge blob of `RawVec`'s resizing logic inlined into some seemingly-unrelated function, or not enough inlining happens and/or the actual check in `needs_to_grow` ends up behind a function call. My goal is to make the codegen for `Vec::reserve` match the mental that callers seem to have: It's reliably just a `sub cmp ja` if there is already sufficient capacity.
This patch has the following impact on the serde_json benchmarks: https://github.com/serde-rs/json-benchmark/tree/ca3efde8a5b75ff59271539b67452911860248c7 run with `cargo +stage1 run --release -- -n 1024`
Before:
```
DOM STRUCT
======= serde_json ======= parse|stringify ===== parse|stringify ====
data/canada.json 340 MB/s 490 MB/s 630 MB/s 370 MB/s
data/citm_catalog.json 460 MB/s 540 MB/s 1010 MB/s 550 MB/s
data/twitter.json 330 MB/s 840 MB/s 640 MB/s 630 MB/s
======= json-rust ======== parse|stringify ===== parse|stringify ====
data/canada.json 580 MB/s 990 MB/s
data/citm_catalog.json 720 MB/s 660 MB/s
data/twitter.json 570 MB/s 960 MB/s
```
After:
```
DOM STRUCT
======= serde_json ======= parse|stringify ===== parse|stringify ====
data/canada.json 330 MB/s 510 MB/s 610 MB/s 380 MB/s
data/citm_catalog.json 450 MB/s 640 MB/s 970 MB/s 830 MB/s
data/twitter.json 330 MB/s 880 MB/s 670 MB/s 960 MB/s
======= json-rust ======== parse|stringify ===== parse|stringify ====
data/canada.json 560 MB/s 1130 MB/s
data/citm_catalog.json 710 MB/s 880 MB/s
data/twitter.json 530 MB/s 1230 MB/s
```
That's approximately a one-third increase in throughput on two of the benchmarks, and no effect on one (The benchmark suite has sufficient jitter that I could pick a run where there are no regressions, so I'm not convinced they're meaningful here).
This also produces perf increases on the order of 3-5% in a few other microbenchmarks that I'm tracking. It might be useful to see if this has a cascading effect on inlining choices in some large codebases.
Compiling this simple program demonstrates the change in codegen that causes the perf impact:
```rust
fn main() {
reserve(&mut Vec::new());
}
#[inline(never)]
fn reserve(v: &mut Vec<u8>) {
v.reserve(1234);
}
```
Before:
```rust
00000000000069b0 <scratch::reserve>:
69b0: 53 push %rbx
69b1: 48 83 ec 30 sub $0x30,%rsp
69b5: 48 8b 47 08 mov 0x8(%rdi),%rax
69b9: 48 8b 4f 10 mov 0x10(%rdi),%rcx
69bd: 48 89 c2 mov %rax,%rdx
69c0: 48 29 ca sub %rcx,%rdx
69c3: 48 81 fa d1 04 00 00 cmp $0x4d1,%rdx
69ca: 77 73 ja 6a3f <scratch::reserve+0x8f>
69cc: 48 81 c1 d2 04 00 00 add $0x4d2,%rcx
69d3: 72 75 jb 6a4a <scratch::reserve+0x9a>
69d5: 48 89 fb mov %rdi,%rbx
69d8: 48 8d 14 00 lea (%rax,%rax,1),%rdx
69dc: 48 39 ca cmp %rcx,%rdx
69df: 48 0f 47 ca cmova %rdx,%rcx
69e3: 48 83 f9 08 cmp $0x8,%rcx
69e7: be 08 00 00 00 mov $0x8,%esi
69ec: 48 0f 47 f1 cmova %rcx,%rsi
69f0: 48 85 c0 test %rax,%rax
69f3: 74 17 je 6a0c <scratch::reserve+0x5c>
69f5: 48 8b 0b mov (%rbx),%rcx
69f8: 48 89 0c 24 mov %rcx,(%rsp)
69fc: 48 89 44 24 08 mov %rax,0x8(%rsp)
6a01: 48 c7 44 24 10 01 00 movq $0x1,0x10(%rsp)
6a08: 00 00
6a0a: eb 08 jmp 6a14 <scratch::reserve+0x64>
6a0c: 48 c7 04 24 00 00 00 movq $0x0,(%rsp)
6a13: 00
6a14: 48 8d 7c 24 18 lea 0x18(%rsp),%rdi
6a19: 48 89 e1 mov %rsp,%rcx
6a1c: ba 01 00 00 00 mov $0x1,%edx
6a21: e8 9a fe ff ff call 68c0 <alloc::raw_vec::finish_grow>
6a26: 48 8b 7c 24 20 mov 0x20(%rsp),%rdi
6a2b: 48 8b 74 24 28 mov 0x28(%rsp),%rsi
6a30: 48 83 7c 24 18 01 cmpq $0x1,0x18(%rsp)
6a36: 74 0d je 6a45 <scratch::reserve+0x95>
6a38: 48 89 3b mov %rdi,(%rbx)
6a3b: 48 89 73 08 mov %rsi,0x8(%rbx)
6a3f: 48 83 c4 30 add $0x30,%rsp
6a43: 5b pop %rbx
6a44: c3 ret
6a45: 48 85 f6 test %rsi,%rsi
6a48: 75 08 jne 6a52 <scratch::reserve+0xa2>
6a4a: ff 15 38 c4 03 00 call *0x3c438(%rip) # 42e88 <_GLOBAL_OFFSET_TABLE_+0x490>
6a50: 0f 0b ud2
6a52: ff 15 f0 c4 03 00 call *0x3c4f0(%rip) # 42f48 <_GLOBAL_OFFSET_TABLE_+0x550>
6a58: 0f 0b ud2
6a5a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
```
After:
```asm
0000000000006910 <scratch::reserve>:
6910: 48 8b 47 08 mov 0x8(%rdi),%rax
6914: 48 8b 77 10 mov 0x10(%rdi),%rsi
6918: 48 29 f0 sub %rsi,%rax
691b: 48 3d d1 04 00 00 cmp $0x4d1,%rax
6921: 77 05 ja 6928 <scratch::reserve+0x18>
6923: e9 e8 fe ff ff jmp 6810 <alloc::raw_vec::RawVec<T,A>::reserve::do_reserve_and_handle>
6928: c3 ret
6929: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
```
|
|
unix: Fix feature(unix_socket_ancillary_data) on macos and other BSDs
This adds support for CMSG handling on macOS and fixes it on OpenBSD and possibly other BSDs.
When traversing the CMSG list, the previous code had an exception for Android where the next element after the last pointer could point to the first pointer instead of NULL. This is actually not specific to Android: the `libc::CMSG_NXTHDR` implementation for Linux and emscripten have a special case to return NULL when the length of the previous element is zero; most other implementations simply return the previous element plus a zero offset in this case.
This MR makes the check non-optional which fixes CMSG handling and a possible endless loop on such systems; tested with file descriptor passing on OpenBSD, Linux, and macOS.
This MR additionally adds `SocketAncillary::is_empty` because clippy is right that it should be added.
This belongs to the `feature(unix_socket_ancillary_data)` tracking issue: https://github.com/rust-lang/rust/issues/76915
r? `@joshtriplett`
|
|
escape_ascii take 2
The previous PR, #73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one.
I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this.
r? ``@m-ou-se``
|
|
alloc: Added `as_slice` method to `BinaryHeap` collection
I initially asked about whether it is useful addition on https://internals.rust-lang.org/t/should-i-add-as-slice-method-to-binaryheap/13816, and it seems there were no objections, so went ahead with this PR.
> There is [`BinaryHeap::into_vec`](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.into_vec), but it consumes the value. I wonder if there is API design limitation that should be taken into account. Implementation-wise, the inner buffer is just a Vec, so it is trivial to expose as_slice from it.
Please, guide me through if I need to add tests or something else.
UPD: Tracking issue #83659
|
|
|
|
ffi::c_str removed bound checks on as_bytes, to_bytes
This removes bound checks on CString::as_bytes() and CStr::to_bytes() and adds test.
|
|
|
|
|
|
|
|
may not -> might not
may not -> might not
"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."
In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)
This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.
This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
|
|
Adjust documentation links for slice::make_ascii_*case
The documentation for the functions `slice::to_ascii_lowercase` and `slice::to_ascii_uppercase` contain the suggestion
> To lowercase the value in-place, use `make_ascii_lowercase`
however the link to the suggested method takes you to the page for `u8`, rather than the method of that name on the same page.
|
|
Fixes API soundness issue in join()
Fixes #80335
|
|
Instruct LLVM that binary_search returns a valid index
This allows removing bound checks when the return value of `binary_search` is used to index into the slice it was call on. I also added a codegen test for this, not sure if it's the right thing to do (I didn't find anything on the dev guide), but it felt so.
|
|
"may not" has two possible meanings:
1. A command: "You may not stay up past your bedtime."
2. A fact that's only sometimes true: "Some cities may not have bike lanes."
In some cases, the meaning is ambiguous: "Some cars may not have snow
tires." (do the cars *happen* to not have snow tires, or is it
physically impossible for them to have snow tires?)
This changes places where the standard library uses the "description of
fact" meaning to say "might not" instead.
This is just `std::vec` for now - if you think this is a good idea I can
convert the rest of the standard library.
|
|
Add #[inline] to io::Error methods
Fixes #82812
|
|
Improve fs error open_from unix
Consistency for #79399
Suggested by JohnTitor
r? `@JohnTitor`
Not user if the error is too long now, do we handle long errors well?
|
|
Add function core::iter::zip
This makes it a little easier to `zip` iterators:
```rust
for (x, y) in zip(xs, ys) {}
// vs.
for (x, y) in xs.into_iter().zip(ys) {}
```
You can `zip(&mut xs, &ys)` for the conventional `iter_mut()` and
`iter()`, respectively. This can also support arbitrary nesting, where
it's easier to see the item layout than with arbitrary `zip` chains:
```rust
for ((x, y), z) in zip(zip(xs, ys), zs) {}
for (x, (y, z)) in zip(xs, zip(ys, zs)) {}
// vs.
for ((x, y), z) in xs.into_iter().zip(ys).zip(xz) {}
for (x, (y, z)) in xs.into_iter().zip((ys.into_iter().zip(xz)) {}
```
It may also format more nicely, especially when the first iterator is a
longer chain of methods -- for example:
```rust
iter::zip(
trait_ref.substs.types().skip(1),
impl_trait_ref.substs.types().skip(1),
)
// vs.
trait_ref
.substs
.types()
.skip(1)
.zip(impl_trait_ref.substs.types().skip(1))
```
This replaces the tuple-pair `IntoIterator` in #78204.
There is prior art for the utility of this in [`itertools::zip`].
[`itertools::zip`]: https://docs.rs/itertools/0.10.0/itertools/fn.zip.html
|
|
update array missing `IntoIterator` msg
fixes #82602
r? ```@estebank``` do you know whether we can use the expr span in `rustc_on_unimplemented`? The label isn't too great rn
|
|
make unaligned_references future-incompat lint warn-by-default
and also remove the safe_packed_borrows lint that it replaces.
`std::ptr::addr_of!` has hit beta now and will hit stable in a month, so I propose we start fixing https://github.com/rust-lang/rust/issues/27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed, this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an `unsafe` block should make any difference here.
For references to packed fields outside `unsafe` blocks, this means `unaligned_refereces` replaces the previous `safe_packed_borrows` warning with a link to https://github.com/rust-lang/rust/issues/82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes, the warning is just worded differently. For references to packed fields inside `unsafe` blocks, this PR shows a new future-incompat warning.
Closes https://github.com/rust-lang/rust/issues/46043 because that lint no longer exists.
|
|
which may not be available
|
|
|
|
|
|
rustdoc link format
|
|
same type, rather than on u8
|
|
|
|
Improve Debug implementations of Mutex and RwLock.
This improves the Debug implementations of Mutex and RwLock.
They now show the poison flag and use debug_non_exhaustive. (See #67364.)
|
|
Derive Debug for io::Chain instead of manually implementing it.
This derives Debug for io::Chain instead of manually implementing it.
The manual implementation has the same bounds, so I don't think there's any reason for a manual implementation. The names used in the derive implementation are even nicer (`first`/`second`) than the manual implementation (`t`/`u`), and include the `done_first` field too.
|
|
Fix Debug implementation for RwLock{Read,Write}Guard.
This would attempt to print the Debug representation of the lock that the guard has locked, which will try to lock again, fail, and just print `"<locked>"` unhelpfully.
After this change, this just prints the contents of the mutex, like the other smart pointers (and MutexGuard) do.
MutexGuard had this problem too: https://github.com/rust-lang/rust/issues/57702
|
|
Use DebugStruct::finish_non_exhaustive() in std.
See https://github.com/rust-lang/rust/issues/67364
|
|
lazily calls some fns
Replaced some fn's with it's lazy variants.
|
|
ExitStatus: print "exit status: {}" rather than "exit code: {}" on unix
Proper Unix terminology is "exit status" (vs "wait status"). "exit
code" is imprecise on Unix and therefore unclear. (As far as I can
tell, "exit code" is correct terminology on Windows.)
This new wording is unfortunately inconsistent with the identifier
names in the Rust stdlib.
It is the identifier names that are wrong, as discussed at length in eg
https://doc.rust-lang.org/nightly/std/process/struct.ExitStatus.html
https://doc.rust-lang.org/nightly/std/os/unix/process/trait.ExitStatusExt.html
Unfortunately for API stability reasons it would be a lot of work, and
a lot of disruption, to change the names in the stdlib (eg to rename
`std::process::ExitStatus` to `std::process::ChildStatus` or
something), but we should fix the message output. Many (probably
most) readers of these messages about exit statuses will be users and
system administrators, not programmers, who won't even know that Rust
has this wrong terminology.
So I think the right thing is to fix the documentation (as I have
already done) and, now, the terminology in the implementation.
This is a user-visible change to the behaviour of all Rust programs
which run Unix subprocesses. Hopefully no-one is matching against the
exit status string, except perhaps in tests.
|
|
Use detailed and shorter fs error explaination
Includes suggestion from `@the8472` https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336
|
|
the safe_packed_borrows lint that it replaces
|
|
|
|
|
|
Generalize and inline slice::fill specializations
This makes the memset specialization applicable to more types. And since the code now lives in a generic method it is also eligible for cross-crate inlining which should fix #83235
|
|
Consistency for #79399
Suggested by JohnTitor
Improve fs error invaild input for sys_common
The text was duplicated from unix.
|
|
Includes suggestion from the8472 https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336
More detail error explanation in fs doc
|
|
They now show the poison flag and use debug_non_exhaustive.
|
|
The manual implementation has the same bounds, so I don't think there's
any reason for a manual implementation. The names used in the derive
implementation are even nicer (`first`/`second`) than the manual
implementation (`t`/`u`), and include the `done_first` field too.
|
|
This would attempt to print the Debug representation of the lock that
the guard has locked, which will try to lock again, fail, and just print
"<locked>" unhelpfully.
After this change, this just prints the contents of the mutex, like the
other smart pointers (and MutexGuard) do.
|
|
|
|
|
|
Add IEEE 754 compliant fmt/parse of -0, infinity, NaN
This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values, namely signed zero, the infinities, and NaN. It also adds IEEE 754 compliance tests that, while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests, are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks.
This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074, and closes #24623.
The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers, i.e. not the extended reals (where floats live), IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely, when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition, the vast majority of other programming languages not only output `-0` but output `-0.0` here.
While IEEE 754 offers a broad leeway in how to handle producing what it calls a "decimal character sequence", it is clear that the operations a language provides should be capable of round tripping, and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further, existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character, but it prints "+0" instead if given such (which was what led to the opening of #24623).
There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard, as well as other well-documented challenges on the arithmetic level, but I hope that this can be the beginning of motion towards solving those challenges.
|
|
|
