Allow blocking Command::output

[Ayush1325]

Problem

Currently, Command::output is internally implemented using Command::spawn. This is problematic because some targets (like UEFI) do not actually support multitasking and thus block while the program is executing. This coupling does not make much sense as Command::output is supposed to block until the execution is complete anyway and thus does not need to rely on a non-blocking Child or any other intermediate.

Solution

This PR moves the implementation of Command::output to std::sys. This means targets can choose to implement only Command::output without having to implement Command::spawn.

Additional Information

This was originally conceived when working on #100316. Currently, the only target I know about that will benefit from this change is UEFI.

This PR can also be used to implement more efficient Command::output since the intermediate Process is not actually needed anymore, but that is outside the scope of this PR.

Since this is not a public API change, I'm not sure if an RFC is needed or not.

[rustbot]

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

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 @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. 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

[Mark-Simulacrum]

It seems like this doesn't change or add support itself for any platforms that can block but not spawn a subprocess, right? That will come in a future PR?

I think the changes here seem fine -- but the PR description could be updated to make clear that this isn't changing anything, just shuffling some APIs to make it easier to make changes in the future.

[Ayush1325]

It seems like this doesn't change or add support itself for any platforms that can block but not spawn a subprocess, right? That will come in a future PR?

I think the changes here seem fine -- but the PR description could be updated to make clear that this isn't changing anything, just shuffling some APIs to make it easier to make changes in the future.

Ok, will do that. I specifically made this change for UEFI (#100316) but it should be helpful for any target that is similar.

[Ayush1325]

@rustbot ready

[Mark-Simulacrum]

Thanks!

@bors r+

[bors]

📌 Commit 1ba9790 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[matthiaskrgr]

@bors r- failed in a rollup

[RUSTC-TIMING] addr2line test:false 0.462
[RUSTC-TIMING] gimli test:false 4.967
[RUSTC-TIMING] object test:false 5.721
warning: dropping unsupported crate type `dylib` for target `wasm32-unknown-unknown`

error: unused variable: `buf`
  --> library/std/src/sys/wasm/../unsupported/pipe.rs:18:31
   |
18 |     pub fn read_to_end(&self, buf: &mut Vec<u8>) -> io::Result<usize> {
   |                               ^^^ help: if this is intentional, prefix it with an underscore: `_buf`
   |
   = note: `-D unused-variables` implied by `-D warnings`

[RUSTC-TIMING] std test:false 2.677
warning: `std` (lib) generated 1 warning
error: could not compile `std` due to previous error; 1 warning emitted
Build completed unsuccessfully in 0:12:08
== clock drift check ==
  local time: Sat Dec 10 22:55:48 UTC 2022
  network time: Sat, 10 Dec 2022 22:55:48 GMT
  

#105540 (comment)

[Ayush1325]

@rustbot ready

[Mark-Simulacrum]

@bors r+ rollup

[bors]

📌 Commit a94793d has been approved by Mark-Simulacrum

It is now in the queue for this repository.