Tracking Issue for anonymous pipe API

[NobodyXu]

This is a tracking issue for the ACP rust-lang/libs-team#375 .
The feature gate for the issue is #![feature(anonymous_pipe)].

// std::pipe

fn pipe() -> io::Result<(PipeReader, PipeWriter)>;

struct PipeReader {...}
struct PipeWriter {...}

impl PipeReader {
    fn try_clone(&self) -> io::Result<Self>;
}

impl PipeWriter {
    fn try_clone(&self) -> io::Result<Self>;
}

impl Read for &PipeReader
impl Read for PipeReader
impl Debug for PipeReader
impl From<PipeReader> for Stdio

impl Write for &PipeWriter
impl Write for PipeWriter
impl Debug for PipeWriter
impl From<PipeWriter> for Stdio

// unix {
impl AsFd for PipeReader
impl AsRawFd for PipeReader
impl FromRawFd for PipeReader
impl IntoRawFd for PipeReader
impl From<PipeReader> for OwnedFd
impl From<OwnedFd> for PipeReader

impl AsFd for PipeWriter
impl AsRawFd for PipeWriter
impl FromRawFd for PipeWriter
impl IntoRawFd for PipeWriter
impl From<PipeWriter> for OwnedFd
impl From<OwnedFd> for PipeWriter
// }

// windows {
impl AsHandle for PipeReader
impl AsRawHandle for PipeReader
impl FromRawHandle for PipeReader
impl IntoRawHandle for PipeReader
impl From<PipeReader> for OwnedHandle
impl From<OwnedHandle> for PipeReader

impl AsHandle for PipeWriter
impl AsRawHandle for PipeWriter
impl FromRawHandle for PipeWriter
impl IntoRawHandle for PipeWriter
impl From<PipeWriter> for OwnedHandle
impl From<OwnedHandle> for PipeWriter
// }

Steps

• Implement the ACP Initial implementation of anonymous_pipe API #127153
• Enable std::io::copy specialisation Enable std::io::copy specialisation for std::pipe::{PipeReader, PipeWriter} #128303
• Adjust documentation Add documentation for anonymous pipe module #133986 (see instructions on rustc-dev-guide)
• Move pipe API into std::io Move std::pipe::* into std::io #135583
• Stabilization PR Stabilize anonymous_pipe #135822 (see instructions on rustc-dev-guide)

Implementation history

• Initial implementation of anonymous_pipe API #127153
• Enable std::io::copy specialisation for std::pipe::{PipeReader, PipeWriter} #128303

[Fulgen301]

You might want to fix the typo in the title and feature name - it's an anonymous pipe, not an annoymous pipe.

[NobodyXu]

Thanks!

I've fixed the typo in this issue and the linked PR.

[NobodyXu]

I think we can now add specialisation to std::io::copy for std::pipe

[NobodyXu]

I'm thinking about a new method for checked conversion from OwnedFd on unix.

I think it would be quite helpful for jobserver-rs

[RalfJung]

Currently the documentation for this module is very bare-bones, quite far from the depth and quality we are used to in other parts of the standard library. There's not even a single example. This should be resolved before stabilization.

[tbu-]

I find that creating a new module for these three symbols (fn pipe, struct PipeReader, struct PipeWriter) is a bit too much — fitting it into another module means that the number of modules in std directly does not unnecessarily increase.

[NobodyXu]

I don't have a particular strong opinion on this honestly, if t/libs-api thinks that's better I am willing to change that

[joshtriplett]

No strong preference either. I don't think there's any problem with small modules, but I'd also be fine with merging it into io.

@rustbot label +I-libs-api-nominated

[m-ou-se]

We discussed this in the library api meeting. There were not a lot of strong opinions. The consensus in the meeting was to put it in the std::io module. One of the arguments was that pipe::pipe() looks less appealing than io::pipe(). Another was that we don't need a module for pipe documentation, as fn pipe() itself is already a logical place for pipe documentation.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[joboet]

@rust-lang/libs-api were the system-specific trait implementations (e.g. From<OwnedFd>, From<OwnedHandle>) also part of the FCP? And could you confirm that you are okay with establishing this pattern, considering that File does not have such implementations? For what it's worth I have nothing against those implementations, but they are unprecedented...

@rustbot label +I-libs-api-nominated

My bad, I overlooked them...

[joshtriplett]

https://doc.rust-lang.org/std/os/fd/struct.OwnedFd.html#impl-From%3COwnedFd%3E-for-File ? Or do you mean something else?

[joboet]

Oh dang, sorry, I totally overlooked that. Nevermind!