-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for const_collections_with_hasher
#102575
Comments
…th_hasher, r=oli-obk,fee1-dead Make Hash{Set,Map}::with_hasher unstably const Makes [`HashMap::with_hasher`](https://doc.rust-lang.org/stable/std/collections/hash_map/struct.HashMap.html#method.with_hasher) and [`HashSet::with_hasher`](https://doc.rust-lang.org/stable/std/collections/hash_set/struct.HashSet.html#method.with_hasher) `const`. This allows ```rust static GlobalState: Mutex<HashMap<i32, i32, SomeHasher>> = Mutex::new(HashMap::with_hasher(SomeHasher::new())) ``` Tracking issue: rust-lang#102575
What blocks this from stabilization? Can I do something to move it forward? |
@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. |
This is fairly straightforward, we are essentially guaranteeing that a newly created @rfcbot fcp merge |
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: 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. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
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. |
Trying to stabilize this, I run into this error:
This code here rust/compiler/rustc_const_eval/src/transform/check_consts/check.rs Lines 984 to 995 in 9bd71af
seems to think it's unstable, despite |
Solved in #118423 by changing the compiler to respect This also means a load of ugly things are needed to be @rustbot claim |
Because std's dependencies are build with `-Zforce-unstable-if-unmarked` normally, std is unable to call them in const-stable function. However, becuase they had no explicit feature gates, there was no way to use `rustc_allow_const_fn_unstable` to allow this. Therefor we add `#[rustc_allow_const_fn_unstable(any)]` to allow using these functions. The reson to do this is rust-lang#102575, which relies on calling hashbrow function in const-stable std functions.
Can we get an ETA how many years will this approximately take to stabilize? How can I speed this process? Or should I just write my own hashmap or use alloc::collections::BTreeMap? Thanks ahead for any info. |
Sorry, I should have given an update to this. The FCP’s been approved, so the only thing remaining it to actually do the stabilisation. Unfortunately that’s actually tricky in this case, due to HashMap being implemented in an external crate (hashbrown), it has really painful interactions with the const-stability checker. Those checks are currently being rewritten in #131349, so after that lands it should be possible to try again if you (or someone else) wants to work on it. |
I am planning to make this possible as part of finishing my work on #129815. The external hashbrown crate will also need some changes. However, you won't be able to construct a |
better test for const HashMap; remove const_hash leftovers The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (rust-lang#123197), so we also have a test that does not involve that type. The second commit removes the last remnants of rust-lang#104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`. Cc `@rust-lang/libs-api` `@rust-lang/wg-const-eval` Closes rust-lang#104061 Related to rust-lang#102575
better test for const HashMap; remove const_hash leftovers The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (rust-lang#123197), so we also have a test that does not involve that type. The second commit removes the last remnants of rust-lang#104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`. Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval`` Closes rust-lang#104061 Related to rust-lang#102575
better test for const HashMap; remove const_hash leftovers The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (rust-lang#123197), so we also have a test that does not involve that type. The second commit removes the last remnants of rust-lang#104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`. Cc ```@rust-lang/libs-api``` ```@rust-lang/wg-const-eval``` Closes rust-lang#104061 Related to rust-lang#102575
better test for const HashMap; remove const_hash leftovers The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (rust-lang#123197), so we also have a test that does not involve that type. The second commit removes the last remnants of rust-lang#104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`. Cc `@rust-lang/libs-api` `@rust-lang/wg-const-eval` Closes rust-lang#104061 Related to rust-lang#102575
better test for const HashMap; remove const_hash leftovers The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (rust-lang#123197), so we also have a test that does not involve that type. The second commit removes the last remnants of rust-lang#104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`. Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval`` Closes rust-lang#104061 Related to rust-lang#102575
Rollup merge of rust-lang#132503 - RalfJung:const-hash-map, r=Amanieu better test for const HashMap; remove const_hash leftovers The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (rust-lang#123197), so we also have a test that does not involve that type. The second commit removes the last remnants of rust-lang#104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`. Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval`` Closes rust-lang#104061 Related to rust-lang#102575
The PR that should enable us to safely expose (That's just the infrastructure for this, once it lands, a bit of wiring-up needs to happen in hashbrown.) |
Cc @rust-lang/wg-const-eval |
bump hashbrown version This pulls in rust-lang/hashbrown#586, in preparation for rust-lang#102575. Cc `@Amanieu`
bump hashbrown version This pulls in rust-lang/hashbrown#586, in preparation for rust-lang#102575. Cc ``@Amanieu``
Rollup merge of rust-lang#133670 - RalfJung:hashbrown, r=Amanieu bump hashbrown version This pulls in rust-lang/hashbrown#586, in preparation for rust-lang#102575. Cc ``@Amanieu``
Feature gate:
#![feature(const_collections_with_hasher)]
This is a tracking issue for making
HashMap::with_hasher
andHashSet::with_hasher
const
.Public API
Steps / History
Unresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: