Skip to content
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

Change RangeInclusive to a three-field struct. #51622

Merged
merged 5 commits into from
Jul 13, 2018

Conversation

kennytm
Copy link
Member

@kennytm kennytm commented Jun 18, 2018

Fix #45222.

This PR also reverts #48012 (i.e. removed the try_fold/try_rfold specialization for RangeInclusive) because LLVM no longer has trouble recognizing a RangeInclusive loop.

@rust-highfive
Copy link
Collaborator

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 18, 2018
@cramertj
Copy link
Member

r? @SimonSapin

@rust-highfive rust-highfive assigned SimonSapin and unassigned cramertj Jun 18, 2018
@rust-highfive

This comment has been minimized.

#[stable(feature = "inclusive_range", since = "1.26.0")]
impl<Idx: PartialEq> PartialEq for RangeInclusive<Idx> {
fn eq(&self, other: &Self) -> bool {
self.start == other.start && self.end == other.end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure you don't need to compare is_iterating? Consider:

let a = 0..=0;
let mut b = a.clone();
assert_eq!(a, b);
assert_eq!(b.next(), Some(0));
assert_eq!(b.next(), None);
assert_eq!(a, b); // yes or no?

Currently that last assert would fail, because an exhausted range is replaced by 1..=0. I think with your new code, they will look equal, only different by their is_iterating.

Another one to consider:

let a = 1..=10;
let mut b = 0..=10;
b.next();
assert_eq!(a, b); // same `start` and `end`, different `is_iterating`

I guess is_empty() is the better value to use for PartialEq and Hash, but that needs PartialOrd.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On this other hand, do we expect this to always be true?

fn reflexive(r: RangeInclusive) -> bool {
    r == (r.start()..=r.end())
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imo, it would be quite jarring if it were not always true..

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with @SimonSapin and @Centril that taking is_iterating into account when comparing is strange. At the very least we need to modify the impl Debug to expose is_iterating if we do want to make the field significant.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On this other hand, do we expect this to always be true?

fn reflexive(r: RangeInclusive) -> bool {
r == (r.start()..=r.end())
}

That works in the status quo because the range is changed to 1..=0 when the iterator is exhausted. But it troubles me that with this change, r and r.start()..=r.end() might compare equal yet not produce the same items, if r is exhausted.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. Both "compares equal when reconstructed form accessors" and "yields the same items if compares equal" seem desirable, but we can’t have both with this PR’s three-fields design.

@SimonSapin
Copy link
Contributor

I think the replace_one and replace_zero methods of the Step trait can also be removed, right?

I can review for correctness in a bit, but I really don’t have an opinion on whether this change is desirable in the first place.

@kennytm
Copy link
Member Author

kennytm commented Jun 19, 2018

I think the replace_one and replace_zero methods of the Step trait can also be removed, right?

Seems like yes, I can't find other uses of these two methods in this repo.

These two functions were added by #34530 as substitute of std::num::{Zero, One}, well before we've chosen the 1..=0 representation. Though they were also only used in RangeInclusive.

@kennytm
Copy link
Member Author

kennytm commented Jun 19, 2018

cc #51601, these two PRs are going to silently conflict with each other.

@rust-highfive

This comment has been minimized.

@kennytm kennytm force-pushed the three-field-range-inclusive branch from 08e3aad to b0e29d9 Compare June 19, 2018 10:27
@rust-highfive

This comment has been minimized.

@kennytm kennytm force-pushed the three-field-range-inclusive branch from b0e29d9 to 5c80508 Compare June 19, 2018 15:14
@rust-highfive

This comment has been minimized.

@kennytm kennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 19, 2018
@kennytm kennytm force-pushed the three-field-range-inclusive branch from 5c80508 to 4941579 Compare June 19, 2018 18:39
@kennytm kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 19, 2018
@kennytm
Copy link
Member Author

kennytm commented Jun 19, 2018

Turns out LLVM 3.9 cannot recognize the loop. LLVM 6.0 is fine. Not sure about LLVM 4.0.

@Emerentius
Copy link
Contributor

@kennytm so, uh, first to get his PR merged wins and loser has to clean up the conflict?

@kennytm
Copy link
Member Author

kennytm commented Jun 20, 2018

@Emerentius yeah 😐

@Emerentius
Copy link
Contributor

@kennytm I guess I win then 😛

@kennytm kennytm force-pushed the three-field-range-inclusive branch from 4941579 to ccb0166 Compare June 22, 2018 17:42
@rust-highfive

This comment has been minimized.

@kennytm kennytm force-pushed the three-field-range-inclusive branch from ccb0166 to bb0d05a Compare June 22, 2018 19:24
@TimNN
Copy link
Contributor

TimNN commented Jun 26, 2018

Ping from triage, @SimonSapin: This PR requires your review.

@SimonSapin
Copy link
Contributor

I believe that #51622 (comment) is an unresolved issue.

@kennytm kennytm force-pushed the three-field-range-inclusive branch from 5e3bd09 to dbfa8fe Compare July 13, 2018 05:08
@kennytm
Copy link
Member Author

kennytm commented Jul 13, 2018

@bors r=SimonSapin

@bors
Copy link
Contributor

bors commented Jul 13, 2018

📌 Commit dbfa8fe2ca143818b94ded7b49e6511cfd4ff330 has been approved by SimonSapin

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 13, 2018
@rust-highfive

This comment has been minimized.

@kennytm kennytm force-pushed the three-field-range-inclusive branch from dbfa8fe to 6093128 Compare July 13, 2018 05:26
@bors
Copy link
Contributor

bors commented Jul 13, 2018

📌 Commit 6093128 has been approved by SimonSapin

@bors
Copy link
Contributor

bors commented Jul 13, 2018

⌛ Testing commit 6093128 with merge 00ebf67226780da280a20f4ec60d3c62adb9b58f...

@bors
Copy link
Contributor

bors commented Jul 13, 2018

💔 Test failed - status-travis

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 13, 2018
@rust-highfive
Copy link
Collaborator

The job dist-armv7-linux of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
  0     0    0     0    0     0      0      0 --:--:--  0:00:54 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:55 --:--:--     0curl: (6) Could not resolve host: s3-us-west-1.amazonaws.com
[01:03:16] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap dist --host armv7-unknown-linux-gnueabihf --target armv7-unknown-linux-gnueabihf
[01:03:16] Build completed unsuccessfully in 1:00:09
[01:03:16] thread 'main' panicked at 'failed to download openssl source: exit code: 6', bootstrap/native.rs:589:17
travis_time:end:023c19d0:start=1531461117067340622,finish=1531464913566915344,duration=3796499574722

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 1.
travis_time:start:1c7fc56b
---
travis_time:end:0b258f91:start=1531464914135306042,finish=1531464914142374925,duration=7068883
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:00406488
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:1573a0de
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

1 similar comment
@rust-highfive
Copy link
Collaborator

The job dist-armv7-linux of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
  0     0    0     0    0     0      0      0 --:--:--  0:00:54 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:55 --:--:--     0curl: (6) Could not resolve host: s3-us-west-1.amazonaws.com
[01:03:16] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap dist --host armv7-unknown-linux-gnueabihf --target armv7-unknown-linux-gnueabihf
[01:03:16] Build completed unsuccessfully in 1:00:09
[01:03:16] thread 'main' panicked at 'failed to download openssl source: exit code: 6', bootstrap/native.rs:589:17
travis_time:end:023c19d0:start=1531461117067340622,finish=1531464913566915344,duration=3796499574722

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 1.
travis_time:start:1c7fc56b
---
travis_time:end:0b258f91:start=1531464914135306042,finish=1531464914142374925,duration=7068883
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:00406488
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:1573a0de
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@kennytm
Copy link
Member Author

kennytm commented Jul 13, 2018

@bors retry travis-ci/travis-ci#9696

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 13, 2018
@bors
Copy link
Contributor

bors commented Jul 13, 2018

⌛ Testing commit 6093128 with merge c0955a3...

bors added a commit that referenced this pull request Jul 13, 2018
Change RangeInclusive to a three-field struct.

Fix #45222.

This PR also reverts #48012 (i.e. removed the `try_fold`/`try_rfold` specialization for `RangeInclusive`) because LLVM no longer has trouble recognizing a RangeInclusive loop.
@bors
Copy link
Contributor

bors commented Jul 13, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: SimonSapin
Pushing c0955a3 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.