Skip to content
This repository has been archived by the owner on Nov 27, 2020. It is now read-only.

AllocRef support for BTreeMap #21

Merged
merged 12 commits into from
Aug 28, 2020
Merged

Conversation

exrook
Copy link
Contributor

@exrook exrook commented Jul 9, 2020

Hello, I have modified BTreeMap to optionally work with AllocRef instead of the global allocator.

The diff shown in the PR is extremely large because I first had to copy BTreeMap into the repo, you can view the commit with just the changes for AllocRef support here: 40196f9

The code passes the stdlib BTreeMap unit tests but I have not yet tested the new apis supporting AllocRef, hopefully the changes I've made so far can be further validated and serve as a starting point for more detailed design discussion.

@TimDiekmann
Copy link
Owner

Thanks for the PR, I'll take a look into this as soon as possible (probably next week).

Copy link
Owner

@TimDiekmann TimDiekmann left a comment

Choose a reason for hiding this comment

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

I'm willing to merge this after the CI and the comments has been fixed.

src/btree/map.rs Outdated Show resolved Hide resolved
src/collections.rs Outdated Show resolved Hide resolved
.eq(data.clone().into_iter().filter(|x| *x < key))
);
assert!(right.into_iter().eq(data.into_iter().filter(|x| *x >= key)));
}
Copy link
Owner

Choose a reason for hiding this comment

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

We might want at least some test with an allocator.

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'm not sure how to approach this, since BTreeMap::new() does create a BTreeMap with an allocator, it just happens to be the global one, all the tests already use an allocator. I think there would be value in having tests with an allocator that's not the global one, in case there's some behavior that can differ in other allocators.

@exrook exrook force-pushed the master branch 2 times, most recently from d79b3ea to abddef1 Compare August 3, 2020 21:34
@TimDiekmann
Copy link
Owner

You might want to allow clippy errors on the file, I don't think there is a point in changeing all those errors in this crate, this should be changed upstream.

@exrook
Copy link
Contributor Author

exrook commented Aug 3, 2020

Alright, I've reverted those changes and disabled the warnings. The clippy (and maybe rustfmt) check seems to be failing because it doesn't support running on a fork.

@TimDiekmann
Copy link
Owner

Could you provide a diff-link for your changes and the upstream implementation? Otherwise it's almost impossible to review 🙂

@exrook
Copy link
Contributor Author

exrook commented Aug 4, 2020

exrook/alloc-wg@168bac8...master Here's the functional changes made.

exrook/alloc-wg@67fd9ee...168bac8 Here are the changes I needed to make to get the code to compile outside of stdlib.

@TimDiekmann
Copy link
Owner

Changes looking good, however there are still around 200 clippy errors (stopped counting at 150). Also, rustfmt still has one error. Running clippy on a fork runs fine, it just don't create inline annotations.

@exrook exrook force-pushed the master branch 3 times, most recently from 8770be6 to 53d68cf Compare August 27, 2020 20:08
@TimDiekmann
Copy link
Owner

Thank you for the effort!

@TimDiekmann TimDiekmann merged commit 9ae078b into TimDiekmann:master Aug 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants