-
Notifications
You must be signed in to change notification settings - Fork 287
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
Fix index calculation in panic guard of clone_from_impl #511
Conversation
Previously, it was possible for an uninitialized element to be dropped if all of the following occurred: - `clone_from` was called where `T: !Copy`. - The `clone` implementation of `T` panicked. - The first bucket of the source `HashMap` contained an entry.
This is a new lint introduced in rustc.
4a3334a
to
309c473
Compare
37864e7
to
a5eddff
Compare
@bors r+ |
☀️ Test successful - checks-actions |
It looks like this issue (different optimizations with latest Rust 1.77+ and / or LLVM?) is now happening much more frequently. The Fedora Linux CI for hashbrown has started to fail quite often due to test failures that would be fixed by this commit. Since v0.14.4 was yanked due to breaking API changes, this fix never landed in a non-yanked stable release of hashbrown. Would it be possible to backport this onto a v0.14 branch based on v0.14.3 and release it as v0.14.5? |
@decathorpe I released v0.14.5 |
Great, thank you! |
Previously, it was possible for an uninitialized element to be dropped if all of the following occurred:
clone_from
was called whereT: !Copy
.clone
implementation ofT
panicked.HashMap
contained an entry.Fixes #510