Open dkuehr opened 1 year ago
Rust-types generator uses the information provided by bin_prot which is the over-the-wire representation of the encoded value. This representation doesn't necessarily match the OCaml type definition.
For example one particular case is UInt64, where the over-the-wire representation is Int64: https://github.com/name-placeholder/mina/blob/9fe2662251a98d5329a03a469ce2abbe6da34541/src/lib/unsigned_extended/unsigned_extended.ml#L120-L122
UInt64
Int64
Rust-types generator ends producing a type like the following:
/// **OCaml name**: `Unsigned_extended.UInt64.Stable.V1` /// /// Gid: `125` /// Location: [src/int64.ml:6:6](https://github.com/name-placeholder/mina/blob/da4c511501876adff40f3e1281392fedd121d607/src/int64.ml#L6) #[derive(Clone, Debug, PartialEq, Serialize, Deserialize, BinProtRead, BinProtWrite)] pub struct UnsignedExtendedUInt64StableV1(pub crate::number::Int64);
Another instance of this issue is the compressed/uncompressed public keys, where the over-the-wire representation is always the compressed form: https://github.com/MinaProtocol/mina/blob/develop/src/lib/non_zero_curve_point/non_zero_curve_point.ml#L191-L193
We should keep track of every case like this (please include them in this issue), and provide some fix/workaround for the affected types.
@dkuehr The first part should be fixed with #43
Rust-types generator uses the information provided by bin_prot which is the over-the-wire representation of the encoded value. This representation doesn't necessarily match the OCaml type definition.
For example one particular case is
UInt64
, where the over-the-wire representation isInt64
: https://github.com/name-placeholder/mina/blob/9fe2662251a98d5329a03a469ce2abbe6da34541/src/lib/unsigned_extended/unsigned_extended.ml#L120-L122Rust-types generator ends producing a type like the following:
Another instance of this issue is the compressed/uncompressed public keys, where the over-the-wire representation is always the compressed form: https://github.com/MinaProtocol/mina/blob/develop/src/lib/non_zero_curve_point/non_zero_curve_point.ml#L191-L193
We should keep track of every case like this (please include them in this issue), and provide some fix/workaround for the affected types.