-
Notifications
You must be signed in to change notification settings - Fork 119
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
Use allocator-api through allocator-api2 crate #201
Conversation
Apparently this would require bumping MSRV to 1.63 |
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.
Thanks for the PR!
Can we make the dependency optional? Right now, bumpalo
doesn't have any mandatory dependencies, and I'd like to keep it that way.
Additionally, once the dependency is optional, we should have a blurb in the README just before/after the existing blurb for the allocator_api
feature about what enabling it does.
.map(|p| NonNull::slice_from_raw_parts(p, new_layout.size())) | ||
.map(|p| unsafe { | ||
NonNull::new_unchecked(ptr::slice_from_raw_parts_mut(p.as_ptr(), new_layout.size())) | ||
}) |
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.
Why these changes? Seems unnecessary?
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.
To remove all unstable rust features. Except that I had to put one back, so this one may stay as well I guess
How do you suggest enabling "nightly" in |
I found a problem with the approach in So I changed it. |
I tried to forward "nightly" feature back from |
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.
Aside: it seems like it would make sense for allocator_api2
to have a cargo feature that, when enabled, made the crate re-export the std
types/traits rather than polyfilling them. I don't think bumpalo
woulds use that feature, but it would help avoid ecosystem splitting and annoying build errors where some crates are using the actual Allocator
and others are using allocator_api2::Allocator
.
src/lib.rs
Outdated
#![cfg_attr(feature = "allocator_api", feature(allocator_api))] | ||
#![cfg_attr(feature = "nightly", feature(allocator_api))] |
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.
Ideally, the API and cargo features for enabling the nightly allocator API support in bumpalo
wouldn't change just because we can alternatively use the allocator_api2
crate, so the "nightly" feature should keep the "allocator_api" name.
src/lib.rs
Outdated
@@ -1886,6 +1891,7 @@ unsafe impl<'a> alloc::Alloc for &'a Bump { | |||
} | |||
} | |||
|
|||
#[cfg(feature = "allocator_api")] |
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.
This should be
#[cfg(any(feature = "allocator_api", feature = "allocator_api2"))]
It was made like this originally. However this doesn't work since user would have to enable unstable #![feature(allocator_api)] if any crate enables "nightly" in allocator-api2. I found no way to enable #![feature(allocator_api)] conditionally based on allocator-api2 features. I tried different route and make blanket impls of allocator_api2::Allocator for core::alloc::Allocator types. Unfortunately I got stuck on conflicting impls for references. Tried using specialization feature to resolve the conflict, but with no luck. So currently PR is blocked on resolving this issue. I'll return to it later when I have free time again. |
Ok. I think it should be consistent and usable now. |
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.
Looks great, thanks for your patience as we worked out the exact kinks of how the cargo features and cfg
s would work!
It does look like this needs a little rebase to deal with |
"nightly" enables use of unstable allocator_api. "allocator_api" without "nightly" enables usage of allocator-api2
Keep feature semantics
It's ready for merge now |
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.
Thanks!!
Add support for allocator-api2 This change allows using hashbrown with other crates that support `allocator-api2`. It opens possibility for any allocator that supports `allocator-api2` to be used with `hashbrown`. `allocator-api2` mimics types and functions of unstable `allocator-api` feature but works on stable. `hashbrown` will be using `allocator-api2` only when `"nightly" feature is not enabled. Typical use-case for `allocator-api2` is to use it both with and without `"nightly" feature, however `hashbrown` is special-case since it is built as part of `std` and `allocator-api2` is not ready for this. If fitzgen/bumpalo#201 is accepted, explicit support for `bumpalo` would be obsolete. *caveat*: Either `"nightly"`, `"allocator-api2"` or both features should be enabled for `hashbrown` to compile.
@fitzgen can you provide ETA for next release with this? |
Published! |
This change allows to use mirror of the allocator-api on stable channel.
Types imported from
allocator-api2
are reexports fromcore
andalloc
crates when"nightly"
feature is enabled.Otherwise
allocator-api2
defines types to mimic unstablecore
andalloc
types and functions, stable stuff is re-exported.The goal is to add support for
allocator-api2
into as many crates as possible.The
bumpalo
crate is first on the list.