Tracking Issue for const_collections_with_hasher

[aDotInTheVoid]

Feature gate: #![feature(const_collections_with_hasher)]

This is a tracking issue for making HashMap::with_hasher and HashSet::with_hasher const.

Public API

// std::collections
impl<K, V, S> HashMap<K, V, S> {
    pub const fn with_hasher(hash_builder: S) -> HashMap<K, V, S> { ... }
}

impl<T, S> HashSet<T, S> {
    pub const fn with_hasher(hasher: S) -> HashSet<T, S> { ... }
}

Steps / History

• Implementation: Make Hash{Set,Map}::with_hasher unstably const #102574
• Final comment period (FCP)¹
• Stabilization PR ( const-stabilize HashMap/HashSet::with_hasher (+ required compiller changes) #118427)

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[GoldsteinE]

What blocks this from stabilization? Can I do something to move it forward?

[aDotInTheVoid]

@GoldsteinE: see https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

Main questions for stabilization are do we want to add the constraint that an empty hashmap can be const constructed (ie doesn't alloc and more). This is true for the current hashbrown design, but might not be true for other alternatives. I'm not framiliar enough with hashmap design to say.

[Amanieu]

This is fairly straightforward, we are essentially guaranteeing that a newly created HashMap does not allocate any memory.

@rfcbot fcp merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[aDotInTheVoid]

Trying to stabilize this, I run into this error:

error: `hashbrown::HashMap::<K, V, S>::with_hasher` is not yet stable as a const fn
   --> library/std/src/collections/hash/map.rs:292:25
    |
292 |         HashMap { base: base::HashMap::with_hasher(hash_builder) }
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |

This code here

rust/compiler/rustc_const_eval/src/transform/check_consts/check.rs

Lines 984 to 995 in 9bd71af

	// FIXME(ecstaticmorse); For compatibility, we consider `unstable` callees that
	// have no `rustc_const_stable` attributes to be const-unstable as well. This
	// should be fixed later.
	let callee_is_unstable_unmarked = tcx.lookup_const_stability(callee).is_none()
	&& tcx.lookup_stability(callee).is_some_and(|s| s.is_unstable());
	if callee_is_unstable_unmarked {
	trace!("callee_is_unstable_unmarked");
	// We do not use `const` modifiers for intrinsic "functions", as intrinsics are
	// `extern` functions, and these have no way to get marked `const`. So instead we
	// use `rustc_const_(un)stable` attributes to mean that the intrinsic is `const`
	if self.ccx.is_const_stable_const_fn() || tcx.is_intrinsic(callee) {
	self.check_op(ops::FnCallUnstable(callee, None));

seems to think it's unstable, despite hashbrown having no stability annotations. CC @ecstatic-morse

[aDotInTheVoid]

Solved in #118423 by changing the compiler to respect rustc_allow_const_fn_unstable here. This requires new semantics as there's no feature gate on the hashbrown side, so I said any will work here. Not sure if this is OK.

This also means a load of ugly things are needed to be cfg_attr(bootstrap, ...)ed

@rustbot claim