diff options
| author | Corey Farwell <coreyf@rwell.org> | 2017-02-08 10:19:48 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-02-08 10:19:48 -0500 |
| commit | 96bf9ba94da034a5999e71b5bdbed60559d7b373 (patch) | |
| tree | c3e92f8d296bee5fc0a732d5f20a4c10fab8026c /src/rustllvm/RustWrapper.cpp | |
| parent | f69259ecf8cc5577cd24065f9a5a6498cfff77db (diff) | |
| parent | 2a345bbcc1e6332241883f784896ea93d2a7ccb3 (diff) | |
| download | rust-96bf9ba94da034a5999e71b5bdbed60559d7b373.tar.gz rust-96bf9ba94da034a5999e71b5bdbed60559d7b373.zip | |
Rollup merge of #39512 - oconnor663:try_wait, r=alexcrichton
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
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
