-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Update hashbrown to version 0.15, with changes that were blocked by that release #131178
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
Conversation
|
Some changes occurred in cfg and check-cfg configuration cc @Urgau These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
d058e12 to
347dd7c
Compare
| .expecteds | ||
| .get_many_mut(VALUES) | ||
| .expect("unable to get all the check-cfg values buckets"); | ||
| .map(|x| x.expect("unable to get all the check-cfg values buckets")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried updating this code in a few different ways but ultimately, this felt like the least-invasive way to make the change. I don't fully understand what this code is doing (and didn't really bother to figure out), so, someone else can change this code later if they find a better way of doing it.
Plus, a panic is an ICE anyway, so, if this causes any noticeable difference in behaviour it was a bug anyway.
|
Just kidding, I had searched for an existing PR and hadn't found one. Will close this and just reopen my other PR. >< |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Going over the changes:
The obvious
hashbrownhas been set to version 0.15 inlibrary/std/Cargo.toml, and acargo updatefor thestdcrate has been performed. This also bumps the version of thecccrate inCargo.lock, but I didn't think it was worth removing this change by hand, since it's just a bugfix release.map_entry_replaceThere was an FCP that decided to remove these unstable methods, but no PR was actually submitted to do so: #44286 (comment)
Since
hashbrownhas removed these methods, they are removed with the update as well.map_many_mutThe unstable APIs for
HashMap::get_many_mutandHashMap::get_many_unchecked_muthave been transposed from returningOption<[&mut V; N]>to returning[Option<&mut V>; N].This was based upon a libs-api decision here: #97601 (comment)
hash_set_entryThe unstable
HashSet::get_or_insert_ownedAPI was removed in favour of the also-unstableHashSet::get_or_insert_with. There wasn't much discussion here that I could find, but essentially, both of these methods have the same problem of having to verify that the keys are equivalent after the fact, and theownedvariant was removed fromhashbrown, which seems to indicate some kind of consensus.Since this API is unstable, it doesn't need an FCP, but since I don't think there was any official consensus on it, someone from libs-api should probably sign this off. If you'd prefer to retain the
ownedvariant of the method, it can easily be reimplemented on top of the hashbrown API which only offers awithvariant.default_iters_hashThese are instantly-stable, but already passed FCP here: #128711 (comment)
They were blocked by a hashbrown release containing the necessary impls, so, that's why they're included in this PR.
r? libs-api