| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.
Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594
|
|
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd *that are not involved in any currently open PR* to
minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libstd.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
|
|
|
|
|
|
Fix `Stdio::piped` example code and lint
Summary:
Invoking `rev` does not add a trailing newline when none is present in
the input (at least on my Debian). Nearby examples use `echo` rather
than `rev`, which probably explains the source of the discrepancy.
Also, a `mut` qualifier is unused.
Test Plan:
Copy the code block into <https://play.rust-lang.org> with a `fn main`
wrapper, and run it. Note that it compiles and runs cleanly; prior to
this commit, it would emit an `unused_mut` warning and then panic.
wchargin-branch: stdio-piped-docs
|
|
|
|
|
|
Summary:
Invoking `rev` does not add a trailing newline when none is present in
the input (at least on my Debian). Nearby examples use `echo` rather
than `rev`, which probably explains the source of the discrepancy.
Also, a `mut` qualifier is unused.
Test Plan:
Copy the code block into <https://play.rust-lang.org> with a `fn main`
wrapper, and run it. Note that it compiles and runs cleanly; prior to
this commit, it would emit an `unused_mut` warning and then panic.
wchargin-branch: stdio-piped-docs
|
|
|
|
This commit moves a test out of libstd which is causing deadlocks on
musl on CI. Looks like the recent update in musl versions brings in some
internal updates to musl which makes `setgid` and `setuid` invalid to
call after a `fork` in a multithreaded program. The issue seen here is
that the child thread was attempting to grab a lock held by a
nonexistent thread, meaning that the child process simply deadlocked
causing the whole test to deadlock.
This commit moves the test to its own file with no threads which should
work.
|
|
Removed trailing whitespace from documentation of ExitStatus.
|
|
The documentation of [`ExitStatus`] are extended to be at the same depth as [`Output`].
|
|
Extend the std::process::Child docs with warning about possible zombies.
The previous version mentioned that when dropping the Child, the
process is not killed. However, the wording gave the impression that
such behaviour is fine to do (leaving the reader believe low-level
details like reaping zombies of the dead processes is taken over by std
somehow; or simply leaving the reader unaware about the problem).
|
|
This renames `std::io::IoVec` to `std::io::IoSlice` and
`std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes
`std::io::IoSlice`, `std::io::IoSliceMut`,
`std::io::Read::read_vectored`, and `std::io::Write::write_vectored`.
Closes #58452
|
|
This commit implements the `{read,write}_vectored` methods on more types
in the standard library, namely:
* `std::fs::File`
* `std::process::ChildStd{in,out,err}`
* `std::io::Std{in,out,err}`
* `std::io::Std{in,out,err}Lock`
* `std::io::Std{in,out,err}Raw`
Where supported the OS implementations hook up to native support,
otherwise it falls back to the already-defaulted implementation.
|
|
|
|
|
|
|
|
|
|
* A number of `Stdio` related doc examples include running the "rev"
command to illustrate piping commands. The majority of these tests are
marked as `no_run` except for two tests which were not
* Not running these tests is unlikely to cause any negative impact, and
doing so also allows the test suite to pass in environments where the
"rev" command is unavailable
|
|
|
|
|
|
|
|
This test ensures that everything in `env::vars()` is inherited but
that's not actually true because other tests may add env vars after we
spawn the process, causing the test to be flaky! This commit moves the
test to a run-pass test where it can execute in isolation.
Along the way this removes a lot of the platform specificity of the
test, using iteslf to print the environment instead of a foreign process.
|
|
fix various typos in doc comments
|
|
|
|
Avoid converting bytes to UTF-8 strings to print, just pass bytes to stdout/err
r? @nikomatsakis
|
|
|
|
Add a basic summary and an example to From `ChildStdin`, `ChildStdout`,
`ChildStderr`, `File` implementations.
|
|
|
|
|
|
The prior documentation did not make it clear this was possible.
|
|
|
|
std: Child::kill() returns error if process has already exited
This patch makes it clear in std::process::Child::kill()'s API
documentation that an error is returned if the child process has
already cleanly exited. This is implied by the example, but not
called out explicitly.
|
|
|
|
|
|
These were showing up in tests and in binaries but are trivially optimize-able
away, so add `#[inline]` attributes so LLVM has an opportunity to optimize them
out.
|
|
It was stabilized right before the beta branch was cut for 1.26.0.
See https://github.com/rust-lang/rust/pull/49523#issuecomment-377996315
|
|
Fixes #44971
|
|
|
|
|
|
This patch makes it clear in std::process::Child::kill()'s API
documentation that an error is returned if the child process has
already cleanly exited. This is implied by the example, but not
called out explicitly.
|
|
|
|
|
|
|
|
|
