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.
With the release of arrayvec 0.5, these crates are unused.
With the release of Rust 1.36 and MaybeUninit, these crates have no
purpose (but for older Rust releases).
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 very useful for generic code that may want to parse arbitrary
input string into arbitrary other types.
Limitations of the FromStr trait don't allow us to keep the original string slice
inside the CapacityError, unfortunately.
bluss