| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Beef up the struct docs, add examples for the methods.
r? @alexcrichton
|
|
These provide various special readers, so point their docs to their
constructor functions in a manner consistent with everything else.
r? @alexcrichton
|
|
Beef up the docs on the type, as well as adding examples for all
methods.
r? @alexcrichton
|
|
Make them all consistent and link up the documentation.
r? @alexcrichton
|
|
Mostly through adding examples.
r? @alexcrichton
I'm going to be doing a bunch of these today, but I figured I'd keep it one PR per struct, since the last 'all the things in one PR' ended up taking a week to actually land.
|
|
Beef up the docs on the type, as well as adding examples for all
methods.
|
|
Beef up the struct docs, add examples for the methods.
|
|
Mostly through adding examples.
|
|
Mostly adding examples.
|
|
This is the landing page for all of io, so we should have more than just
a sentence here.
|
|
Better and more consistent links to their creators.
|
|
These provide various special readers, so point their docs to their
constructor functions in a manner consistent with everything else.
|
|
Make them all consistent and link up the documentation.
|
|
into rollup_central
|
|
|
|
|
|
|
|
|
|
|
|
allowing them to read into a buffer containing uninitialized data,
rather than pay the cost of zeroing.
|
|
Use Vec::drain in BufWriter
I happened past a comment that asked for functionality that we now have.
|
|
I happened past a comment that asked for functionality that we now have.
|
|
- It is clear that what follows are re-exports
- There aren't so many re-exports that examples should be given
|
|
This round: io::Result and the free functions.
|
|
|
|
This round: io::Result and the free functions.
|
|
In a followup to PR #26849, improve one more location for I/O where
we can use `Vec::resize` to ensure better performance when zeroing
buffers.
Use the `vec![elt; n]` macro everywhere we can in the tree. It replaces
`repeat(elt).take(n).collect()` which is more verbose, requires type
hints, and right now produces worse code. `vec![]` is preferable for vector
initialization.
The `vec![]` replacement touches upon one I/O path too, Stdin::read
for windows, and that should be a small improvement.
r? @alexcrichton
|
|
Vec::resize compiles to better code than .extend(repeat(0).take(n)) does
right now.
|
|
Improve zerofill in Vec::resize and Read::read_to_end
We needed a more efficient way to zerofill the vector in read_to_end.
This to reduce the memory intialization overhead to a minimum.
Use the implementation of `std::vec::from_elem` (used for the vec![]
macro) for Vec::resize as well. For simple element types like u8, this
compiles to memset, so it makes Vec::resize much more efficient.
|
|
|
|
Use the vec![] macro directly to create a sized, zeroed vector.
This should result in a big speedup when creating BufReader, because
vec![0; cap] compiles to a memset call, while the previous extend code
currently did not.
|
|
We needed a more efficient way to zerofill the vector in read_to_end.
This to reduce the memory intialization overhead to a minimum.
Use the implementation of `std::vec::from_elem` (used for the vec![]
macro) for Vec::resize as well. For simple element types like u8, this
compiles to memset, so it makes Vec::resize much more efficient.
|
|
* fix probable copy-paste error in BufWriter.get_mut()
* more consistent punctuation
|
|
|
|
|
|
|
|
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
Fixes #26408
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
|
|
Questions about the utility of this type has caused it to move to crates.io in
the `bufstream` crate, so this type can be deprecated.
|
|
|
|
Closes #25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
[breaking-change]
|
|
Closes #25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
[breaking-change]
|
|
|
|
|
|
This takes the cases from InvalidInput where a data format error
was encountered. This is different from the documented semantics
of InvalidInput, which more likely indicate a programming error.
|
|
|
|
Ergonomics are a bit crappy right now because method resolution isn't
smart enough to drop bounds, unfortunately.
|
|
error::Error itself has downcasting methods, so there's no need to
duplicate those here.
|
|
|
