195: Remove rust2015 style docs r=Amanieu a=faern
We juuuust had a release. But when sifting through the docs I stumbled upon a `extern crate parking_lot;`. That felt very ancient. So I removed it.
I also found an example with `use` statements that were not sorted. So very minor, but could fix it while I was at it anyway.
Co-authored-by: Linus Färnstrand <faern@faern.net>
194: Add changelog entries and bump versions for 0.10.0 release r=Amanieu a=faern
We must first let #193 be merged. Otherwise this changelog is not even correct.
There were a lot of changes since last release. But the vast majority is reformatting and re-arranging to reduce the number of unsafe expressions. As well as adding safety invariant documentation and a few tests. These are cool improvements, but does not affect the public API. I can add something about it in the changelog if you think it's worth it.
`lock_api` only has formatting changes and a few documentation improvements, so I don't think it needs a breaking version change. But might be worth releasing anyway to get the improved documentation out.
The date in the changelog is simply tomorrow. Since I did not think we would have time to release today, and I did not want to just go with `2019-XX-YY` either. If we don't think we'll release tomorrow we can just fix that before merging this PR.
Co-authored-by: Linus Färnstrand <faern@faern.net>
193: Misc clippy fixes r=Amanieu a=faern
I went over the crates with Clippy. Some suggested changes are only stylistic, others more optimization oriented. The commit messages should hopefully explain well enough why each change was made. Otherwise see what clippy says on current master :)
I left some warnings, since the suggested changes were not really objectively better, or possibly larger than what I wanted to do right now.
Co-authored-by: Linus Färnstrand <faern@faern.net>
191: Add initial parking_lot_core tests r=Amanieu a=faern
This library could use more tests, to be more robust. This was one of the things pointed out in the review of the integration into std in https://github.com/rust-lang/rust/pull/56410
`WTF::ParkingLot` has a number of tests we can take inspiration from. And this is somewhat of a port of some of those tests. However, when I ported it 1:1 I found a race condition, so I had to implement the semaphore a bit differently.
I also got away without the tests relying on a working mutex or condvar implementation. Because we can't make the `parking_lot_core` tests depend on the higher level `parking_lot`, nor do we want to depend on locking primitives in std if we aim to become the base for those implementations one day.
Co-authored-by: Linus Färnstrand <faern@faern.net>
189: Remove pre 1.36 backwards compatibility code r=Amanieu a=faern
Back when I submitted #185 I did not get the impression that dropping support for older Rust was an option. But it seemed to have gone through without much fanfare in #188, so I guess we can remove all this backwards compatibility code now then.
Co-authored-by: Linus Färnstrand <faern@faern.net>
186: Safe grow_hashtable r=Amanieu a=faern
Calling `grow_hashtable` can't do unsafe stuff unless `HASHTABLE` has been wrongfully manipulated. So there are no safety invariants to uphold as a caller. So it does not need to be `unsafe`. The little unsafe Rust used inside it has instead been contained and documented.
Moving the hardest to understand/read part, linked list handling, into a separate function for isolation and to make it easier to understand on its own.
Co-authored-by: Linus Färnstrand <faern@faern.net>
185: Replace deprecated mem::uninitialized() r=Amanieu a=faern
Follow up to #173. If we vendor the parts of `MaybeUninit` we need for the places where we use it, then we can get rid of all `mem::uninitialized` and still support Rust older than 1.36.
Because my impression is that there is no way `parking_lot` will make it into `std` while using methods `std` has deprecated and explicitly stated no one should use.
I was not able to make the vendored version `#[repr(transparent)]`.
Co-authored-by: Linus Färnstrand <faern@faern.net>
183: Make locking buckets a safe operation r=Amanieu a=faern
There should not be anything `unsafe` about locking `HashTable` buckets. There is no input you can give it, nor state you can cause by calling other public functions in this module that will make the lock bucket functions behave unsafely. Unless I missed some aspect of course.
I first made `get_hashtable` and `create_hashtable` return static safe references instead of raw pointers, so working with the returned HashTable became a bit easier. The returned pointers are going to always point to valid HashTables anyway, so I did not see anything unsafe about it. The tables might become inactive, but they will still be there, and never unsafe to access.
Co-authored-by: Linus Färnstrand <faern@faern.net>
Paulo