-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix extend
from assuming a fused iterator.
#150
Conversation
☔ The latest upstream changes (presumably #152) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks reasonable, but can you elaborate on the commit message / PR description how exactly this fixes the rustc issue?
I updated the comment, but the exact details are quite complex (and dealing with parts of librustc I know little about). |
Sure, looks good, thanks! |
@bors-servo r+ |
📌 Commit 1fbaf10 has been approved by |
Fix `extend` from assuming a fused iterator. Iterators may resume after returning None. I think it is generally expected that `extend` should stop on the first None. Fixes #147. Specifically, in rustc, there are some situations where an iterator of Results are collected into a `Result<SmallVec, _>` (such as [here](https://github.com/rust-lang/rust/blob/c1c60d292e2dd2deff7084208274f9a02f750d43/src/librustc/ty/relate.rs#L139-L142) which ends up in [this call to `collect`](https://github.com/rust-lang/rust/blob/c1c60d292e2dd2deff7084208274f9a02f750d43/src/librustc/ty/context.rs#L3002)). The [Result adapter](https://github.com/rust-lang/rust/blob/c1c60d292e2dd2deff7084208274f9a02f750d43/src/libcore/result.rs#L1245-L1258) returns None for the first `Err` in the sequence. However, it is possible for an iterator to have additional elements after the first Err. With this bug, SmallVec was falling through to the slow-path `for` loop, and resuming the iterator grabbing too many elements. I believe this was having some bad interactions with the type interner where the additional elements after the `Err` were getting processed (via a `map()`) and interned when they shouldn't be (or otherwise having some side effects from the `map`). <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/rust-smallvec/150) <!-- Reviewable:end -->
☀️ Test successful - checks-travis |
Publish 0.6.10. This incorporates #144, #152, #150, and #151, which should all be minor version updates according to semver. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/rust-smallvec/153) <!-- Reviewable:end -->
Iterators may resume after returning None. I think it is generally expected that
extend
should stop on the first None.Fixes #147. Specifically, in rustc, there are some situations where an iterator of Results are collected into a
Result<SmallVec, _>
(such as here which ends up in this call tocollect
). The Result adapter returns None for the firstErr
in the sequence. However, it is possible for an iterator to have additional elements after the first Err. With this bug, SmallVec was falling through to the slow-pathfor
loop, and resuming the iterator grabbing too many elements. I believe this was having some bad interactions with the type interner where the additional elements after theErr
were getting processed (via amap()
) and interned when they shouldn't be (or otherwise having some side effects from themap
).This change is