about summary refs log tree commit diff
path: root/library/std/src/io/buffered
AgeCommit message (Collapse)AuthorLines
2023-01-14Remove various double spaces in source comments.André Vennberg-2/+2
2022-10-06Avoid defensive re-initialization of the BufReader bufferBen Kimock-3/+48
2022-08-18Address reviewer commentsNick Cameron-3/+3
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-08-05non-linux platformsNick Cameron-12/+17
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-08-04std::io: migrate ReadBuf to BorrowBuf/BorrowCursorNick Cameron-23/+24
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-07-26Add Buffer::consume_with to enable direct buffer access with one checkBen Kimock-3/+18
2022-07-24Rename and document the new BufReader internalsBen Kimock-29/+33
2022-07-24Allow Buffer methods to inlineBen Kimock-0/+9
2022-07-24Remove some redundant checks from BufReaderBen Kimock-53/+106
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.
2022-06-19Fix documentation for with_capacity and reserve families of methodsjmaargh-4/+4
Documentation for the following methods with_capacity with_capacity_in with_capacity_and_hasher reserve reserve_exact try_reserve try_reserve_exact was inconsistent and often not entirely correct where they existed on the following types Vec VecDeque String OsString PathBuf BinaryHeap HashSet HashMap BufWriter LineWriter since the allocator is allowed to allocate more than the requested capacity in all such cases, and will frequently "allocate" much more in the case of zero-sized types (I also checked BufReader, but there the docs appear to be accurate as it appears to actually allocate the exact capacity). Some effort was made to make the documentation more consistent between types as well. Fix with_capacity* methods for Vec Fix *reserve* methods for Vec Fix docs for *reserve* methods of VecDeque Fix docs for String::with_capacity Fix docs for *reserve* methods of String Fix docs for OsString::with_capacity Fix docs for *reserve* methods on OsString Fix docs for with_capacity* methods on HashSet Fix docs for *reserve methods of HashSet Fix docs for with_capacity* methods of HashMap Fix docs for *reserve methods on HashMap Fix expect messages about OOM in doctests Fix docs for BinaryHeap::with_capacity Fix docs for *reserve* methods of BinaryHeap Fix typos Fix docs for with_capacity on BufWriter and LineWriter Fix consistent use of `hasher` between `HashMap` and `HashSet` Fix warning in doc test Add test for capacity of vec with ZST Fix doc test error
2022-03-10Use implicit capture syntax in format_argsT-O-R-U-S-1/+1
This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored).
2022-02-04Hide Repr details from io::Error, and rework `io::Error::new_const`.Thom Chiovoloni-5/+5
2022-01-09Compute most of Public/Exported access level in rustc_resolveLamb-4/+4
Mak DefId to AccessLevel map in resolve for export hir_id to accesslevel in resolve and applied in privacy using local def id removing tracing probes making function not recursive and adding comments Move most of Exported/Public res to rustc_resolve moving public/export res to resolve fix missing stability attributes in core, std and alloc move code to access_levels.rs return for some kinds instead of going through them Export correctness, macro changes, comments add comment for import binding add comment for import binding renmae to access level visitor, remove comments, move fn as closure, remove new_key fmt fix rebase fix rebase fmt fmt fix: move macro def to rustc_resolve fix: reachable AccessLevel for enum variants fmt fix: missing stability attributes for other architectures allow unreachable pub in rustfmt fix: missing impl access level + renaming export to reexport Missing impl access level was found thanks to a test in clippy
2021-11-02implement review suggestionsDrMeepster-1/+1
2021-11-02consolidate 2 unsafe blocks into 1DrMeepster-2/+2
2021-11-02read_bufDrMeepster-17/+94
2021-10-11Auto merge of #89755 - jkugelman:must-use-conversions-that-move-self, ↵bors-0/+1
r=joshtriplett Add #[must_use] to conversions that move self Everything here got the same message. Is the wording okay? ```rust #[must_use = "`self` will be dropped if the result is not used"] ``` I want to draw attention to these methods in particular: ```rust alloc::sync::Arc<MaybeUninit<T>> unsafe fn assume_init(self) -> Arc<T>; alloc::sync::Arc<[MaybeUninit<T>]> unsafe fn assume_init(self) -> Arc<[T]>; core::pin::Pin<&'a mut T> const fn into_ref(self) -> Pin<&'a T>; core::pin::Pin<&'a mut T> const fn get_mut(self) -> &'a mut T; core::pin::Pin<&'a mut T> const unsafe fn get_unchecked_mut(self) -> &'a mut T; core::pin::Pin<&'a mut T> unsafe fn map_unchecked_mut(self, func: F) -> Pin<&'a mut U>; core::pin::Pin<&'a mut Pin<P>> fn as_deref_mut(self) -> Pin<&'a mut P::Target>; ``` Parent issue: #89692 r? `@joshtriplett`
2021-10-10Add #[must_use] to conversions that move selfJohn Kugelman-0/+1
2021-10-09Apply clippy suggestionsClemens Wasser-6/+5
2021-10-07Optimize File::read_to_end and read_to_stringJohn Kugelman-0/+67
Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer "warms up" and grows to its final size. This is perhaps a necessary evil with generic readers, but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `read_to_string` already perform this optimization: they open the file, reads its metadata, and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However, if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests, which isn't a big deal, but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling, the `Read` trait and the `read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end, this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as a bare `Read` constraint or via a `dyn Read` trait object will benefit. For example, this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result<Json, BuilderError> { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added @camelid's suggested wording from: https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502
2021-09-25Auto merge of #88343 - steffahn:fix_code_spacing, r=jyn514bors-5/+5
Fix spacing of links in inline code. Similar to #80733, but the focus is different. This PR eliminates all occurrences of pieced-together inline code blocks like [`Box`]`<`[`Option`]`<T>>` and replaces them with good-looking ones (using HTML-syntax), like <code>[Box]<[Option]\<T>></code>. As far as I can tell, I should’ve found all of these in the standard library (regex search with `` r"`\]`|`\[`" ``) \[except for in `core::convert` where I’ve noticed other things in the docs that I want to fix in a separate PR]. In particular, unlike #80733, I’ve added almost no new instance of inline code that’s broken up into multiple links (or some link and some link-free part). I also added tooltips (the stuff in quotes for the markdown link listings) in places that caught my eye, but that’s by no means systematic, just opportunistic. [Box]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [`Box`]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [Option]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" [`Option`]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" Context: I got annoyed by repeatedly running into new misformatted inline code while reading the standard library docs. I know that once issue #83997 (and/or related ones) are resolved, these changes become somewhat obsolete, but I fail to notice much progress on that end right now. r? `@jyn514`
2021-09-25Apply 16 commits (squashed)Frank Steffahn-5/+5
---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::fmt ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::{rc, sync} ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::string ---------- Fix spacing for links inside code blocks in alloc::vec ---------- Fix spacing for links inside code blocks in core::option ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in core::result ---------- Fix spacing for links inside code blocks in core::{iter::{self, iterator}, stream::stream, poll} ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{fs, path} ---------- Fix spacing for links inside code blocks in std::{collections, time} ---------- Fix spacing for links inside code blocks in and make formatting of `&str`-like types consistent in std::ffi::{c_str, os_str} ---------- Fix spacing for links inside code blocks, and improve link tooltips in std::ffi ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{io::{self, buffered::{bufreader, bufwriter}, cursor, util}, net::{self, addr}} ---------- Fix typo in link to `into` for `OsString` docs ---------- Remove tooltips that will probably become redundant in the future ---------- Apply suggestions from code review Replacing `…std/primitive.reference.html` paths with just `reference` Co-authored-by: Joshua Nelson <github@jyn.dev> ---------- Also replace `…std/primitive.reference.html` paths with just `reference` in `core::pin`
2021-09-09Ignore automatically derived impls of `Clone` and `Debug` in dead code analysisFabian Wolff-4/+0
2021-08-24Stabilise BufWriter::into_partsIan Jackson-9/+7
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-29Rename feature gate bufwriter_into_parts from bufwriter_into_raw_partsIan Jackson-9/+9
As requested https://github.com/rust-lang/rust/pull/85901#pullrequestreview-698404772 Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-29BufWriter: rename `into_parts` from `into_raw_parts`Ian Jackson-6/+6
I looked in stdlib and as @BurntSushi thought, `raw` is generally used for raw pointers, or other hazardous kinds of thing. stdlib does not have `into_parts` apart from the one I added to `IntoInnerError`. I did an ad-hoc search of the rustdocs for my current game project Otter, which includes quite a large number of dependencies. `into_parts` seems heavily used for things quite like this. So change this name. Suggested-by: Andrew Gallant <jamslam@gmail.com> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-29BufWriter: actually export WriterPanicked errorIan Jackson-0/+2
I didn't notice the submodule, which means I failed to re-export this to make it actually-public. Reported-by: Andrew Gallant <jamslam@gmail.com> Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-07-24Rollup merge of #87175 - inquisitivecrystal:inner-error, r=kennytmYuki Okushi-4/+2
Stabilize `into_parts()` and `into_error()` This stabilizes `IntoInnerError`'s `into_parts()` and `into_error()` methods, currently gated behind the `io_into_inner_error_parts` feature. The FCP has [already completed.](https://github.com/rust-lang/rust/issues/79704#issuecomment-880652967) Closes #79704.
2021-07-22Remove Option from BufWriterAlex Macleod-10/+14
Fixes #72925
2021-07-15Stabilize `into_parts()` and `into_error()`inquisitivecrystal-4/+2
2021-06-10Specialize `io::Bytes::size_hint` for more typesBenoît du Garreau-1/+7
2021-05-14Move `std::memchr` to `sys_common`Christiaan Dirkx-1/+1
2021-04-13BufWriter: improve safety commentTyson Nottingham-6/+10
2021-04-13BufWriter: simplify buffer drainingTyson Nottingham-5/+1
2021-04-13BufWriter: use #[cold] and less aggressive #[inline] hintsTyson Nottingham-1/+3
2021-04-13BufWriter: handle possibility of overflowTyson Nottingham-15/+39
2021-04-13BufWriter: optimize for write sizes less than buffer sizeTyson Nottingham-24/+32
Optimize for the common case where the input write size is less than the buffer size. This slightly increases the cost for pathological write patterns that commonly fill the buffer exactly, but if a client is doing that frequently, they're already paying the cost of frequent flushing, etc., so the cost is of this optimization to them is relatively small.
2021-04-13BufWriter: avoid using expensive Vec methodsTyson Nottingham-12/+75
We use a Vec as our internal, constant-sized buffer, but the overhead of using methods like `extend_from_slice` can be enormous, likely because they don't get inlined, because `Vec` has to repeat bounds checks that we've already done, and because it makes considerations for things like reallocating, even though they should never happen.
2021-04-13BufWriter: apply #[inline] / #[inline(never)] optimizationsTyson Nottingham-24/+66
Ensure that `write` and `write_all` can be inlined and that their commonly executed fast paths can be as short as possible. `write_vectored` would likely benefit from the same optimization, but I omitted it because its implementation is more complex, and I don't have a benchmark on hand to guide its optimization.
2021-04-13Auto merge of #82992 - philippeitis:stabilize_bufreader_seek_relative, ↵bors-1/+1
r=workingjubilee Stabilize `bufreader_seek_relative` This PR marks `BufReader::seek_relative` as stable - the associated issue, #31100, has passed the final comment period without any issues, and from what I understand, the only thing left to stabilize this is to submit a PR marking the method as stable. Closes #31100.
2021-03-27Use DebugStruct::finish_non_exhaustive() in std.Mara Bos-1/+1
2021-03-21Bump stable version of bufreader_seek_relative.Mara Bos-1/+1
2021-03-21Use io::Error::new_const everywhere to avoid allocations.Mara Bos-2/+2
2021-03-10Stabilize `bufreader_seek_relative`philippeitis-1/+1
2021-03-05Rollup merge of #82728 - calebsander:refactor/bufreader-buf, r=m-ou-seMara-4/+3
Avoid unnecessary Vec construction in BufReader As mentioned in #80460, creating a `Vec` and calling `Vec::into_boxed_slice()` emits unnecessary calls to `realloc()` and `free()`. Updated the code to use `Box::new_uninit_slice()` to create a boxed slice directly. I think this also makes it more explicit that the initial contents of the buffer are uninitialized. r? ``@m-ou-se``
2021-03-05Rollup merge of #81136 - Xavientois:io_reader_size_hint, r=cramertjMara-1/+9
Improved IO Bytes Size Hint After trying to implement better `size_hint()` return values for `File` in [this PR](https://github.com/rust-lang/rust/pull/81044) and changing to implementing it for `BufReader` in [this PR](https://github.com/rust-lang/rust/pull/81052), I have arrived at this implementation that provides tighter bounds for the `Bytes` iterator of various readers including `BufReader`, `Empty`, and `Chain`. Unfortunately, for `BufReader`, the size_hint only improves after calling `fill_buffer` due to it using the contents of the buffer for the hint. Nevertheless, the the tighter bounds should result in better pre-allocation of space to handle the contents of the `Bytes` iterator. Closes #81052
2021-03-03Avoid unnecessary Vec construction in BufReaderCaleb Sander-4/+3
2021-01-31specialize io::copy to use the memory of the writer if it is a BufWriterThe8472-1/+13
2021-01-31Remove trailing newlineXavientois-2/+3
2021-01-31Implement SizeHint trait for BufReader, Emtpy, and ChainXavientois-1/+8
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 10:30:29 +0000