c314a37ea6
It's used by both webrender and fog, and it contains a subtle soundness issue which may affect us, see: * https://github.com/crossbeam-rs/crossbeam/pull/533 * https://twitter.com/khuey_/status/1311641831201857537 Quoting for posterity: > There is a 0.4.4 on a branch and it contains a reversion for the UB > mentioned in https://github.com/crossbeam-rs/crossbeam/pull/533. > > This was causing corruption of jemalloc structures (and ultimately a > deadlock) for us. Update the crate resolving the issue. Differential Revision: https://phabricator.services.mozilla.com/D92046 |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| .cargo-checksum.json | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
| build.rs | ||
README.md
maybe-uninit
Quite often, uses of std::mem::uninitialized() end up in unsound code.
Therefore, the MaybeUninit union has been added to std::mem and std::mem::uninitialized() is being deprecated.
However, MaybeUninit has been added quite recently.
Sometimes you might want to support older versions of Rust as well.
Here is where maybe-uninit comes in: it supports stable Rust versions starting with 1.20.0.
Sadly, a feature-complete implementation of MaybeUninit is not possible on stable Rust.
Therefore, the library offers the guarantees of MaybeUninit in a staged fashion:
-
Rust 1.36.0 onward:
MaybeUninitimplementation of Rust stable is being re-exported -
Rust 1.22.x - 1.35.0: No panicing on uninhabited types, unsoundness when used with types like
boolor enums. However, there is protection from accidentiallyDroping e.g. during unwind! -
Rust 1.20.x - 1.21.x: No support for Copy/Clone of
MaybeUninit<T>, even ifTimplsCopyor evenClone.