You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 12, 2023. It is now read-only.
There is certain macro syntax which should be parsed or not parsed depending on which XRBK traits one derives.
For example, a let element would be parsed if any of these traits are derived:
X11Size
ConstantX11Size
Readable
...but without the source used to write it:
let name_len:u16
Only if Writable is derived would it have a source:
let name_len:u16 = name => name.len()asu16
Also, if the macro syntax is parsed conditionally depending on which traits are derived, then all structs should be parsed custom, not just those with at least one XRBK trait. This is so that requests, replies, events, and errors may still be implemented without deriving their XRBK traits (you really should, but for consistency, and therefore each of learning, it wouldn't be required). It also means better errors can be given.
The text was updated successfully, but these errors were encountered:
There is certain macro syntax which should be parsed or not parsed depending on which XRBK traits one derives.
For example, a let element would be parsed if any of these traits are derived:
X11Size
ConstantX11Size
Readable
...but without the source used to write it:
Only if
Writable
is derived would it have a source:Also, if the macro syntax is parsed conditionally depending on which traits are derived, then all structs should be parsed custom, not just those with at least one XRBK trait. This is so that requests, replies, events, and errors may still be implemented without deriving their XRBK traits (you really should, but for consistency, and therefore each of learning, it wouldn't be required). It also means better errors can be given.
The text was updated successfully, but these errors were encountered: