Open udoprog opened 7 months ago
Overall the errors are a bit of a red herring, but first it seems like CString just isn't supported.
Yeah, I haven't added back all the features bitcode 0.5 supported CString being one of them.
Second it seems like you might be imposing a Send + Sync bound which might not be necessary (or at least I don't see why it should be!).
This is only imposed on the Encoder, not the actual type. I think the error message is misleading.
If you don't want to add CString support I can carve out a separate category for bitcode derive in my tests.
I eventually want to add missing types, but this seems like the best option for now.
Thanks.
I do have one minor minorly related questions if you don't mind.
I can't find serde support for serializing with existing buffers, which makes the serde-based benchmarks much slower than they should be since they'd have to allocate.
Has this been removed?
I can't find serde support for serializing with existing buffers, which makes the serde-based benchmarks much slower than they should be since they'd have to allocate.
Has this been removed?
Yes for a rather complex reason. Bitcode 0.6 encoding converts any type to a Vec<primitive>
per field and copies them to the output Vec<u8>
. There is no metadata between the Vec<primitive>
s. bitcode::serialize
has to keep track of which order it learned about the fields since bitcode::deserialize
will learn about the fields in the same order (in depth explanation). If bitcode kept Vec<primitive>
s from previous calls to serialize
, it wouldn't record the order it learned about them.
feature = derive
can use reuse allocations since it knows all the fields up front.
All right, so I'll put the serde-based tests in a separate category too :)
I'm guessing then this also extends to fields marked with #[bitcode(with_serde)]
, as in additional internal allocations and copying would happen?
This is blocked on determining the serialized representation.
&'de CStr
can be deserialized, but hard to deserialize quickly.
I've updated bitcode, and if you try and build the musli test suite right now like this:
You get the following errors
``` error[E0277]: the trait bound `CString: Encode` is not satisfied in `AllocatedEncoder` --> crates\tests\src\models.rs:144:47 | 144 | #[cfg_attr(feature = "bitcode-derive", derive(bitcode::Encode, bitcode::Decode))] | ^^^^^^^^^^^^^^^ within `AllocatedEncoder`, the trait `Encode` is not implemented for `CString`, which is required by `Overall the errors are a bit of a red herring, but first it seems like CString just isn't supported. Second it seems like you might be imposing a
Send + Sync
bound which might not be necessary (or at least I don't see why it should be!).If you don't want to add
CString
support I can carve out a separate category for bitcode derive in my tests.Thank you!