Added utils module with a `MaybeUninit` helper type to construct `[MaybeUninit<T>; N]`
Removed all uses of the "unstable-const-fn" feature, and documented it as being deprecated.
Changed `assert_capacity_limit` macro to work in const contexts.
Store the length as u32 internally. This is to shrink the size of the
ArrayVec value (when possible, depending on element type).
Inline storage vectors larger than u32::MAX are very unlikely to be
useful - for these cases, prefer using Vec instead.
It's not possible to have the CAP type parameter be of type u32 (missing
features in const evaluation/const generics). We also have to panic at
runtime instead of having a static assertion for capacity, for similar
reasons.
Prefer ManuallyDrop instead of forget (more modern style preference -
with the benefit that the ManuallyDrop style sets up the non-dropping
before taking further actions).
This regresses performance of the .extend(s) benchmark where s is a
slice; to compensate add a private extend_from_slice method that we can
use where possible (clone_from, try_from).
We were using &mut [u8] in encode_utf8, but this is not right according
to the developing unsafe coding guidelines. We need to use raw pointers
to write to possibly uninit memory.
We use a raw pointer form for encode_utf8. It was first attempted to
encapsulate the trusted-to-be-valid raw pointer in a simple { *mut u8,
usize } struct, but the current way of passing ptr and len separately
was the only way to not regress performance.
This impl maintains the same performance in arraystring benches.
Add exhaustive-style tests for encode_utf8
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.
bluss