-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
requires: rust |
@debris What makes me worry about this is that we will know that the structs serialize and deserialize to RLP, but it's a lot harder to know if it's the correct RLP now. This is important for stuff like protocol structures, and existing structures we've written to old databases. |
@rphmeier I agree, that's why this pr needs careful review. Long term, I believe it's much needed, cause it simplifies our code and reduces amount of boilerplate, the same way |
@@ -76,6 +76,8 @@ extern crate futures; | |||
extern crate itertools; | |||
extern crate rand; | |||
extern crate rlp; | |||
#[macro_use] | |||
extern crate rlp_derive; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you toss this at the beginning of the imports with other macro_use guys?
There are already tests for the light client which directly serialize the messages with manual RLP streaming (for this reason exactly) so I am not worried about PIP breaking. Generally, having a nice suite import/regression tests (parity-import-tests repo) will protect against regressions here as well. |
this pr introduces 4 new derives:
RlpEncodable
- encodes a structure a listRlpDecodable
- decodes structure from a listRlpEncodableWrapper
- encodes structure with a single field, without declaring new listRlpDecodableWrapper
decodes structure with a single fieldPossible improvements:
encoding and decoding enums