Skip to content

Add Range parameter to BTreeMap::extract_if and BTreeSet::extract_if #140825

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 4 commits into from
May 31, 2025

Conversation

rs-sac
Copy link
Contributor

@rs-sac rs-sac commented May 8, 2025

This new parameter was requested in the btree_extract_if tracking issue: #70530 (comment)

I attempted to follow the style used by Vec::extract_if.

Before:

impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A>
    where
        K: Ord,
        F: FnMut(&K, &mut V) -> bool;
}

After:

impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A>
    where
        K: Ord,
        R: RangeBounds<K>,
        F: FnMut(&K, &mut V) -> bool;
}

Related: #70530

While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.

@rustbot
Copy link
Collaborator

rustbot commented May 8, 2025

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 8, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 8, 2025

The Miri subtree was changed

cc @rust-lang/miri

@bors
Copy link
Collaborator

bors commented May 25, 2025

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

@rustbot

This comment has been minimized.

@rs-sac
Copy link
Contributor Author

rs-sac commented May 28, 2025

@workingjubilee, would you be able to take a look (and maybe redirect to the right place)?

@workingjubilee
Copy link
Member

Ah, yeah, looks good to me.

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented May 30, 2025

📌 Commit 8656d9e has been approved by workingjubilee

It is now in the queue for this repository.

@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 May 30, 2025
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request May 30, 2025
Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`

This new parameter was requested in the btree_extract_if tracking issue:  rust-lang#70530 (comment)

I attempted to follow the style used by `Vec::extract_if`.

Before:

```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A>
    where
        K: Ord,
        F: FnMut(&K, &mut V) -> bool;
}
```

After:

```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A>
    where
        K: Ord,
        R: RangeBounds<K>,
        F: FnMut(&K, &mut V) -> bool;
}
```

Related: rust-lang#70530

—

While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.
bors added a commit that referenced this pull request May 30, 2025
Rollup of 8 pull requests

Successful merges:

 - #140825 (Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`)
 - #141077 (Fix the issue of typo of comma in arm parsing)
 - #141237 (Implement ((un)checked_)exact_div methods for integers)
 - #141494 (mir-opt: Do not transform non-int type in match_branches)
 - #141609 (core: begin deduplicating pointer docs)
 - #141768 (ci: use arm to calculate job matrix)
 - #141771 (Increase timeout for new bors try builds)
 - #141781 (Fix spans for unsafe binders)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit a7e56bf into rust-lang:master May 31, 2025
7 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 31, 2025
rust-timer added a commit that referenced this pull request May 31, 2025
Rollup merge of #140825 - rs-sac:ext, r=workingjubilee

Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`

This new parameter was requested in the btree_extract_if tracking issue:  #70530 (comment)

I attempted to follow the style used by `Vec::extract_if`.

Before:

```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A>
    where
        K: Ord,
        F: FnMut(&K, &mut V) -> bool;
}
```

After:

```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A>
    where
        K: Ord,
        R: RangeBounds<K>,
        F: FnMut(&K, &mut V) -> bool;
}
```

Related: #70530

—

While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request May 31, 2025
Rollup of 8 pull requests

Successful merges:

 - rust-lang/rust#140825 (Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`)
 - rust-lang/rust#141077 (Fix the issue of typo of comma in arm parsing)
 - rust-lang/rust#141237 (Implement ((un)checked_)exact_div methods for integers)
 - rust-lang/rust#141494 (mir-opt: Do not transform non-int type in match_branches)
 - rust-lang/rust#141609 (core: begin deduplicating pointer docs)
 - rust-lang/rust#141768 (ci: use arm to calculate job matrix)
 - rust-lang/rust#141771 (Increase timeout for new bors try builds)
 - rust-lang/rust#141781 (Fix spans for unsafe binders)

r? `@ghost`
`@rustbot` modify labels: rollup
@rs-sac rs-sac deleted the ext branch June 2, 2025 15:55
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request Jun 3, 2025
Add Range parameter to `BTreeMap::extract_if` and `BTreeSet::extract_if`

This new parameter was requested in the btree_extract_if tracking issue:  rust-lang#70530 (comment)

I attempted to follow the style used by `Vec::extract_if`.

Before:

```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F>(&mut self, pred: F) -> ExtractIf<'_, K, V, F, A>
    where
        K: Ord,
        F: FnMut(&K, &mut V) -> bool;
}
```

After:

```rust
impl<K, V, A: Allocator + Clone> BTreeMap<K, V, A> {
    #[unstable(feature = "btree_extract_if", issue = "70530")]
    pub fn extract_if<F, R>(&mut self, range: R, pred: F) -> ExtractIf<'_, K, V, R, F, A>
    where
        K: Ord,
        R: RangeBounds<K>,
        F: FnMut(&K, &mut V) -> bool;
}
```

Related: rust-lang#70530

—

While I believe I have adjusted all of the necessary bits, as this is my first attempt to contribute to Rust, I may have overlooked something out of ignorance, but if you can point out any oversight, I shall attempt to remedy it.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants