In the Enums section, there are examples using the second and third variants of an enum, but the comment incorrectly refers to them as "first variant".
Unless perhaps the intention here was to say "the variant is first"?
* Made arrays with 32 elements or less never encode their length
* Removed `write_fixed_array_length` and `skip_fixed_array_length` as this was based on incorrect assumptions on how serde and bincode 1 works
---------
Co-authored-by: Victor Koenders <victor.koenders@qrtech.se>
* Improved encoding and decoding speed of Vec<u8>
* Added black_box calls to benches/string.rs
Added a SizeWriter because someone finally has a benchmark to show it's faster
* Improved performance for `impl<T> Encode for [T]`
* Added #[inline] to `impl Encoder for EncoderImpl`
---------
Co-authored-by: Victor Koenders <victor.koenders@qrtech.se>
* Added `[serde(tag)]` to the list of tags that are known to give issues
* Removed the old warning about serde and no-std. Added references to the documentation in the serde::DecodeError enum
This makes it match the implementation for Decode which is
already supports up to 16 fields.
Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>
Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>
* Shrink `DecodeError` to 32 bytes on 64-bit arch
* Nul with a single l
* fmt
* Consider feature combinations for error sizes
* Remove superfluous `any`
* fmt
* Box SystemTime in EncodeError
* Add impl Encode for [T], where T: Encode
Since Encode takes a reference, this allows us to encode &[T] directly
using this implementation. The encoding scheme is the same as for
Vec<T>.
This also makes the implementation for &[u8] superfluous, since we get
an implementation for [u8] by virtue of u8 implementing encode. This
also gives us free implementations for &[u16], &[u32], etc. which is
quite useful. Nonetheless, we keep the implementation for &[u8] around,
because the implementation can directly write a large number of bytes,
which can be more efficient than the generic implementation.
* Remove redundant Encode implementations
Since we've implemented Encode for [T], this makes the implementation
for Box<[T]> redundant (since we have a blanket implementation for
Box<T>), and ditto for &[T], which this change replaces by combining the
implementations for [T] and &T.
* Reinclude comment about Encode specialization for &[u8]
* Rewrite: seperated Decode and BorrowDecode
* Fixed cargo.toml issues
* Fixed clippy warning
* Removed the `impl_tuples` macro call with manually exported code
* Replaced the generated code in `impl_tuples` with the macro instead
* Implemented BorrowDecode for Box<[T]>
* Added a test to see if zoxide can be ported to bincode 2
* Added a test for Arc<str>
* Made several `Encode` implementations require `T: ?Sized`
* Implemented Decode for Arc<str>
* Added BlockedTODO links to commented out code
* Fixed clippy and lint issues
* Updated virtue dependency in fuzz lockfile
* Switched to weak dependencies
* Removed old `serde_impl` references
* Fixed CI and updated documentation
* Fixed a cfg for a test
* Removed unneeded package in Cargo.toml
* Fixed cross platform targets
* Uncommented not working archs, with a reason why they fail
* Removed duplicate windows test
* Commented the other sun system
* Commented out i686-pc-windows-gnu
Co-authored-by: Victor Koenders <git@github.com>
* tests: fix alloc range test on 32-bit Windows
This test checks the range, which is necessarily different when running
on another platform.
Signed-off-by: Sean Cross <sean@xobs.io>
* enc: case usize/isize as u64/i64 in serialization
The deserialization process assumes that usize/isize are 64-bits, as
does the spec at
https://github.com/bincode-org/bincode/blob/trunk/docs/spec.md#varintencoding
Force `usize` and `isize` to be encoded as `u64` and `i64` to force
32-bit platforms to conform to this spec.
This fixes running tests under `cargo test --target i686-pc-windows-msvc`
Signed-off-by: Sean Cross <sean@xobs.io>
* atomic: only provide Atomic*64 on supported platforms
Not all platforms support AtomicI64 or AtomicU64. Use the
`target_has_atomic` config flag to determine whether to include these.
This fixes#532.
Signed-off-by: Sean Cross <sean@xobs.io>
* atomic: remove feature and use new attributes
Now that there is an attribute to indicate which atomic features are
supported on this platform, remove the `atomic` Feature and use these
new attributes.
Signed-off-by: Sean Cross <sean@xobs.io>
* alloc: run `cargo fmt`
Signed-off-by: Sean Cross <sean@xobs.io>
* Added cross platform tests
* Added all cross platforms
* Fixed an issue where `usize` and `isize` would be encoded wrong on 32 bit platforms
* Made the cross platform tests actually run on the platforms
* Disabled cross targets that don't build right now
* Fixed a failing test on 32 bit platforms, re-enabled all platforms for testing
* Disabled failing platforms