ba2a3835f3
This should help us isolate what rayon changes could've caused this stability issue on 32-bit windows. Automatically generated with: $ cargo update -p rayon --precise 1.4.1 && cargo update -p rayon-core --precise 1.8.1 && ./mach vendor rust Differential Revision: https://phabricator.services.mozilla.com/D108045 |
||
|---|---|---|
| .. | ||
| 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.