Stdio::makes_pipe

[ChrisDenton]

Wrappers around std::process::Command may want to be able to override pipe creation. However, std::process::Stdio is opaque so there's no way to tell if Command was told to create new pipes or not.

This is in some ways a more generic (and cross-platform) alternative to #97149. However, unlike that feature, this comes with the price of the user needing to actually create their own pipes rather than reusing the std one. So I think it stands (or not) on its own.

Example

#![feature(stdio_makes_pipe)]
use std::process::Stdio;

let io = Stdio::piped();
assert_eq!(io.makes_pipe(), true);

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[ChrisDenton]

r? rust-lang/libs-api

[the8472]

Shouldn't it be makes_pipe (interrogative) rather than make_pipe (imperative)?

[ChrisDenton]

Good point, changed!

[m-ou-se]

Looks good to me, other than some potential bikeshedding on the name. (is_piped() to match piped()?)

r=me after opening a tracking issue.

[ChrisDenton]

@bors r=m-ou-se rollup

[bors]

📌 Commit 8b93147 has been approved by m-ou-se