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

Add support for custom allocator in VecDeque #86595

Merged
merged 4 commits into from Jul 25, 2021

Conversation

a1phyr
Copy link
Contributor

@a1phyr a1phyr commented Jun 24, 2021

This follows the roadmap of the allocator WG to add custom allocators to collections.

@rustbot modify labels: +A-allocators +T-libs

@rustbot rustbot added A-allocators Area: Custom and system allocators T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 24, 2021
@rust-highfive
Copy link
Collaborator

r? @kennytm

(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 24, 2021
library/alloc/src/collections/vec_deque/mod.rs Outdated Show resolved Hide resolved
__impl_slice_eq1! { [const N: usize] VecDeque<A>, [B; N], }
__impl_slice_eq1! { [const N: usize] VecDeque<A>, &[B; N], }
__impl_slice_eq1! { [const N: usize] VecDeque<A>, &mut [B; N], }
__impl_slice_eq1! { [] VecDeque<T, A>, Vec<U, A>, }
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, why do you require both to come from the same allocator? Just comparing them shouldn't do any reallocation, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For all function potentially mixing allocators, while I agree that allowing it would be great, current APIs (eg for Vec) do not seem to go in this direction.

There may be a reason I don't know for this choice, but I chose consistency anyway. If the opposite is decided, I'll be happy to change this.

impl<A: PartialEq> PartialEq for VecDeque<A> {
fn eq(&self, other: &VecDeque<A>) -> bool {
impl<T: PartialEq, A: Allocator> PartialEq for VecDeque<T, A> {
fn eq(&self, other: &Self) -> bool {
Copy link
Member

Choose a reason for hiding this comment

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

Ditto: why require the same allocator? Is it required by the trait definition?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is not required by the definition (only for Eq), but this is what Vec does, so I did the same.

self.get_mut(index).expect("Out of bounds access")
}
}

#[stable(feature = "rust1", since = "1.0.0")]
impl<A> FromIterator<A> for VecDeque<A> {
fn from_iter<T: IntoIterator<Item = A>>(iter: T) -> VecDeque<A> {
impl<T> FromIterator<T> for VecDeque<T> {
Copy link
Member

Choose a reason for hiding this comment

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

I think you forgot to add an A: Allocator parameter here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was not sure about this one, as adding a generic parameter could break inference. So I referred to what Vec does and did the same.

fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
f.debug_list().entries(self).finish()
}
}

#[stable(feature = "vecdeque_vec_conversions", since = "1.10.0")]
impl<T> From<Vec<T>> for VecDeque<T> {
impl<T, A: Allocator> From<Vec<T, A>> for VecDeque<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.

Ditto: why require the same allocator?

VecDeque { tail: 0, head: len, buf }
}
}
}

#[stable(feature = "vecdeque_vec_conversions", since = "1.10.0")]
impl<T> From<VecDeque<T>> for Vec<T> {
impl<T, A: Allocator> From<VecDeque<T, A>> for Vec<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.

Ditto: why require the same allocator?

@@ -25,7 +27,7 @@ pub struct PairSlices<'a, 'b, T> {
}

impl<'a, 'b, T> PairSlices<'a, 'b, T> {
pub fn from(to: &'a mut VecDeque<T>, from: &'b VecDeque<T>) -> Self {
pub fn from<A: Allocator>(to: &'a mut VecDeque<T, A>, from: &'b VecDeque<T, A>) -> Self {
Copy link
Member

Choose a reason for hiding this comment

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

Ditto: why require the same allocator?

@rust-log-analyzer

This comment has been minimized.

@a1phyr a1phyr force-pushed the allocator_api_for_vecdeque branch from 4b52881 to 821b4b8 Compare July 8, 2021 14:34
@bors
Copy link
Contributor

bors commented Jul 22, 2021

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

@jyn514
Copy link
Member

jyn514 commented Jul 22, 2021

r? @Amanieu

@rust-highfive rust-highfive assigned Amanieu and unassigned kennytm Jul 22, 2021
@a1phyr a1phyr force-pushed the allocator_api_for_vecdeque branch from 821b4b8 to 19318e6 Compare July 23, 2021 18:38
@Amanieu
Copy link
Member

Amanieu commented Jul 24, 2021

I'm happy with the changes since it mirrors what Vec does.

@bors r+

@bors
Copy link
Contributor

bors commented Jul 24, 2021

📌 Commit 19318e6 has been approved by Amanieu

@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 24, 2021
@bors
Copy link
Contributor

bors commented Jul 25, 2021

⌛ Testing commit 19318e6 with merge ca1bb41863911446e5f687c523052113c7716d9e...

@bors
Copy link
Contributor

bors commented Jul 25, 2021

💔 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 Jul 25, 2021
@rust-log-analyzer

This comment has been minimized.

@Amanieu
Copy link
Member

Amanieu commented Jul 25, 2021

@bors r+

@bors
Copy link
Contributor

bors commented Jul 25, 2021

📌 Commit 8987b74 has been approved by Amanieu

@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 25, 2021
@bors
Copy link
Contributor

bors commented Jul 25, 2021

⌛ Testing commit 8987b74 with merge 9c25eb7...

@bors
Copy link
Contributor

bors commented Jul 25, 2021

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 25, 2021
@bors bors merged commit 9c25eb7 into rust-lang:master Jul 25, 2021
@rustbot rustbot added this to the 1.56.0 milestone Jul 25, 2021
@a1phyr a1phyr deleted the allocator_api_for_vecdeque branch March 12, 2024 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-allocators Area: Custom and system allocators 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 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.

None yet

8 participants