latest/recent rev appears to break ahash/compile-time-rng usage

[sleffler]

We've been using hashbrown in an embedded environment (no os rng) with:

hashbrown = { version = "0.11", features = ["ahash-compile-time-rng"] }

recent (maybe) changes removed the "ahash-compile-time-rng" feature. The current hashbrown Cargo.toml depends on ahash with:

ahash = { version = "0.8.0", default-features = false, optional = true }

which causes ahash to use fixed entropy to generate keys. I don't see how to configure hashbrown so that it depends on ahash with compile-time-rng? (w/o forking/patching the crate)

Am I missing something?

[Amanieu]

Hashbrown doesn't make any guarantees about the hasher and opts for the fastest performance. If you have specific requirements for a random seed then you should use the ahash crate directly.

[sleffler]

Yes, this is not your issue (and thank you for the subtle pointer to the _with_capacity_and_hasher api). I've tracked this down to the latest rev of the const-random crate that ahash depends on--it breaks my no_std usage.

…

On Mon, Oct 23, 2023 at 4:05 PM Amanieu ***@***.***> wrote: Hashbrown doesn't make any guarantees about the hasher and opts for the fastest performance. If you have specific requirements for a random seed then you should use the ahash crate directly. — Reply to this email directly, view it on GitHub <#478 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRM7IP7S4657UHBU4L7OKLYA3Z5HAVCNFSM6AAAAAA6MZHRI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGE3DGNJQG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>