Vendor dependencies

notes-service/vendor/bitvec/doc/serdes/array.md

@@ -0,0 +1,26 @@
+# Bit-Array De/Serialization
+
+The Serde model distinguishes between *sequences*, which have a dynamic length
+which must always be transported with the data, and *tuples*, which have a fixed
+length known at compile-time that does not require transport.
+
+Serde handles arrays using its tuple model, not its sequence model, which means
+that `BitArray` cannot use the `BitSlice` Serde implementations (which must use
+the sequence model in order to handle `&[u8]` and `Vec<T>` de/serialization).
+Instead, `BitArray` has a standalone implementation using the tuple model so
+that its wrapped array can be transported (nearly) as if it were unwrapped.
+
+For consistency, `BitArray` has the same wire format that `BitSlice` does; the
+only distinction is that the data buffer is a tuple rather than a sequence.
+
+Additionally, Serde’s support for old versions of Rust means that it only
+implements its traits on arrays `[T; 0 ..= 32]`. Since `bitvec` has a much
+higher MSRV that includes support for the const-generic `[T; N]` family, it
+reïmplements Serde’s behavior on a custom `Array<T, N>` type in order to ensure
+that all possible `BitArray` storage types are transportable. Note, however,
+that *because* each `[T; N]` combination is a new implementation, de/serializing
+`BitArray`s directly is a great way to pessimize codegen.
+
+While it would be nice if `rustc` or LLVM could collapse the implementations and
+restore `N` as a run-time argument rather than a compile-time constant, neither
+`bitvec` nor Serde attempt to promise this in any way. Use at your discretion.

notes-service/vendor/bitvec/doc/serdes/slice.md

@@ -0,0 +1,14 @@
+# Bit-Slice De/Serialization
+
+Bit-slice references and containers serialize as sequences with additional
+metadata.
+
+Serde only provides a deserializer for `&[u8]`; wider integers and
+interior-mutability wrappers are not able to view a transport buffer without
+potentially modifying it, and the buffer is not modifiable while being used for
+deserialization. As such, only `&BitSlice<u8, O>` has a no-copy deserialization
+implementation.
+
+If you need other storage types, you will need to deserialize into a `BitBox` or
+`BitVec`. If you do not have an allocator, you must *serialize from* and
+deserialize into a `BitArray`.

notes-service/vendor/bitvec/doc/serdes/utils.md

@@ -0,0 +1,26 @@
+# De/Serialization Assistants
+
+This module contains types and implementations that assist in the
+de/serialization of the crate’s primary data structures.
+
+## `BitIdx<R>`
+
+The `BitIdx` implementation serializes both the index value and also the
+bit-width of `T::Mem`, so that the deserializer can ensure that it only loads
+from a matching data buffer.
+
+## `Array<T, N>`
+
+Serde only provides implementations for `[T; 0 ..= 32]`, because it must support
+much older Rust versions (at time of writing, 1.15+) that do not have
+const-generics. As `bitvec` has an MSRV of 1.56; it *does* have const-generics.
+This type reïmplements Serde’s array behavior for all arrays, so that `bitvec`
+can transport any `BitArray` rather than only small bit-arrays.
+
+## `Domain<Const, T, O>`
+
+`BitSlice` serializes its data buffer by using `Domain` to produce a sequence of
+elements. While the length is always known, and is additionally carried in the
+crate metadata ahead of the data buffer, `Domain` uses Serde’s sequence model in
+order to allow the major implementations to use the provided slice or vector
+deserializers, rather than rebuilding even more logic from scratch.