Update hashbrown to 0.8.1

[Amanieu]

This update includes:

• Optimize Clone implementation hashbrown#146, which improves the performance of Clone and implements clone_from.
• Another attempt to reduce size_of<HashMap> hashbrown#159, which reduces the size of HashMap by 8 bytes.
• Avoid creating small tables with a capacity of 1 hashbrown#162, which avoids creating small 1-element tables.

Fixes#28481

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[Centril]

@bors rollup=never

[Mark-Simulacrum]

Looking over the diff in the PR you linked, this adds two uses of specialization to hashbrown which I believe carry over into std. I believe we are currently trying to vet specialization before adding more copies by ccing lang folks.

• https://github.com/rust-lang/hashbrown/pull/146/files#diff-178822c448ce6afe0e383be6f514626eR215-R233
• https://github.com/rust-lang/hashbrown/pull/146/files#diff-1b47db5c9a30eca8cfa833e56ecf2c4eR1034-R1066

I am unsure who the "experts" here are, but let's try @nikomatsakis and perhaps @Centril first?

[Centril]

I am unsure who the "experts" here are, but let's try @nikomatsakis and perhaps @Centril first?

cc @matthewjasper

[Centril]

Aside: reliance on default fn as a syntax here is implemented in a problematic way. The right way to do it is to delay parsing in a macro or move the default fns to a separate external module that is cfged. The way this is done in the diffs above, we will have a headache if we ever decide to change the syntax for specialization, so this should be fixed.

[Amanieu]

Could you give an example of how delayed parsing with a macro would work?

Is it something like this?

#[cfg(feature = "nightly")]macro_rules! default_fn {($($x:tt)*) => {default $($x)*}}#[cfg(not(feature = "nightly"))]macro_rules! default_fn {($($x:tt)*) => {
$($x)*}}

[Centril]

@Amanieu Example due to @petrochenkov#65860 (comment).

[Amanieu]

I started a PR at rust-lang/hashbrown#147, let me know if any other changes are needed.

[matthewjasper]

min_specialization is in the next nightly.
I would prefer either min_specialization to be used if possible or a sepatate feature flag if not.

[Amanieu]

I tried compiling with min_specialization, but got these errors:

error: cannot specialize on trait `core::marker::Copy`
--> src/raw/mod.rs:1047:1
|
1047 | / impl<T: Copy> RawTableClone for RawTable<T> {
1048 | | #[cfg_attr(feature = "inline-more", inline)]
1049 | | unsafe fn clone_from_spec(&mut self, source: &Self, _on_panic: impl FnMut(&mut Self)) {
1050 | | source
... |
1060 | | }
1061 | | }
| |_^
error: cannot specialize on trait `core::cmp::Eq`
--> src/map.rs:225:9
|
225 | / impl<K: Clone, V: Clone, S> HashClone<S> for HashMap<K, V, S>
226 | | where
227 | | K: Eq + Hash,
228 | | S: BuildHasher,
... |
234 | | }
235 | | }
| |_________^
error: cannot specialize on trait `core::hash::Hash`
--> src/map.rs:225:9
|
225 | / impl<K: Clone, V: Clone, S> HashClone<S> for HashMap<K, V, S>
226 | | where
227 | | K: Eq + Hash,
228 | | S: BuildHasher,
... |
234 | | }
235 | | }
| |_________^
error: cannot specialize on trait `core::hash::BuildHasher`
--> src/map.rs:225:9
|
225 | / impl<K: Clone, V: Clone, S> HashClone<S> for HashMap<K, V, S>
226 | | where
227 | | K: Eq + Hash,
228 | | S: BuildHasher,
... |
234 | | }
235 | | }
| |_________^

[Amanieu]

If I'm understanding the min_specialization documentation correctly, this means that we need to add #[rustc_specialization_trait] on Copy, Eq, Hash and BuildHasher. Is that correct?

[bors]

☔ The latest upstream changes (presumably #69470) made this pull request unmergeable. Please resolve the merge conflicts.

[Mark-Simulacrum]

@matthewjasper Could you perhaps help @Amanieu with the answer to the above question?

[nikomatsakis]

I'm trying to remember under what conditions adding rustc_specialization_trait makes sense. I'm a bit nervous about us adding it loosely. But I guess I'll wait until @matthewjasper weighs in -- or else I should go refresh my memory perhaps of what precisely it means and when it's ok to use it. =)

[Centril]

@Amanieu Could we drop the specializations meanwhile to land the other bits sooner?

[Amanieu]

The specializations are really the only significant improvement that is relevant to libstd. There's not much point in upgrading otherwise.

[Centril]

r? @matthewjasper

[matthewjasper]

rustc_specialization_trait can't be added to stable traits since it prevents implementations in crates which don't have feature(min_specialization) or feature(specialization).
Copy might get rustc_unsafe_specialization_marker on it temporarily, but it's not really correct and i don't want crates outside of std rely on it when it's removed.

[Amanieu]

Hmm, upon further review I do believe that the specialization on Eq + Hash + BuildHasher is unsound. I reverted it in hashbrown 0.7.2.

The other one uses Copy, which could be made to work with rustc_unsafe_specialization_marker. I think it should be fine to rely on this since:

• this is only used when the "nightly" feature of hashbrown is used. It is acceptable for compiler updates to break people who have opted into using nightly features.
• the use of specialization is an implementation detail and can be reverted at any time without any change to the API.
• hashbrown is maintained by the libs team and can quickly react to any changes in the compiler regarding specialization.

[bors]

💔 Test failed - checks-actions

[bors]

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

[Amanieu]

@bors r=Mark-Simulacrum

[bors]

📌 Commit e46bb17 has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit e46bb17 with merge 8b26609...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: Mark-Simulacrum
Pushing 8b26609 to master...