-
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
Make BinaryHeap parametric over Allocator #99339
Conversation
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. |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
☔ The latest upstream changes (presumably #106833) made this pull request unmergeable. Please resolve the merge conflicts. |
Hello @yanchith! I noticed this PR has a merge conflict, has there been any updates? |
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. |
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 |
@@ -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(..) } | |||
} | |||
|
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.
/// 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
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.
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> { |
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.
You can update the other direction too (on Vec).
And what about the one below? Can that be extended or are there inference failures?
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.
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.
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.
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.
/// Returns a reference to the underlying allocator. | ||
#[unstable(feature = "allocator_api", issue = "32838")] | ||
#[inline] | ||
pub fn allocator(&self) -> &A { | ||
self.data.allocator() | ||
} |
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.
The iterators should have a method like this too.
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 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.
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.
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.
Oh, I didn't realize we had added those. My bad.
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.
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.
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 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.
@bors r+ |
⌛ Testing commit e0e355d with merge 71b3326f9ee1a7b2bf4811b16db47edb9e409478... |
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
Finished benchmarking commit (de1ff0a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 648.907s -> 648.481s (-0.07%) |
cb5c011 Not nice, merge commit here. |
Oh no. Sorry. I thought the entire PR would get squashed, so I didn't pay it any attention. |
Tracking issue: #32838
Related: rust-lang/wg-allocators#7
This parametrizes
BinaryHeap
withA
, similarly to how other collections are parametrized.A couple things I left out:
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 aSpecExtend
impl, and prior work made implementingExtend
possible.