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

[oconnor663]

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: #38903

[rust-highfive]

r? @aturon

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

[oconnor663]

I probably should've written r? @alexcrichton, since this is coming from #38903.

[alexcrichton]

Looks good to me, thanks @oconnor663!

@rust-lang/libs any thoughts about this change?

[nagisa]

Seems to be inconsistent with how pretty much every other non-blocking operation is handled.

[alexcrichton]

@nagisa can you elaborate some more? I think a good point is made that read and write are special cases because it's the same API for both blocking and nonblocking, so our hands are force there. Here, however, it's an explicit API and the examples I think are more ergonomic using Option.

What other blocking/nonblocking APIs do we have?

[nagisa]

Mutex::try_lock comes to mind, and I could’ve sworn we had more; but I couldn’t find any.

[oconnor663]

[added fixes for the try-wait.rs tests, and rebased]

The API currently in master tries to be consistent with Read/Write. I think if we wanted to be maximally consistent with try_lock, we might have an error enum like this:

pubenumTryWaitError{Io(std::io::Error),WouldBlock,}

So we might end up with some inconsistency either way? Though maybe that TryWaitError concept doesn't count as a reasonable option, since the io::Error can (and currently does) represent WouldBlock by itself?

My goal here was to make the non-blocking case as nice as possible, by making it a good option to just do try_wait()? if you're already short-circuiting on IO errors. I think by that logic, I wish try_lock had done something similar with Result<Option<MutexGuard>, PoisonError>. Then callers who just want to propagate panics (most of them?) could've done a similar try_lock().unwrap() instead of needing a full match. Do other folks share the "that would've been nice" opinion, or are there benefits to the TryLockError enum that I'm missing?

[oconnor663]

Oh and is this the right thing to do to run that test locally right now?

./x.py test src/test/run-pass --test-args try-wait

I found that in https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md, and it seems to work.

[alexcrichton]

@oconnor663 looks like the doctest may be failing?

[alexcrichton]

Ok I'm gonna go ahead an r+, but we can also revisit this signature before stabilization!

@bors: r+

[bors]

📌 Commit bd57742 has been approved by alexcrichton

[frewsxcv]

This fails on Windows

https://ci.appveyor.com/project/rust-lang/rust/build/1.0.1843/job/4ysk609ppr5hxfm2

@bors r-

[oconnor663]

Rebased and fixed the Windows break (hopefully).

[alexcrichton]

@bors: r+

[bors]

📌 Commit 2a345bb has been approved by alexcrichton