We have a recommendation from the unsafe-wg (no rule yet), that
repr(C) for unions should work this way, so that we can cast from the
union type to one of its fields.
We can't fix this properly (MaybeUninit with a union) until we change
the user visible API (we need to require that A: Copy.
As a temporary solution for arrayvec version 0.4.*, we use zeroed to
initialize an array of bytes, instead of using uninitialized. This may
have a negative performance impact, but the fix is to upgrade to future
arrayvec 0.5.
Use a build script to detect if we can use MaybeUninit or NoDrop.
Enabling unstable features automatically is not ideal, but since it's
a soundness issue we should do it.
Use a MaybeUninit-like union on nightly when we can. We use a feature
detection script in build.rs, so that we also go back to the fallback if
the unstable feature changes in an unexpected way.
We need to continue to use NoDrop for best working stable
implementation, but we eagerly use our union solution where we can,
currently only in nightlies.
Rustc feature probe code written by Josh Stone (cuviper),
taken from num-bigint.
This way we cover all users up to 256 at least. The reason these are not
enabled by default is that they slow down the compilation of the crate
by a factor of 2-3x.
```
warning: the type of this value must be known in this context
--> src/lib.rs:312:32
|
312 | ptr::copy(p, p.offset(1), len - index);
| ^^^^^^
|
= note: #[warn(tyvar_behind_raw_pointer)] on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #46906 <https://github.com/rust-lang/rust/issues/46906>
```
Copy the required unreachable and debug assertion; saves us dependency
on odds.
We could also depend on crate unreachable, but that adds dep on
2 microcrates.
Instead of being vague about it, we can promise it.
We continue to be a bit vague in ArrayString::set_len. I don't see how
to add a char boundary check in ArrayString::set_len unfortunately.
It's a tricky issue, checking char boundaries requires reading the
memory of the string, and we don't even know if the user of set_len has
initialized that area of memory yet (but they hopefully did).
bluss