| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Assigned new feature name `core_io_borrowed_buf` to distinguish from the
`Read::read_buf` functionality in `std::io`.
|
|
|
|
|
|
This reduces the runtime for a simple program using `Bytes::next` to
iterate through a file from 220ms to 70ms on my Linux box.
|
|
This greatly increases its speed.
|
|
This variable seems to serve no purpose, and it's a little confusing
when reading std source code, so remove it.
|
|
|
|
|
|
add more explicit I/O safety documentation
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/434
Cc https://github.com/rust-lang/rust/issues/114167
Cc `@Manishearth` `@sunfishcode` `@joshtriplett`
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Dan Gohman <dev@sunfishcode.online>
|
|
`Ok(0)` is indeed something the caller may interpret as an error, but
that's the *correct* thing to return if the writer can't accept any more
bytes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
io: soften ‘at most one write attempt’ requirement in io::Write::write
At the moment, documentation of std::io::Write::write indicates that
call to it ‘represents at most one attempt to write to any wrapped
object’. It seems that such wording was put there to contrast it with
pre-1.0 interface which attempted to write all the data (it has since
been changed in [RFC 517]).
However, the requirement puts unnecessary constraints and may
complicate adaptors which perform non-trivial transformations on the
data. For example, they may maintain an internal buffer which needs
to be written out before the write method accepts more data. It might
be natural to code the method such that it flushes the buffer and then
grabs another chunk of user data. With the current wording in the
documentation, the adaptor would be forced to return Ok(0).
This commit softens the wording such that implementations can choose
code structure which makes most sense for their particular use case.
While at it, elaborate on the meaning of `Ok(0)` return pointing out
that the write_all methods interprets it as an error.
[RFC 517]: https://rust-lang.github.io/rfcs/0517-io-os-reform.html
|
|
r=Amanieu
Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`
TL;DR:
```diff,rust
-pub struct BufReader<R> { /* ... */ }
+pub struct BufReader<R: ?Sized> { /* ... */ }
-pub struct BufWriter<W: Write> { /* ... */ }
+pub struct BufWriter<W: ?Sized + Write> { /* ... */ }
-pub struct LineWriter<W: Write> { /* ... */ }
+pub struct LineWriter<W: ?Sized + Write> { /* ... */ }
```
This allows using `&mut BufReader<dyn Read>`, for example.
**This is an insta-stable change**.
|
|
|
|
|
|
|
|
Limit read size in `File::read_to_end` loop
Fixes #110650.
Windows file reads have perf overhead that's proportional to the buffer size. When we have a reasonable expectation that we know the file size, we can set a reasonable upper bound for the size of the buffer in one read call.
|
|
This works around performance issues on Windows by limiting reads the size of reads when the expected size is known.
|
|
A bunch of places were using `replace(…, &mut [])`, but that can just be `take`.
|
|
closes: https://github.com/rust-lang/rust/issues/98070
|
|
Guarantee that when `read_buf_exact` returns, all bytes read will be
appended to the buffer. Including the case when the operations fails.
The motivating use case are operations on a non-blocking reader. When
`read_buf_exact` fails with `ErrorKind::WouldBlock` error, the operation
can be resumed at a later time.
|
|
Co-authored-by: Jacob Lifshay <programmerjake@gmail.com>
|
|
Co-authored-by: Andrew Gallant <jamslam@gmail.com>
|
|
|
|
|
|
Implement rust-lang/libs-team#173.
|
|
At the moment, documentation of std::io::Write::write indicates that
call to it ‘represents at most one attempt to write to any wrapped
object’. It seems that such wording was put there to contrast it
with pre-1.0 interface which attempted to write all the data (it has
since been changed in [RFC 517]).
However, the requirement puts unnecessary constraints and may complicate
adaptors which perform non-trivial transformations on the data. For
example, they may maintain an internal buffer which needs to be written
out before the write method accepts more data. It might be natural to
code the method such that it flushes the buffer and then grabs another
chunk of user data. With the current wording in the documentation, the
adaptor would be forced to return Ok(0).
This commit softens the wording such that implementations can choose
code structure which makes most sense for their particular use case.
While at it, elaborate on the meaning of `Ok(0)` return pointing out
that the write_all methods interprets it as an error.
[RFC 517]: https://rust-lang.github.io/rfcs/0517-io-os-reform.html
|
|
|
|
|
|
|
|
The UNIX and WASI implementations use `isatty`. The Windows
implementation uses the same logic the `atty` crate uses, including the
hack needed to detect msys terminals.
Implement this trait for `File` and for `Stdin`/`Stdout`/`Stderr` and
their locked counterparts on all platforms. On UNIX and WASI, implement
it for `BorrowedFd`/`OwnedFd`. On Windows, implement it for
`BorrowedHandle`/`OwnedHandle`.
Based on https://github.com/rust-lang/rust/pull/91121
Co-authored-by: Matt Wilkinson <mattwilki17@gmail.com>
|
|
|
|
|
|
|
|
Add mention of `BufReader` in `Read::bytes` docs
There is a general paragraph about `BufRead` in the `Read` trait's docs, however using `bytes` without `BufRead` *always* has a large impact, due to reads of size 1.
`@rustbot` label +A-docs
|
|
Signed-off-by: Nick Cameron <nrc@ncameron.org>
|
|
|
|
Signed-off-by: Nick Cameron <nrc@ncameron.org>
|
|
Signed-off-by: Nick Cameron <nrc@ncameron.org>
|
|
remove useless mut from examples
remove useless mut from examples
|
