This is a soundness fix w.r.t unsafe coding guidelines.
In some of the instances, `get_unchecked_mut() -> &mut T as *mut T` was
used in places where the element was potentially uninitialized.
This was a problem in push. (Not a problem in IntoIter next/next_back,
where the whole range we're iterating is initialized).
Using the following principles:
- Trivial methods (empty and simple constants) can be inline(always)
- Generic methods don't need any inlining directive at all.
..with the exception of Deref which just seems to be extra important.
- Non-generic items use #[inline] to enable inlining at the
compiler's discretion.
This is a nicer and simpler interface to expose, since the ref to uninit
array to pointer cast is not usable anyway (it's historic now, arrayvec
itself does not use it anymore).
The raw pointer walk did not do the right thing for ZST, because when
offsets are zero, the start and end pointer would be the same and the
loop ends before incrementing the length correctly.
This is the "real" union solution, and ArrayString can use it since its
backing array is Copy. Unfortunately, we'll have to use the Copy bound
on the type, making it "viral" and visible in the user API.
* '0.4' of https://github.com/bluss/arrayvec:
0.4.9
TEST: Add test that ensures the MaybeUninit impl is used on nightly
FIX: Remove use of uninitialized in ArrayString
FEAT: Implement a "MaybeUninit" and use it conditionally
TEST: Add test that Some(ArrayVec<[&_;_]>).is_some()
MAINT: Test the 0.4 branch in travis
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.
Again, stacked borrows model makes the `self.set_len()` call illegal
because we are holding (and are going to use) another raw pointer
derived from self, `tail`.
This simplification -- borrowing self.len instead of self, leads to
an improvement in the extend_from_slice benchmark.
It's also guided by the discussion of stacked borrows; the old code
would be invalid, because the whole self is borrowed while ptr is derived from
self.
This should perform better in both release and debug mode.
NOTE: This is significant because it changes the drop order of the
elements, and how we handle panicking destructors. If just one of the
destructors panic during ArrayVec drop, clear or truncate, the rest of
the elements should still drop. If we encounter another panic during
that process, however, Rust will abort as usual for panic during
unwinding.
```
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>
```
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).
Phlosioneer