Fix Iterator::advance_by contract inconsistency#89916
Merged
bors merged 1 commit intorust-lang:masterfrom Nov 27, 2021
Merged
Conversation
the8472
added
the
T-libs
Contributor
|
r? @m-ou-se (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
the8472
force-pushed
the
advance_by-avoid-err-0
branch
from
de31b95 to
17ce56f
Compare
3 tasks
JohnCSimon
added
S-waiting-on-review
Member
|
@bors r+ |
Collaborator
|
📌 Commit 17ce56f has been approved by |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 18, 2021
…tolnay Fix Iterator::advance_by contract inconsistency The `advance_by(n)` docs state that in the error case `Err(k)` that k is always less than n. It also states that `advance_by(0)` may return `Err(0)` to indicate an exhausted iterator. These statements are inconsistent. Since only one implementation (Skip) actually made use of that I changed it to return Ok(()) in that case too. While adding some tests I also found a bug in `Take::advance_back_by`.
Contributor
|
@bors r- Failed in rollup: #91024 (comment) Looks like this fails when run with overflow-checks enabled. |
bors
added
S-waiting-on-author
Contributor
|
The reason CI checks are green here is because overflow checks were added after this PR was submitted (in #89776). |
the8472
force-pushed
the
advance_by-avoid-err-0
branch
from
17ce56f to
04cecdf
Compare
The `advance_by(n)` docs state that in the error case `Err(k)` that k is always less than n. It also states that `advance_by(0)` may return `Err(0)` to indicate an exhausted iterator. These statements are inconsistent. Since only one implementation (Skip) actually made use of that I changed it to return Ok(()) in that case too. While adding some tests I also found a bug in `Take::advance_back_by`.
the8472
force-pushed
the
advance_by-avoid-err-0
branch
from
04cecdf to
3f9b26d
Compare
the8472
added
S-waiting-on-review
dtolnay
approved these changes
Nov 26, 2021
Member
|
@bors r+ |
Collaborator
|
📌 Commit 3f9b26d has been approved by |
bors
added
S-waiting-on-bors
Collaborator
Collaborator
|
☀️ Test successful - checks-actions |
Collaborator
|
Finished benchmarking commit (5fd3a5c): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Member
Author
|
Thanks for all the reviews @dtolnay |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
advance_by(n)docs state that in the error caseErr(k)that k is always less than n.It also states that
advance_by(0)may returnErr(0)to indicate an exhausted iterator.These statements are inconsistent.
Since only one implementation (Skip) actually made use of that I changed it to return Ok(()) in that case too.
While adding some tests I also found a bug in
Take::advance_back_by.