Mark some more types as having insignificant dtor
These were caught by https://github.com/rust-lang/rust/pull/129864#issuecomment-2376658407, which is implementing a lint for some changes in drop order for temporaries in tail expressions.
Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory.
See some discussion on #89144 for what makes a drop impl "significant"
Add `File` constructors that return files wrapped with a buffer
In addition to the light convenience, these are intended to raise visibility that buffering is something you should consider when opening a file, since unbuffered I/O is a common performance footgun to Rust newcomers.
ACP: https://github.com/rust-lang/libs-team/issues/446
Tracking Issue: #130804
Also emit `missing_docs` lint with `--test` to fulfil expectations
This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant".
I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive.
Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky.
Fixes https://github.com/rust-lang/rust/issues/130021
try-job: x86_64-gnu-aux
Stabilize most of `io_error_more`
Sadly, venting my frustration with t-libs-api is not a constructive way to solve problems and get things done, so I will try to stick to stuff that actually matters here.
- Tracking issue for this feature was opened 3 years ago: #86442
- FCP to stabilize it was completed 19(!!) months ago: https://github.com/rust-lang/rust/issues/86442#issuecomment-1368082102
- A PR with stabilization was similarly open for 19 months: #106375, but nothing ever came out of it. Presumably (it is hard to judge given the lack of communication) because a few of the variants still had some concerns voiced about them, even after the FCP.
So, to highlight a common sentiment:
> Maybe uncontroversial variants can be stabilised first and other variants (such as `QuotaExceeded` or `FilesystemLoop`) later? [^1]
[^1]: https://github.com/rust-lang/rust/issues/106375#issuecomment-1435762236
> I would like to voice support stabilization of the uncontroversial variants. This would get those variants to stable and focus the discussion around the more controversial ones. I don't see any particular reason that all of these must be stabilized at the same time. [...] [^2]
[^2]: https://github.com/rust-lang/rust/pull/106375#issuecomment-1742661555
> Maybe some less-controversial subset could be stabilized sooner? What’s blocking this issue from making progress? [^3]
[^3]: https://github.com/rust-lang/rust/issues/86442#issuecomment-1691187483 (got 30 upvotes btw) (and no response)
So this is exactly what this PR does. It stabilizes the non-controversial variants now, leaving just a few of them behind.
Namely, this PR stabilizes:
- `HostUnreachable`
- `NetworkUnreachable`
- `NetworkDown`
- `NotADirectory`
- `IsADirectory`
- `DirectoryNotEmpty`
- `ReadOnlyFilesystem`
- `StaleNetworkFileHandle`
- `StorageFull`
- `NotSeekable`
- `FileTooLarge`
- `ResourceBusy`
- `ExecutableFileBusy`
- `Deadlock`
- `TooManyLinks`
- `ArgumentListTooLong`
- `Unsupported`
This PR does not stabilize:
- `FilesystemLoop`
- `FilesystemQuotaExceeded`
- `CrossesDevices`
- `InvalidFilename`
Hopefully, this will allow us to move forward with this highly and long awaited addition to std, both allowing to still polish the less clear parts of it and not leading to stagnation.
r? joshtriplett
because they seem to be listed as a part of t-libs-api and were one of the most responsive persons previously
Replace `io::Cursor::{remaining_slice, is_empty}`
This is a late follow up to the concerns raised in https://github.com/rust-lang/rust/issues/86369.
https://github.com/rust-lang/rust/issues/86369#issuecomment-953096691
> This API seems focussed on the `Read` side of things. When `Seek`ing around and `Write`ing data, `is_empty` becomes confusing and `remaining_slice` is not very useful. When writing, the part of the slice before the cursor is much more interesting. Maybe we should have functions for both? Or a single function that returns both slices? (If we also have a `mut` version, a single function would be useful to allow mutable access to both sides at once.)
New feature name: `cursor_remaining` > `cursor_split`.
Added functions:
```rust
fn split(&self) -> (&[u8], &[u8]);
// fn before(&self) -> &[u8];
// fn after(&self) -> &[u8];
fn split_mut(&mut self) -> (&mut [u8], &mut [u8]);
// fn before_mut(&mut self) -> &mut [u8];
// fn after_mut(&mut self) -> &mut [u8];
```
A question was raised in https://github.com/rust-lang/rust/issues/86369#issuecomment-927124211 about whether to return a lifetime that would reflect the lifetime of the underlying bytes (`impl Cursor<&'a [u8]> { fn after(&self) -> &'a [u8] }`). The downside of doing this would be that it would not be possible to implement these functions generically over `T: AsRef<[u8]>`.
## Update
Based on the review, before* and after* methods where removed.
Use ManuallyDrop in BufWriter::into_parts
The fact that `mem::forget` takes by value means that it interacts very poorly with Stacked Borrows; generally users think of calling it as a no-op, but in Stacked Borrows, the field retagging tends to cause surprise tag invalidation.
This makes their intent and expected location clearer. We see some
examples where these comments were not clearly separate from `use`
declarations, which made it hard to understand what the comment is
describing.
Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude
(Note: need to update the PR to add `align_of` and `align_of_val`, and remove the second commit with the myriad changes to appease the lint.)
Many, many projects use `size_of` to get the size of a type. However,
it's also often equally easy to hardcode a size (e.g. `8` instead of
`size_of::<u64>()`). Minimizing friction in the use of `size_of` helps
ensure that people use it and make code more self-documenting.
The name `size_of` is unambiguous: the name alone, without any prefix or
path, is self-explanatory and unmistakeable for any other functionality.
Adding it to the prelude cannot produce any name conflicts, as any local
definition will silently shadow the one from the prelude. Thus, we don't
need to wait for a new edition prelude to add it.
Fix `read_exact` and `read_buf_exact` for `&[u8]` and `io:Cursor`
- Drain after `read_exact` and `read_buf_exact`
- Append to cursor in `read_buf_exact`
