-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
accumulate vector and assert for RangeFrom and RangeInclusive examples #35758
accumulate vector and assert for RangeFrom and RangeInclusive examples #35758
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
Thanks! @bors: r+ rollup |
📌 Commit 6c0186d has been approved by |
/// println!("{}", i); | ||
/// } | ||
/// let result: Vec<_> = (0..).step_by(2).take(5).collect(); | ||
/// assert_eq!(result, vec![0, 2, 4, 6, 8]); |
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.
I think removing the annotation changes it from u8
to implicitly i32
, not that it matters.
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.
It simplified the example without harming so I didn't bother with it.
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.
Yeah, sorry, I should have been clear. Removing the annotation isn't a no-op for the code, but it's unnecessary for explaining the behavior of step_by
in this case. A u8
example may be important for explaining overflow behavior though...
☔ The latest upstream changes (presumably #35747) made this pull request unmergeable. Please resolve the merge conflicts. |
6c0186d
to
95c53b1
Compare
@bors: r+ rollup |
📌 Commit 95c53b1 has been approved by |
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
Please squash your two last commits. |
7636be9
to
28f057d
Compare
@bors: r=GuillaumeGomez rollup |
📌 Commit 28f057d has been approved by |
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
⌛ Testing commit 28f057d with merge 1d3d70e... |
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
PR rust-lang#35695 for `Range` was approved, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`. add `fn main` wrappers to enable Rust Playground "Run" button
28f057d
to
50e0fbc
Compare
Once buildbot is fixed, r+ you get! |
@bors: r=GuillaumeGomez rollup |
📌 Commit 50e0fbc has been approved by |
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
…tln-remaining, r=GuillaumeGomez accumulate vector and assert for RangeFrom and RangeInclusive examples PR rust-lang#35695 for `Range` was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation for `RangeFrom` and `RangeInclusive`. It also removes what looks to be an erroneously commented line for `#![feature(step_by)]`, and an unnecessary primitive-type annotation in `0u8..`.
PR #35695 for
Range
was merged, so it seems that this side-effect-free style is preferred for Range* examples. This PR performs the same translation forRangeFrom
andRangeInclusive
. It also removes what looks to be an erroneously commented line for#![feature(step_by)]
, and an unnecessary primitive-type annotation in0u8..
.