Generalize IO Traits for Arc<T> where &T: IoTrait

[bushrat011899]

ACP: rust-lang/libs-team#755
Tracking issue: #154046
Related: #94744

Description

After experimenting with #155625, I noticed Seek and SeekFrom can almost be moved to core::io. Unfortunately, the implementation of Seek for Arc<File> is a blocker for such a move, since Arc is not a fundamental type. This PR attempts to resolve this potential blocker by replacing the implementation with a more general alternative. An internal trait IoHandle has been added which types can implement to opt-in to Read/Write/Seek implementations for Arc<Self> as long as &Self implements said trait. Note that BufRead is excluded as the signature for fill_buf would require returning from a temporary.

Since this "blanket" implementation only applies to a single type which already implements the same traits, I believe this should have no user-facing impact.

If this PR was merged, #134190 could be replaced with a 2 line PR:

impl IoHandle for TcpStream {}
impl IoHandle for UnixStream {}

Likewise for any other types, a table of which can be found here. This is out of scope for this PR to avoid the need for an ACP.

---

Notes

• See this comment for further details.
• No AI tooling of any kind was used during the creation of this PR.

[fintelia]

This was proposed before in #94744

[programmerjake]

if you have some type that depends on using the shared reference itself (and not just data it points to) to keep track of position, this impl would be incorrect since it doesn't keep the shared reference around, but instead creates a new one from the Arc every time.

it could be made correct by adding a new trait bound SharedSeek that guarantees that the shared reference doesn't need to be updated:

#[unstable(...)]
pub trait SharedSeek
where
    for<'a> &'a Self: Seek,
{
}

impl<T: ?Sized + SharedSeek> Seek for Arc<T>
where
    for<'a> &'a Self: Seek,
{
    ...
}

impl SharedSeek for File {}
// ...

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ChrisDenton, libs
• @ChrisDenton, libs expanded to 7 candidates
• Random selection from Mark-Simulacrum, jhpratt

[bushrat011899]

I've adjusted the approach here to instead add a marker trait to opt-in to the blanket implementation, which should resolve this concern from #94744. This is still useful as the marker trait can (eventually) be moved into core::io along with the other IO traits but still be implemented for std types like File.

Noting here: I believe these could be replaced with default fn to allow for overriding through specialization, but since there is only one type using these implementations, and their bodies are identical, I don't think it's necessary.

[jhpratt]

LGTM; this definitely resolves the concern brought up in the previous attempt. Agreed on the name not much mattering, as the documentation makes it clear. "Handle" is a typical term for this sort of thing anyways.

@bors r+

[rust-bors]

📌 Commit 7ba9478 has been approved by jhpratt

It is now in the queue for this repository.