`hashbrown` fails to compile as a transitive dependency

[gootorov]

Hi

When using certain crates (repro below) it is possible for hashbrown to fail to compile, even though it is a transitive dependency.

To reproduce, create a new crate: cargo new --lib hashbrown_issue With the following Cargo.toml:

[package]
name = "hashbrown_issue"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
sqlx = { version = "0.7.2", features = ["runtime-tokio-rustls"], default-features = false }
blink-alloc = { version = "0.3.1", features = ["nightly"] }

And the following src/lib.rs:

#![feature(allocator_api)]

Then, attempt to compile: cargo +nightly build. This produces a lot of similar errors:

error[E0658]: use of unstable library feature 'allocator_api'
    --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.14.2/src/raw/mod.rs:4248:23
     |
4248 |                 alloc.deallocate(ptr, layout);
     |                       ^^^^^^^^^^
     |
     = note: see issue #32838 <https://github.com/rust-lang/rust/issues/32838> for more information
     = help: add `#![feature(allocator_api)]` to the crate attributes to enable

For more information about this error, try `rustc --explain E0658`.
error: could not compile `hashbrown` (lib) due to 292 previous errors

The toolchain used is cargo 1.75.0-nightly (7046d992f 2023-11-08).

This might be related to #417. To be honest, I'm not too sure whether the issue should be opened in hashbrown, or sqlx/blink-alloc/allocator-api2.

Possible workarounds

• Adding hashbrown = { version = "0.14.2", features = ["nightly"] } to Cargo.toml resolves the issue. Even if hashbrown is not used as a direct dependency. However, this is undesirable as it enables a lot of unstable features in hashbrown. Limiting to #![feature(allocator_api)] is preferable.
• Replacing blink-alloc with bumpalo = { version = "3.14.0", features = ["allocator_api"] } also works.

[gootorov]

cc @zakarumych

Your help may be needed here

[zakarumych]

This was kinda expected issue when one crate turns on nightly for allocator-api2 and another one does not.

The workaround is add direct dependency to the crate that does not enable "nightly" and make it enable the feature.