Skip to content

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Aug 20, 2019

Successful merges:

Failed merges:

r? @ghost

JohnTitor and others added 8 commits August 5, 2019 02:44
Prevously the `read_to_end` implementation for `std::io::Take` used its
own `limit` as a cap on the `reservation_size`. However, that could
still result in an over-allocation like this:

1. Call `reader.take(5).read_to_end(&mut vec)`.
2. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
3. `read` writes 5 bytes.
4. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
5. `read` writes 0 bytes.
6. The read loop ends with `vec` having length 5 and capacity 10.

The reservation of 5 bytes was correct for the read at step 2 but
unnecessary for the read at step 4. By that second read, `Take::limit`
is 0, but the `read_to_end_with_reservation` loop is still using the
same `reservation_size` it started with.

Solve this by having `read_to_end_with_reservation` take a closure,
which lets it get a fresh `reservation_size` for each read. This is an
implementation detail which doesn't affect any public API.
It was accidentally removed in a rebase of rust-lang#62727

Fixes rust-lang#63729
…kler

avoid unnecessary reservations in std::io::Take::read_to_end

Prevously the `read_to_end` implementation for `std::io::Take` used its
own `limit` as a cap on the `reservation_size`. However, that could
still result in an over-allocation like this:

1. Call `reader.take(5).read_to_end(&mut vec)`.
2. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
3. `read` writes 5 bytes.
4. `read_to_end_with_reservation` reserves 5 bytes and calls `read`.
5. `read` writes 0 bytes.
6. The read loop ends with `vec` having length 5 and capacity 10.

The reservation of 5 bytes was correct for the read at step 2 but
unnecessary for the read at step 4. By that second read, `Take::limit`
is 0, but the `read_to_end_with_reservation` loop is still using the
same `reservation_size` it started with.

Solve this by having `read_to_end_with_reservation` take a closure,
which lets it get a fresh `reservation_size` for each read. This is an
implementation detail which doesn't affect any public API.
…unksexactmut, r=scottmcm

Implement `nth_back` for ChunksExactMut

This is a part of rust-lang#54054.

r? @scottmcm
…ttmcm

Fix bug in iter::Chain::size_hint

`Chain::size_hint` currently ignores `self.state`, which means that the size hints of the underlying iterators are always combined regardless of the iteration state. This, of course, should only happen when the state is `ChainState::Both`.
Restore the rustc_plugin crate in the sysroot

It was accidentally removed in a rebase of rust-lang#62727

Fixes rust-lang#63729 (rls build failure)
@Centril
Copy link
Contributor Author

Centril commented Aug 20, 2019

@bors r+ p=4 rollup=never

@bors
Copy link
Collaborator

bors commented Aug 20, 2019

📌 Commit b2d4415 has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 20, 2019
@Centril Centril closed this Aug 20, 2019
@Centril Centril deleted the rollup-tni904e branch August 20, 2019 14:27
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants