| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
|
|
As pointed out in #17136 the semantics of a `BufStream` aren't always what one
expects, and it looks like other [languages like C#][c-sharp] implement a
buffered stream with only one underlying buffer. For now this commit
destabilizes the primitive in the `std::io` module to give us some more time in
figuring out what to do with it.
[c-sharp]: https://msdn.microsoft.com/en-us/library/system.io.bufferedstream%28v=vs.110%29.aspx
[breaking-change]
|
|
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Closes #24791
[breaking-change]
|
|
These implementations were intended to be unstable, but currently the stability
attributes cannot handle a stable trait with an unstable `impl` block. This
commit also audits the rest of the standard library for explicitly-`#[unstable]`
impl blocks. No others were removed but some annotations were changed to
`#[stable]` as they're defacto stable anyway.
One particularly interesting `impl` marked `#[stable]` as part of this commit
is the `Add<&[T]>` impl for `Vec<T>`, which uses `push_all` and implicitly
clones all elements of the vector provided.
Closes #24791
|
|
Even spelled out, one would say 'a Universal Character Set'
|
