Move `std::io::util` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Subset of: https://github.com/rust-lang/rust/pull/154684
## Description
Moves utility types and functions from `std::io::util` and `std::io` to `core::io`, leaving any IO trait implementations behind. They will be moved along with the traits themselves. Certain documentation links had to be amended.
- `Chain`
- `Empty`
- `Repeat`
- `Sink`
- `Take`
- `empty`
- `repeat`
- `sink`
---
## Notes
* This can be reviewed independently of the other PRs tracked in rust-lang/rust#154046.
* `Chain` and `Take` were previously in the main `mod.rs` file for `std::io`, but I've chosen to move them into the `util.rs` file in `core::io` instead. I think they make more sense in that file, but I'm happy to move them into `mod.rs` if that's a controversial decision.
* No AI tooling of any kind was used during the creation of this PR.
Move `std::io::Cursor` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Subset of: https://github.com/rust-lang/rust/pull/154684
## Description
Moves `std::io::Cursor` to `core::io`, leaving the IO trait implementations behind. They will be moved along with the traits themselves. Certain documentation links had to be amended, and a private/unstable `into_parts_mut` method was added to allow the internals to remain private.
---
## Notes
* This can be reviewed independently of the other PRs tracked in rust-lang/rust#154046.
* No AI tooling of any kind was used during the creation of this PR.
enable more f16/f128 tests in Miri
See the individual commit messages for details.
The last commit is a drive-by comment fix that was not worth its own PR.
r? @tgross35
Improve doc comments for f32::ceil() and f32::floor()
Previously ::floor() included an example showing behaviour for negative values, but ::ceil() did not. Ensure both have examples of the negative case, for both f32 and f64.
Whilst we're here, tweak the wording slightly so it reads better.
kernel_copy tests: properly join background threads
This helps Miri because when there are threads just hanging in the background, we cannot check for memory leaks.
I think even without Miri this currently leads to 100% CPU load on one core for each of these threads: once the test function returns and `sink` gets dropped, the `read` in the thread will always immediately return `0`, and then we just loop with that forever until the process exits.
stream_send_recv_stress tests: wait for threads to finish
These tests currently fail in Miri (when run with nextest) because all they do is spawn a lot of threads that will do stuff, but they don't wait for the threads to actually finish. Miri by default errors when there are background threads lingering when `main` is done (since that can indicate a leak, and since it makes it impossible to check for memory leaks). Miri gives background threads a bit of time to finish when `main` is done, but for these tests that's nowhere near enough since basically the entire test runs after `main` is done.
Outside Miri, this could also still mean that the test doesn't actually run to completion, it might get abort when `main` finishes.
So let's use `thread::scope` to ensure all threads are done before the test is considered done.
Previously ::floor() included an example showing behaviour for
negative values, but ::ceil() did not. Ensure both have examples of
the negative case, for both f32 and f64.
Whilst we're here, tweak the wording slightly so it reads better.
mark some panicking methods around Duration as track_caller
Currently when they panic it looks like this
```
0.005045 ---- instant_checked_duration_since_nopanic stdout ----
0.000039
0.000009 thread 'instant_checked_duration_since_nopanic' (2) panicked at /home/runner/work/miri-test-libstd/miri-test-libstd/rust-src-patched/library/std/src/time.rs:445:33:
0.000007 overflow when subtracting duration from instant
0.000006 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
0.000007 note: in Miri, you may have to set `MIRIFLAGS=-Zmiri-env-forward=RUST_BACKTRACE` for the environment variable to have an effect
```
That's pretty useless.
Also fix the panic message while we are at it.
Add mention of sendfile(2) and splice(2) to fs::copy() documentation.
Fixesrust-lang/rust#155968 by adding mention of sendfile(2) and splice(2) from io::copy()
`BufWriter`: Make the soundness of `BorrowedBuf` usage clearer.
The previous safety comment was outdated as it was written before `BorrowedBuf::set_init` was changed to be a boolean. It also failed to address the possibility that `flush_buf` invalidated the assumption.
Add `keepalive`, `set_keepalive` to `TcpStream` implementations
## What
The current implementation of `TcpStream` does not expose `SO_KEEPALIVE`: rust-lang/rust#69774
## Why
It seems the reason this has not yet been implemented is because the initial implementation went as far as to take the keepalive interval as a parameter. However, Windows does not directly expose these intervals for reading, causing there to be some debate about the shape of the API (see the discussion of this [here](https://github.com/rust-lang/rust/pull/31945#issuecomment-189784913)).
## How
I am proposing that this API is enabled with a `bool` parameter to align with the implementation in both Windows and Unix, as it is the least common denominator between the two of them. With regards to the call to `setsockopt`, [Windows expects a disable/enable](https://learn.microsoft.com/en-us/windows/win32/winsock/so-keepalive), and [Unix does as well](https://man7.org/linux/man-pages/man7/socket.7.html).
The extra configuration for Unix that allows the interval to be tweaked could be done through an additional API perhaps, but I don't think that's stopping us from exposing the switch to at least enable the behavior with the OS defaults.
Tracking issue: rust-lang/rust#155889
The previous safety comment was outdated as it was written before
`BorrowedBuf::set_init` was changed to be a boolean. It also failed
to address the possibility that `flush_buf` invalidated the
assumption.
Simplify the implementation of `flush_buf` to more obviously preserve
the spare capacity, and document the need to preserve the spare
capacity where necessary.
https://github.com/rust-lang/rust/pull/150129 reworked this field to use `bool` instead of `usize`, which is awesome!
But the field's comment has a leftover note in it which is no longer true, and that needs to be removed.
Rename the diagnostic item for `std::sync::mpsc::Receiver`
`MpscReceiver` aligns with `MpscSender`. The original name appears to not actually have been in use, for better or worse.
r? mejrs
`MpscReceiver` aligns with `MpscSender`. The original name appears to
not actually have been in use, for better or worse.
Along the way, sprinkle the attribute onto `mpmc::Receiver` and
`mpmc::Sender` too.
John Millikin