Bad use of `mem::uninitialized` in constructor

[Felix S Klock II]

Spawned from rust-lang/rust#58684

The following test is likely to fail in the current code base, at least for many versions of rustc.

    #[test]
    fn test_option_encoding() {
        let tester: ArrayDeque<[Box<()>; 100], Wrapping> = ArrayDeque::new();
        assert!(Some(tester).is_some());
    }

The reason it will fail is because ArrayDeque::new() is using mem::uninitialized to create the array itself, which is discouraged because the resulting value will tend to yield undefined behavior unless the type is valid for all possible bit patterns. (And an easy example of a type that is not valid for all possible bit patterns is Box<T>, since it must be non-null.)

The test above is demonstrating how violating this rule can break invariants like Some(E).is_some() for any E.

• One potential fix for this has been pointed out by oli: Use an untagged union instead of mem::uninitialized.
• Another potential fix would be to use MaybeUninit instead of ManuallyDrop, as pointed out by nagisa.

Neither of these fixes is available in stable Rust today, though. (untagged unions only support Copy data if you're on stable.)

[Felix S Klock II]

Since this library was inspired by bluss/arrayvec, see also bluss/arrayvec#105 and bluss/arrayvec#118, which discusses similar issues, and PRs bluss/arrayvec#114 and bluss/arrayvec#116, which demonstrate the changes that library has adopted in attempting to resolve those problems.

[Andy Lok]

Thanks for bringing this up! And arrayvec shows me a good trick to solve it.