Skip to content

Implemented drain_filter for HashMap#135

Merged
bors merged 4 commits into
rust-lang:masterfrom
JulianKnodt:master
Dec 24, 2019
Merged

Implemented drain_filter for HashMap#135
bors merged 4 commits into
rust-lang:masterfrom
JulianKnodt:master

Conversation

@JulianKnodt

@JulianKnodt JulianKnodt commented Dec 15, 2019

Copy link
Copy Markdown
Contributor

#134
Drain filter is as described in the doc comments.

The implementation is based almost entirely on retain's implementation, as per amanieu's
suggestion.
I messed around with the lifetimes, as I'm not entirely familiar with the unsafe iter
on the raw table, but since we're now using a lazy iterator, the predicate must be valid for as
long as the borrow on the table.

I also annotated the function with a #[must_use], otherwise the drain would have no effect.

Please let me know if there are any other additions before this change can be added.
Thanks!

Edit:
I also realize this could be added to hashset, let me know if I should add that as well,
and if there are other tests that need to be updated.

@JulianKnodt JulianKnodt changed the title #134 Implemented drain_filter #134 Implemented drain_filter for HashMap Dec 15, 2019
@JulianKnodt JulianKnodt force-pushed the master branch 3 times, most recently from 97f74b0 to d5f0b29 Compare December 16, 2019 00:59
@JulianKnodt JulianKnodt changed the title #134 Implemented drain_filter for HashMap Implemented drain_filter for HashMap Dec 16, 2019

@Amanieu Amanieu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

My main concern with this implementation is that the behavior of the returned iterator doesn't match Vec::drain_filter or LinkedList::drain_filter when dropped. It should continue running the predicate function on all remaining elements instead of just leaving unprocessed elements in the table.

Comment thread src/map.rs Outdated
Comment thread src/map.rs Outdated
@JulianKnodt

JulianKnodt commented Dec 16, 2019

Copy link
Copy Markdown
Contributor Author

Would I have to add a separate type with its own drop implementation?

@Amanieu

Amanieu commented Dec 16, 2019

Copy link
Copy Markdown
Member

Yes a separate DrainFilter iterator type will be needed.

@JulianKnodt JulianKnodt force-pushed the master branch 3 times, most recently from 984fd53 to 66bda4e Compare December 16, 2019 05:40
@Amanieu

Amanieu commented Dec 16, 2019

Copy link
Copy Markdown
Member

Can you add a drop guard like in rust-lang/rust#67290.

After that it should be good to go.

@JulianKnodt

Copy link
Copy Markdown
Contributor Author

I've added the guard, but will wait until the embedded stuff gets fixed

@Amanieu

Amanieu commented Dec 21, 2019

Copy link
Copy Markdown
Member

@bors r+

@bors

bors commented Dec 21, 2019

Copy link
Copy Markdown
Contributor

📌 Commit 9598fc8 has been approved by Amanieu

@bors

bors commented Dec 21, 2019

Copy link
Copy Markdown
Contributor

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout master (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self master --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging src/map.rs
CONFLICT (content): Merge conflict in src/map.rs
Automatic merge failed; fix conflicts and then commit the result.

@bors

bors commented Dec 21, 2019

Copy link
Copy Markdown
Contributor

☔ The latest upstream changes (presumably #132) made this pull request unmergeable. Please resolve the merge conflicts.

Drain filter is as described in the doc comments.

The implementation is based almost entirely on retain's implementation, as per `amanieu`'s
suggestion.
I messed around with the lifetimes, as I'm not entirely familiar with the unsafe `iter`
on the raw table, but since we're now using a lazy iterator, the predicate must be valid for as
long as the borrow on the table.

I also annotated the function with a `#[must_use]`, otherwise the drain would have no effect.

Please let me know if there are any other additions before this change can be added.
Thanks!
Fixed clippy lint (added tab and spaced out `=(K,V)` => `= (K, V)`).

Also made the test more explicit.

Edit:
I've finally installed clippy rather than checking Travis.
The previous implementation did not match vec's drain filter's drop semantics. As per
`amanieu`'s suggestion, added a DrainFilter which implements drop so that it removes the
items which don't satisfy the predicate.
@JulianKnodt

Copy link
Copy Markdown
Contributor Author

Is this good to go?

@Amanieu

Amanieu commented Dec 24, 2019

Copy link
Copy Markdown
Member

Sorry, I don't get email notifications when you force-push.

@bors r+

@bors

bors commented Dec 24, 2019

Copy link
Copy Markdown
Contributor

📌 Commit 0a65d86 has been approved by Amanieu

@bors

bors commented Dec 24, 2019

Copy link
Copy Markdown
Contributor

⌛ Testing commit 0a65d86 with merge 11368d0...

bors added a commit that referenced this pull request Dec 24, 2019
Implemented drain_filter for HashMap

#134
Drain filter is as described in the doc comments.

The implementation is based almost entirely on retain's implementation, as per `amanieu`'s
suggestion.
I messed around with the lifetimes, as I'm not entirely familiar with the unsafe `iter`
on the raw table, but since we're now using a lazy iterator, the predicate must be valid for as
long as the borrow on the table.

I also annotated the function with a `#[must_use]`, otherwise the drain would have no effect.

Please let me know if there are any other additions before this change can be added.
Thanks!

Edit:
I also realize this could be added to hashset, let me know if I should add that as well,
and if there are other tests that need to be updated.
@bors

bors commented Dec 24, 2019

Copy link
Copy Markdown
Contributor

☀️ Test successful - checks-travis
Approved by: Amanieu
Pushing 11368d0 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants