make Child::try_wait return io::Result<Option<ExitStatus>>

This is much nicer for callers who want to short-circuit real I/O errors
with `?`, because they can write this

    if let Some(status) = foo.try_wait()? {
        ...
    } else {
        ...
    }

instead of this

    match foo.try_wait() {
        Ok(status) => {
            ...
        }
        Err(err) if err.kind() == io::ErrorKind::WouldBlock => {
            ...
        }
        Err(err) => return Err(err),
    }

The original design of `try_wait` was patterned after the `Read` and
`Write` traits, which support both blocking and non-blocking
implementations in a single API. But since `try_wait` is never blocking,
it makes sense to optimize for the non-blocking case.

Tracking issue: https://github.com/rust-lang/rust/issues/38903

1 files changed, 4 insertions, 4 deletions

diff --git a/src/libstd/sys/unix/process/process_unix.rs b/src/libstd/sys/unix/process/process_unix.rs
index 0dc1739c1a1..bbc987209e3 100644
--- a/src/libstd/sys/unix/process/process_unix.rs
+++ b/src/libstd/sys/unix/process/process_unix.rs
@@ -249,19 +249,19 @@ impl Process {
         Ok(ExitStatus::new(status))
     }
 
-    pub fn try_wait(&mut self) -> io::Result<ExitStatus> {
+    pub fn try_wait(&mut self) -> io::Result<Option<ExitStatus>> {
         if let Some(status) = self.status {
-            return Ok(status)
+            return Ok(Some(status))
         }
         let mut status = 0 as c_int;
         let pid = cvt(unsafe {
             libc::waitpid(self.pid, &mut status, libc::WNOHANG)
         })?;
         if pid == 0 {
-            Err(io::Error::from_raw_os_error(libc::EWOULDBLOCK))
+            Ok(None)
         } else {
             self.status = Some(ExitStatus::new(status));
-            Ok(ExitStatus::new(status))
+            Ok(Some(ExitStatus::new(status)))
         }
     }
 }