refactor framing_sv2 example
#1468
Conversation
|
|
||
| // Example message type (e.g., SetupConnection) | ||
| const MSG_TYPE: u8 = 1; | ||
| // Example extension type (e.g., a standard Sv2 message) | ||
| const EXT_TYPE: u16 = 0x0001; | ||
|
|
||
| #[derive(Serialize, Debug)] | ||
| #[derive(Serialize, Deserialize, Debug)] |
There was a problem hiding this comment.
this line is causing the following error:
error[E0308]: mismatched types
--> v2/framing-sv2/examples/sv2_frame.rs:29:21
|
29 | #[derive(Serialize, Deserialize, Debug)]
| ^^^^^^^^^^^
| |
| expected `&[u8]`, found `&Vec<FieldMarker>`
| arguments to this method are incorrect
|
= note: expected reference `&[u8]`
found reference `&Vec<FieldMarker>`
note: method defined here
--> /Users/plebhash/develop/stratum/protocols/v2/binary-sv2/no-serde-sv2/codec/src/codec/mod.rs:85:8
|
85 | fn size_hint_(&self, data: &[u8], offset: usize) -> Result<usize, Error>;
| ^^^^^^^^^^
= note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0308`.
error: could not compile `framing_sv2` (example "sv2_frame") due to previous error
this error is the main reason why this PR is still draft
I wonder if this is related to #1455, and if it requires anything from #1455 or #1462?
cc @Shourya742
There was a problem hiding this comment.
I rebased to bring in the changes from #1455 and the error did not go away.
There was a problem hiding this comment.
Can you change variable name from data, to anything else. something like
#[derive(Serialize, Deserialize, Debug, Clone)]
pub struct CustomMessage {
pub a: u32,
}There was a problem hiding this comment.
that did the trick!
but now I'm quite puzzled! is data somehow causing some kind of namespace conflict with binary_sv2?
There was a problem hiding this comment.
You managed to break the binary_sv2 implementation.
The error was caused by the following code:
fn get_structure(data: &[u8]) -> Result<Vec<FieldMarker>, Error> {
let mut fields = Vec::new();
let mut offset = 0;
let data: Vec<FieldMarker> = u32::get_structure(&data[offset..])?;
offset += a.size_hint_(&data, offset)?;
let a = a.try_into()?;
fields.push(a);
Ok(fields)
}When the procedural macro deserialization expands, it generates an implementation for our CustomMessage struct, which includes a data field. Because we named the field data, this line:
let data: Vec<FieldMarker> = u32::get_structure(&data[offset..])?;shadows the original data slice with a Vec<FieldMarker>. This causes an issue because get_structure expects a slice of u8, not a Vec<FieldMarker>. We need to have a unique identifier rather than this data. As I might have mentioned in KT session of our, the proc_macro implementation can be improved, and this was one of the reasons to propose that proposal.
There was a problem hiding this comment.
that sounds like a bug in the proc_macro of derive_codec_sv2, right?
should we take note of this in #1462 ?
There was a problem hiding this comment.
Yes, I will add all the observations made so far to the issue and update it.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1468 +/- ##
=======================================
Coverage 18.06% 18.06%
=======================================
Files 127 127
Lines 9555 9555
=======================================
Hits 1726 1726
Misses 7829 7829
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
plebhash
force-pushed
the
refactor-framing-sv2-example
branch
4 times, most recently
from
393cc68 to
7d24f3f
Compare
we need to assert that the deserialized message has the same content from the original
plebhash
force-pushed
the
refactor-framing-sv2-example
branch
from
7d24f3f to
52e824f
Compare
plebhash
changed the title
framing_sv2 exampleframing_sv2 example
nice catch, we didn't but I just added a commit that runs it from |
Should we also add other examples that we recently included during our documentation efforts, since not all of them have been added to CI? |
|
|
||
| // Example message type (e.g., SetupConnection) | ||
| const MSG_TYPE: u8 = 1; | ||
| // Example extension type (e.g., a standard Sv2 message) | ||
| const EXT_TYPE: u16 = 0x0001; | ||
|
|
||
| #[derive(Serialize, Debug)] | ||
| #[derive(Serialize, Deserialize, Debug, Clone)] | ||
| pub struct CustomMessage { |
There was a problem hiding this comment.
thinking out loud here, wouldn't it be more beneficial to actually have an SV2 message here? for the MSG_TYPE, SETUP_CONNECTION is used, maybe here as well?
close #1467