Skip to content

Move HashMap to liballoc #27242

Open
Open
@Gankra

Description

@Gankra

This is blocked on #26870

  • Move FnvHasher from src/librustc/util/nodemap.rs to libcollections
  • Expose FnvHasher as DeterministicState
  • Move HashMap's implementation into libcollections defaulting to DeterministicState
  • Unhardcode HashMap's constructors/methods from using RandomState (instead relying on default fallback)
  • Re-export HashMap in std::collections as pub type HashMap<K, V, S = RandomState> = core_collections::HashMap<K, V, S>
  • Do the same for HashSet
  • Re-export DeterministicState in std as well (so we have a better answer to "HashMap is slow")
  • Document the performance-stability/security tradeoff between DeterministicState and RandomState, and that users of the std facade will get a different default from direct users of libcollections (because RandomState requires OS rng to seed its state)

I am willing to mentor this if someone else wants to do it.

Note that re-exporting HashMap may be the trickiest one; it's not clear to me that it's trivial, and may involve manually re-exporting everything in std::collections::hash_map to get the right behaviour (annoying and potentially fragile).

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-collectionsArea: `std::collections`C-cleanupCategory: PRs that clean code up or issues documenting cleanup.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions