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

Make BinaryHeap parametric over Allocator #99339

Merged
merged 10 commits into from
Jun 13, 2023
Merged

Conversation

yanchith
Copy link
Contributor

@yanchith yanchith commented Jul 16, 2022

Tracking issue: #32838
Related: rust-lang/wg-allocators#7

This parametrizes BinaryHeap with A, similarly to how other collections are parametrized.

A couple things I left out:

BinaryHeap::append

    Currently requires both structures to have the same allocator type. Could
    change, but depends on Vec::append, which has the same constraints.


impl<T: Ord> Default for BinaryHeap<T>

    Not parametrized, because there's nowhere to conjure the allocator from.


impl<T: Ord> FromIterator<T> for BinaryHeap<T>

    Not parametrized, because there's nowhere to conjure the allocator from.


impl<T: Ord, const N: usize> From<[T; N]> for BinaryHeap<T>

    Not parametrized, because there's nowhere to conjure the allocator from.


unsafe impl<I> AsVecIntoIter for IntoIter<I>

    AsVecIntoIter is not allocator aware, and I didn't dare change it without guidance. Is this something important?

I've seen very few tests for allocator_api in general, but I'd like to at least test this on some usage code in my projects before moving forward.

EDIT: Updated the list of impls and functions that are not affected by this. BinaryHeap no longer has a SpecExtend impl, and prior work made implementing Extend possible.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon.

Please see the contribution instructions for more information.

@rustbot
Copy link
Collaborator

rustbot commented Jul 16, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Jul 16, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 16, 2022
@JohnCSimon JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 13, 2022
@JohnCSimon JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 8, 2022
@bors
Copy link
Contributor

bors commented Jan 14, 2023

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

@anden3 anden3 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 Apr 22, 2023
@anden3
Copy link
Contributor

anden3 commented Apr 22, 2023

Hello @yanchith! I noticed this PR has a merge conflict, has there been any updates?

@yanchith
Copy link
Contributor Author

Hi! Nope. Still waiting for review, or someone I could discuss the open questions with.

I meanwhile don't need this anymore, but if we decide to salvage this despite the merge conflicts, I am willing to push it through.

@ChrisDenton
Copy link
Member

This is an API change, albeit an unstable one, so I'll tag this as waiting on a team decision.

@rustbot label +S-waiting-on-team +T-libs-api -T-libs

@rustbot rustbot added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 24, 2023
@m-ou-se m-ou-se assigned Amanieu and unassigned joshtriplett Jun 6, 2023
@@ -1195,7 +1250,7 @@ impl<T> BinaryHeap<T> {
/// ```
#[inline]
#[stable(feature = "drain", since = "1.6.0")]
pub fn drain(&mut self) -> Drain<'_, T> {
pub fn drain(&mut self) -> Drain<'_, T, A> {
Drain { iter: self.data.drain(..) }
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
/// Returns a reference to the underlying allocator.
#[inline]
#[unstable(feature = "allocator_api", issue = "32838")]
pub fn allocator(&self) -> &A {
self.data.allocator()
}

As with https://doc.rust-lang.org/std/vec/struct.Vec.html#method.allocator

Copy link
Member

@the8472 the8472 left a comment

Choose a reason for hiding this comment

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

The iterator stuff looks mostly fine. It's not very sensitive to allocators in the first place.

unsafe impl<I> AsVecIntoIter for IntoIter<I>

AsVecIntoIter is not allocator aware, and I didn't dare change it without guidance.

That's fine, the specialization that uses it currently isn't allocator-aware either.

impl<T: Ord> SpecExtend<Vec<T>> for BinaryHeap<T>

error: specializing impl repeats parameter `A`. Is this something we can do?

Also tried two different allocators, e.g. A and OA, but it depends
on BinaryHeap::append, which requires allocators to be the same type.

No longer relevant since BinaryHeap no longer has a SpecExtend. You should update the PR comment.

impl<T: Ord, A: Allocator> SpecExtend<BinaryHeap<T, A>> for BinaryHeap<T, A>

error: specializing impl repeats parameter `A`. Is this something we can do?

Also tried two different allocators, e.g. A and OA, but it depends
on BinaryHeap::append, which requires allocators to be the same type.

Ditto.


#[stable(feature = "binary_heap_extras_15", since = "1.5.0")]
impl<T: Ord> From<Vec<T>> for BinaryHeap<T> {
impl<T: Ord, A: Allocator> From<Vec<T, A>> for BinaryHeap<T, A> {
Copy link
Member

Choose a reason for hiding this comment

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

You can update the other direction too (on Vec).

And what about the one below? Can that be extended or are there inference failures?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You can update the other direction too (on Vec).

Isn't it updated? Line 1748?

And what about the one below? Can that be extended or are there inference failures?

impl<T: Ord, const N: usize> From<[T; N]> for BinaryHeap<T>? AFAIK that can't work, because there's no way to instantiate the allocator.

Copy link
Member

Choose a reason for hiding this comment

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

Isn't it updated? Line 1748?

My bad.

AFAIK that can't work, because there's no way to instantiate the allocator.

We could maybe do where A: Allocator + Default but there's no precedent for that so maybe that's best discussed in a separate PR.

Comment on lines +1244 to +1249
/// Returns a reference to the underlying allocator.
#[unstable(feature = "allocator_api", issue = "32838")]
#[inline]
pub fn allocator(&self) -> &A {
self.data.allocator()
}
Copy link
Member

Choose a reason for hiding this comment

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

The iterators should have a method like this too.

Copy link
Member

Choose a reason for hiding this comment

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

I disagree, there's no reason for the iterator to care about the allocator. None of the iterators on Vec or HashMap have such a method.

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I didn't realize we had added those. My bad.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added to IntoIter, IntoIterSorted, Drain and DrainSorted. I left PeekMut out of if for now, but let me know, and I can add it too.

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if there would be any benefit to something like trait Allocated { fn allocator(&self) -> &impl Allocator } so APIs could have a generic way to check this information.

@Amanieu
Copy link
Member

Amanieu commented Jun 12, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Jun 12, 2023

📌 Commit e0e355d has been approved by Amanieu

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-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Jun 12, 2023
@bors
Copy link
Contributor

bors commented Jun 12, 2023

⌛ Testing commit e0e355d with merge 71b3326f9ee1a7b2bf4811b16db47edb9e409478...

@bors
Copy link
Contributor

bors commented Jun 13, 2023

💔 Test failed - checks-actions

@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 Jun 13, 2023
@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@Amanieu
Copy link
Member

Amanieu commented Jun 13, 2023

@bors retry

@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 Jun 13, 2023
@bors
Copy link
Contributor

bors commented Jun 13, 2023

⌛ Testing commit e0e355d with merge de1ff0a...

@bors
Copy link
Contributor

bors commented Jun 13, 2023

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing de1ff0a to master...

1 similar comment
@bors
Copy link
Contributor

bors commented Jun 13, 2023

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing de1ff0a to master...

@bors bors added merged-by-bors This PR was explicitly merged by bors. labels Jun 13, 2023
@bors bors merged commit de1ff0a into rust-lang:master Jun 13, 2023
@rustbot rustbot added this to the 1.72.0 milestone Jun 13, 2023
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (de1ff0a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
4.1% [4.1%, 4.1%] 1
Regressions ❌
(secondary)
3.7% [2.4%, 5.0%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 4.1% [4.1%, 4.1%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 648.907s -> 648.481s (-0.07%)

@klensy
Copy link
Contributor

klensy commented Jun 13, 2023

cb5c011 Not nice, merge commit here.

@yanchith yanchith deleted the binary-heap-ta branch June 13, 2023 08:07
@yanchith
Copy link
Contributor Author

Oh no. Sorry. I thought the entire PR would get squashed, so I didn't pay it any attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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.