Open orlp opened 1 month ago
The problem appears to be that allocator-api2
's recommended usage is inherently flawed:
Your library MAY provide a feature that will enable "allocator-api2/nightly". When this feature is enabled, your library MUST enable unstable
#![feature(allocator_api)]
or it may not compile. If feature is not provided, your library may not be compatible with the rest of the users and cause compilation errors on nightly channel when some other crate enables "allocator-api2/nightly" feature.
Feature unification makes the requirement "When this feature is enabled your library MUST enable unstable #![feature(allocator_api)]
or it may not compile" fundamentally impossible to fulfill.
I'm not sure there's anything actionable we can do on hashbrown's side...
allocator-api2/nightly
re-exports from alloc
, but hashbrown/nightly
is already using alloc
directly -- so I think there's no reason to forward the nightly feature at all. That will mean its Allocator
won't match that from allocator-api2
(without nightly), but really, it's already a breaking change that these features change the types in public API.
If a project (most likely indirectly through dependencies) depends on both version 0.14.x and 0.15.x of hashbrown, and only one of the two dependencies has the
nightly
feature flag set, the project will fail to compile due to using theallocator_api
without enabling the unstable feature for it:This can be reproduced by making a clean new project and adding the following two lines to
Cargo.toml
:If it's just one of the two the project compiles fine, regardless of the
nightly
feature flag. If neither or both have thenightly
feature flag everything compiles fine as well. However if one has thenightly
feature flag and the other does not, the project doesn't compile.