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, 3 insertions, 3 deletions

diff --git a/src/libstd/sys/windows/process.rs b/src/libstd/sys/windows/process.rs
index d2ad81023e7..1afb3728c9d 100644
--- a/src/libstd/sys/windows/process.rs
+++ b/src/libstd/sys/windows/process.rs
@@ -340,18 +340,18 @@ impl Process {
         }
     }
 
-    pub fn try_wait(&mut self) -> io::Result<ExitStatus> {
+    pub fn try_wait(&mut self) -> io::Result<Option<ExitStatus>> {
         unsafe {
             match c::WaitForSingleObject(self.handle.raw(), 0) {
                 c::WAIT_OBJECT_0 => {}
                 c::WAIT_TIMEOUT => {
-                    return Err(io::Error::from_raw_os_error(c::WSAEWOULDBLOCK))
+                    return Ok(None);
                 }
                 _ => return Err(io::Error::last_os_error()),
             }
             let mut status = 0;
             cvt(c::GetExitCodeProcess(self.handle.raw(), &mut status))?;
-            Ok(ExitStatus(status))
+            Ok(Some(ExitStatus(status)))
         }
     }