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
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).
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.
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.
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).
This implements serde support under the optional 'serde' feature, and adds unit tests to test said support.
https://serde.rs/unit-testing.html used as a guide for the unit tests - using 'serde_test' makes for much
less boilerplate here, but it does require that the project have a non-optional dev dependency on 'serde_test'.
Previously we used formatting, which is a virtual call and quite the
detour. Now copy the utf-8 encoding code from Rust (thank you Alex
Crichton) and use that.
bluss