Vendor dependency os_pipe

[NobodyXu]

Signed-off-by: Jiahao XU Jiahao_XU@outlook.com

[nagisa]

Could you provide motivation for this change in the PR description?

[NobodyXu]

Could you provide motivation for this change in the PR description?

Its motivation was explained by @thomcc and @joshtriplett on zulip

[workingjubilee]

Jotting out a quick resummary is still good.

[thomcc]

Basically the reason is that the existing crate is not particularly portable, and this fixes those issues (it's not actually a straight vendoring).

My stance is that this optimization is not really worth this complexity and non-portability (this PR even has to explicitly compile_error on non-windows/non-unix, which is something we would support prior to #780 so long as std::process/std::fs worked...), but we've already landed it, and this at least reduces the number of things people have to PR in order to get their targets working.

[NobodyXu]

this PR even has to explicitly compile_error on non-windows/non-unix, which is something we would support prior to #780 so long as std::process/std::fs worked...)

@thomcc I just looked into rust's stdlib and I've found that process spawning is only supported on windows and unix.

In the stdlib's sys module, it supports the following OSes:

• unix
• windows
• solid_asp3
• hermit
• wasi
• wasm
• sgx: cfg(all(target_vendor = "fortanix", target_env = "sgx"))

And I found that other than Unix and Windows, none support process spawning:

• proof that solid_asp3 does not support process spawning
• proof that hermit does not support process spawning
• proof that wasi does not support process spawning
• proof that wasm does not support process spawning
• proof that sgx does not support process spawning

FYI, here is the link to unsupported/process.rs, it simply panics on process spawning.

@thomcc So no, my PR does not introduce any regression since cc only support windows and unix before it lands and process spawning on non-unix and non-windows OS has never been supported by stdlib anyway.

meme

from Imgflip Meme Generator

[NobodyXu]

@thomcc I also discovered a pattern in rust's stdlib: OS that does not support pipe creation also don't support process spawning.

P.S. I was just wondering how many OSes support process spawning but does not support pipe creation to see how much regression/damage my PR introduced and whether @thomcc is right that it should be reverted, turns out there's none in rust stdlib.

[joshtriplett]

I'm wondering if we can simplify this substantially.

The PipeReader/PipeWriter wrappers are nice for the os_pipe crate to keep users from mixing up the two ends and reading/writing the wrong one, but they add substantial complexity. For the purposes of this crate, it seems sufficient to return (File, File), and take care to use them correctly.

That then eliminates the need for impl_Read_by_forward and impl_Write_by_forward, as well as the From impls converting to Stdio (because File already supports that).

I also don't think it's worth including the test-support binaries in src/bin, and the tests that depend on those.

[joshtriplett]

https://github.com/NobodyXu/cc-rs/pull/1

[thomcc]

This is a lot more reasonable. Thanks to both you and @joshtriplett for all the changes.