about summary refs log tree commit diff
path: root/library/std/src/io
AgeCommit message (Collapse)AuthorLines
2023-09-06Auto merge of #115453 - ibraheemdev:patch-16, r=joshtriplettbors-3/+1
Stabilize `io_error_other` feature Per the FCP for https://github.com/rust-lang/rust/issues/91946.
2023-09-04Auto merge of #115493 - Ayush1325:raw-os-error, r=workingjubileebors-4/+1
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.
2023-09-03Use std::io::Error::is_interrupted everywhereBen Kimock-7/+8
2023-09-03Move RawOsError defination to sysAyush Singh-4/+1
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
2023-09-01don't panic in BorrowedCursor::writeZachary S-2/+3
2023-09-01stabilize `io_error_other` featureIbraheem Ahmed-3/+1
2023-08-29further expand on Arc and Box analogyRalf Jung-3/+6
2023-08-25Add a new helper to avoid calling io::Error::kindBen Kimock-7/+17
2023-08-22Replace version placeholders with 1.73.0Mark Rousskov-2/+2
2023-08-22clarify what you cannot doRalf Jung-3/+3
2023-08-22typos and wordingRalf Jung-3/+3
Co-authored-by: Dan Gohman <dev@sunfishcode.online>
2023-08-16Partially revert #107200Josh Triplett-3/+3
`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.
2023-08-14reference-counting analogyRalf Jung-20/+23
2023-08-14reword the paragraph on file description ownershipRalf Jung-9/+10
2023-08-14don't link to RFCs, they are not up-to-date docsRalf Jung-2/+1
2023-08-14wording; and explain some of the possible consequences of violating io-safetyRalf Jung-1/+7
2023-08-14typosRalf Jung-1/+1
2023-08-13add more explicit I/O safety documentationRalf Jung-1/+35
2023-08-10Rollup merge of #114194 - thomcc:flushinline, r=cuviperMichael Goulet-0/+1
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.
2023-08-03Add assertion to test `skip_until` return valueWilliam Venner-2/+4
The extra `\0` in this commit is needed because the assertion on line 49 will fail otherwise (as `skip_until` stops reading on EOF and therefore does not read a trailing `\0`, returning 6 read bytes rather than the expected 7)
2023-07-30Fix empty_write since rust version attributeAlex Saveau-2/+2
2023-07-30Rollup merge of #98154 - vidhanio:master, r=workingjubileeMatthias Krüger-26/+87
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
2023-07-28inline trivial (noop) flush callsThom Chiovoloni-0/+1
2023-07-26Add tests and comments about `read_to_string` and `read_line` specializationsBenoît du Garreau-0/+17
2023-07-26`io::Chain`: specialize some `BufRead` methodsBenoît du Garreau-3/+16
2023-07-26`io::Chain`: specialize some `Read` methodsBenoît du Garreau-0/+33
2023-07-11Auto merge of #103754 - SUPERCILEX:filled-mut, r=m-ou-sebors-0/+7
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
2023-07-09additional io::copy specializationsThe 8472-3/+116
- copying from `&[u8]` and `VecDeque<u8>` - copying to `Vec<u8>`
2023-07-06Rollup merge of #112008 - intruder-kat:master, r=NilstriebMichael Goulet-2/+2
Fix incorrect documented default bufsize in bufreader/writer
2023-06-18Rollup merge of #107200 - mina86:c, r=AmanieuMatthias Krüger-5/+6
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
2023-06-17Extend io::copy buffer reuse to BufReader tooThe 8472-74/+207
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.
2023-06-16Rollup merge of #111074 - WaffleLapkin:🌟unsizes_your_buf_reader🌟, ↵Michael Goulet-109/+116
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**.
2023-05-26Fix incorrect documented default bufsize in bufreader/writerKathryn R-2/+2
2023-05-26Rollup merge of #111940 - zirconium-n:io-read-doc-change, r=thomccMatthias Krüger-3/+4
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).
2023-05-25Clarify safety concern of `io::Read::read` is only relevant in unsafe codeZiru Niu-3/+4
2023-05-18Add tracking issue ID for `bufread_skip_until` feature gateWilliam Venner-1/+1
2023-05-18Move `BufRead::skip_until` test to a more appropriate locationWilliam Venner-28/+28
2023-05-18Add `BufRead::skip_until` testWilliam Venner-0/+28
2023-05-15wanting => wantVagelis Prokopiou-1/+1
2023-05-05feat: merge functionality of `io::Sink` into `io::Empty`Vidhan Bhatt-26/+87
2023-05-01Relax implicit `W: Sized` bound on `LineWriter<W>`Maybe Waffle-27/+29
2023-05-01Relax implicit `W: Sized` bound on `BufWriter<W>`Maybe Waffle-69/+71
2023-05-01Relax implicit `R: Sized` bound on `BufReader<R>`Maybe Waffle-13/+16
2023-04-28replace version placeholdersPietro Albini-4/+4
2023-04-26Rollup merge of #110419 - jsoref:spelling-library, r=jyn514Matthias Krüger-7/+8
Spelling library Split per https://github.com/rust-lang/rust/pull/110392 I can squash once people are happy w/ the changes. It's really uncommon for large sets of changes to be perfectly acceptable w/o at least some changes. I probably won't have time to respond until tomorrow or the next day
2023-04-26rewrite: line_long_tail_not_flushed descriptionJosh Soref-3/+4
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-26rewrite: long_line_flushed descriptionJosh Soref-3/+3
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-26Spelling library/Josh Soref-1/+1
* advance * aligned * borrowed * calculate * debugable * debuggable * declarations * desugaring * documentation * enclave * ignorable * initialized * iterator * kaboom * monomorphization * nonexistent * optimizer * panicking * process * reentrant * rustonomicon * the * uninitialized Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-04-23Auto merge of #110655 - ChrisDenton:read-to-end, r=joshtriplettbors-6/+20
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.
2023-04-21Limit read size in `File::read_to_end` loopChris Denton-6/+20
This works around performance issues on Windows by limiting reads the size of reads when the expected size is known.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 06:45:21 +0000