| Age | Commit message (Collapse) | Author | Lines | |
|---|---|---|---|---|
| 2024-09-28 | Rollup merge of #125404 - a1phyr:fix-read_buf-uses, r=workingjubilee | Matthias Krüger | -1/+3 | |
| Fix `read_buf` uses in `std` Following lib-team decision here: https://github.com/rust-lang/rust/issues/78485#issuecomment-2122992314 Guard against the pathological behavior of both returning an error and performing a read. | ||||
| 2024-09-24 | Pre-allocate buffers in `File::open_buffered` and `create_buffered` | Josh Stone | -1/+11 | |
| 2024-09-23 | Fix `io::BufReader` uses of `read_buf` | Benoît du Garreau | -1/+3 | |
| 2024-09-06 | properly handle EOF in BufReader::peek | binarycat | -2/+2 | |
| previously this would cause an infinite loop due to it being unable to read `n` bytes. | ||||
| 2024-08-05 | implement BufReader::peek | binarycat | -0/+21 | |
| 2024-06-20 | Convert some module-level `//` and `///` comments to `//!`. | Nicholas Nethercote | -10/+11 | |
| This makes their intent and expected location clearer. We see some examples where these comments were not clearly separate from `use` declarations, which made it hard to understand what the comment is describing. | ||||
| 2022-10-06 | Avoid defensive re-initialization of the BufReader buffer | Ben Kimock | -3/+16 | |
| 2022-08-18 | Address reviewer comments | Nick Cameron | -1/+1 | |
| Signed-off-by: Nick Cameron <nrc@ncameron.org> | ||||
| 2022-08-05 | non-linux platforms | Nick Cameron | -4/+8 | |
| Signed-off-by: Nick Cameron <nrc@ncameron.org> | ||||
| 2022-07-26 | Add Buffer::consume_with to enable direct buffer access with one check | Ben Kimock | -0/+17 | |
| 2022-07-24 | Rename and document the new BufReader internals | Ben Kimock | -22/+26 | |
| 2022-07-24 | Allow Buffer methods to inline | Ben Kimock | -0/+9 | |
| 2022-07-24 | Remove some redundant checks from BufReader | Ben Kimock | -0/+75 | |
| The implementation of BufReader contains a lot of redundant checks. While any one of these checks is not particularly expensive to execute, especially when taken together they dramatically inhibit LLVM's ability to make subsequent optimizations. | ||||
