| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
This reduces the runtime for a simple program using `Bytes::next` to
iterate through a file from 220ms to 70ms on my Linux box.
|
|
Inline `Bytes::next` and `Bytes::size_hint`.
This greatly increases its speed. On one small test program using `Bytes::next` to iterate over a large file, execution time dropped from ~330ms to ~220ms.
r? `@the8472`
|
|
This greatly increases its speed.
|
|
Implement `BufRead` for `VecDeque<u8>`
Note: it would become insta-stable
|
|
Bump bootstrap compiler to just-released beta
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
This variable seems to serve no purpose, and it's a little confusing
when reading std source code, so remove it.
|
|
|
|
|
|
r=Mark-Simulacrum
Avoid overflow in `IoSlice::advance_slices`
Noticed in https://github.com/rust-lang/rust/issues/62726#issuecomment-1713997431.
|
|
|
|
- Hide Docs
- Use repr_unpacked error
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
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`
|
|
|
|
Stabilize `io_error_other` feature
Per the FCP for https://github.com/rust-lang/rust/issues/91946.
|
|
Move RawOsError defination to sys
This was originally a part of https://github.com/rust-lang/rust/pull/105861, but I feel it should be its own PR since the raw os error is still unstable.
|
|
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inline trivial (noop) flush calls
At work I noticed that `writer.flush()?` didn't get optimized away in cases where the flush is obviously a no-op, which I had expected (well, desired).
I went through and added `#[inline]` to a bunch of cases that were obviously noops, or delegated to ones that were obviously noops. I omitted platforms I don't have access to (some tier3). I didn't do this very scientifically, in cases where it was non-obvious I left `#[inline]` off.
|
|
|
|
merge functionality of `io::Sink` into `io::Empty`
Many times, there is a need for a simple dummy `io::Read`er + `io::Write`r, but currently the only options are `io::Empty` and `io::Sink` respectively. Having both of their functionality together requires writing your own boilerplate for something that makes sense to have in the standard library. This PR adds the functionality of `io::Sink` to `io::Empty`, making `io::Empty` be able to perform the tasks of both of the previous structs. (This idea was first mentioned in #24235)
Note: I also updated some doc comments in `io::utils` in this pull request to fix inconsistencies between `io::Sink` and `io::Empty`.
API Change Proposal: https://github.com/rust-lang/libs-team/issues/49
|
|
|
|
Add back BorrowedBuf::filled_mut
This is useful if you want to do some processing on the bytes while still using the BorrowedBuf.
The API was removed in https://github.com/rust-lang/rust/pull/97015 with no explanation. The RFC also has it as part of its API, so this just seems like a mistake: [RFC](https://rust-lang.github.io/rfcs/2930-read-buf.html#:~:text=inline%5D%0A%20%20%20%20pub%20fn-,filled_mut,-(%26mut%20self))
ACP: https://github.com/rust-lang/libs-team/issues/139
|
|
- copying from `&[u8]` and `VecDeque<u8>`
- copying to `Vec<u8>`
|
|
Fix incorrect documented default bufsize in bufreader/writer
|
|
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
|
|
previously it was only able to use BufWriter. This was due to a limitation in the
BufReader generics that prevented specialization. This change works around the issue
by using `where Self: Read` instead of `where I: Read`. This limits our options, e.g.
we can't access BufRead methods, but it happens to work out if we rely on some
implementation details.
|
|
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**.
|
|
|
|
Clarify safety concern of `io::Read::read` is only relevant in unsafe code
We have this clarification note in other similar place like [Iterator::size_hint](https://doc.rust-lang.org/stable/std/iter/trait.Iterator.html#method.size_hint).
The lack of clarification might lead to confusion to Rust beginners. [Relevant URLO post](https://users.rust-lang.org/t/can-read-overflow-a-buffer/94347).
|
|
|
|
|
|
|
|
|
|
|
|
|