Revert tearing changes to `dbg!`
Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions:
* rust-lang/rust#153850, fixed by rust-lang/rust#154074
* rust-lang/rust#154988, fixed by rust-lang/rust#154994
* rust-lang/rust#155902, proposed fix in rust-lang/rust#155915
We already reverted this once, on beta only to prevent these regressions from shipping in 1.95.
In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one.
cc @joboet @dianne @rust-lang/libs
@rustbot label beta-nominated
Implement `OsStr::split_at`
See rust-lang/rust#156199
This allows splitting only on valid UTF-8 boundaries, regardless of the platform, which avoids cross-platform landmines.
Update list of platforms vulnerable to TOCTOU in `remove_dir_all`
Neither platform can reasonably protect against TOCTOU in `remove_dir_all`:
* VxWorks doesn't always have the required API (depending on how it's built), and its security model prevents untrusted processes from existing.
* QNX itself is broken and prevents the use of `openat()`: in QNX 7.1, `O_NOFOLLOW` is straight up ignored, and in QNX 8.0 `openat()` works *but* there is a TOCTOU in the kernel itself.
change `other uses of const` to `raw pointers` in const keyword docs
this section only talks about how `const` is used in raw pointers and doesn't give any other uses, so in my opinion it would be a bit clearer if the section was named `raw pointers` or something similar.
library: Fix std compilation for espidf target in unix::process
Fixes a regression on the riscv32imac-esp-espidf target caused by commit 7bf5fe7bf8 (linked issue rust-lang/rust#156537) . The unix_kill_process_group feature attempts to use libc::SIGKILL, which is not supported on the espidf target.
Discussed in `esp-idf-sys` issue: https://github.com/esp-rs/esp-idf-sys/issues/419
remove/update various cfg(miri)
I went over all `cfg(miri)` in `library/`. Most of the things I noticed have become separate PRs; these here are the few remaining scattered little fixes in various places.
Updated `.keys()`, `.values()`, `.iter()` and `.iter_mut()`.
Instead of using print statements which shows no clear effect by just reading the documentation
actually run the temp_dir doctest
No idea why this currently doesn't get run.
That said, this might fail in Miri, so we may have to wait for https://github.com/rust-lang/miri/pull/5029.
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.
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.
bors