Sync BTreeMap with stdlib

[exrook]

I've pulled in the changes made to BTreeMap in stdlib that happened since my first pull of the BTreeMap code.

These changes are based off the stdlib BTreeMap as of commit 3a4da87f58099f08620a9a3e812abd77301cafb2

I also sorted the feature flags & lint definitions since they didn't seem to follow any pattern.

[TimDiekmann]

Do you think it's worth the effort on alloc-wg right now as we can push those changes upstream pretty soon?

I'm planing on deprecating this crate after most collections has been updated upstream as there is no point in keeping alloc-wg updated.

[exrook]

I've had the same thoughts, and I've been working on getting the changes pushed in the other direction as well. However the stdlib btreemap implementation diverged a bit since my initial changes, and it was easier to get the new changes working here first. (Notably, I need Box<T, A>, which needs RawVec<T, A> in order to get anything to compile)

[TimDiekmann]

As soon as the stability annotations on generics has landed I'll make a PR for `Box` as pretty much everything depends on it. It's bit tricky though as compiler magic is involved and a crater run has to be done so don't expect it to land before next week. :)

…

On Sep 24, 2020, 23:12, at 23:12, exrook ***@***.***> wrote: I've had the same thoughts, and I've been working on getting the changes pushed in the other direction as well. However the stdlib btreemap implementation diverged a bit since my initial changes, and it was easier to get the new changes working here first. (Notably, I need `Box<T, A>`, which needs `RawVec<T, A>` in order to get anything to compile) -- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #25 (comment)

[exrook]

Yeah I started copying the Box changes from this repo and once I saw #[lang = "owned_box"] I realized it would be quite a bit more involved than I had originally thought :)