-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correctly encode Duration and optional fields #72
Conversation
@@ -316,7 +318,7 @@ macro_rules! request { | |||
( | |||
$destination_request:ident from $source_request:ident | |||
$( extracts $( $field_name:ident : $field_type:tt ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident $( { $transformation:expr } )? $( $optional:literal )? ),+ $(,)? )? |
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.
I'm adding "optional"
to flag things as optional. But the match will match any literal, which is suboptimal. I'd prefer to match just optional
, but I don't see any way of doing that. If I use $( optional )
, then that would match just optional
, but then I don't have a way to expand that back out it the transcription below, because it isn't assigned to a metavariable.
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 we check at runtime that the token is optional
? It would be nice to have some kind of check.
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.
Or I guess you could have two alternatives, one with optional
and one without, and give the metavariables different names? I've not done many of these macros so I'm just guessing.
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.
@Hywan as original author of the request!
macro, do you have any suggestions for this?
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.
What about simply optional
?
$( $( and )? groups $( $grouped_field_name:ident $( { $transformation:expr } )? $( optional )? ),+ $(,)? )?
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.
Yup, I tried doing $( optional )?
, but I couldn't figure out how to handle the expansion so that it does something different depending on whether it's specified or not, because it isn't bound to a metavariable.
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.
Let's keep things as they are now, I may update this later.
Just for fun, I decided to see what would happen if I ran
which suggests that doing Rust tests will not be as trivial as I thought it would be. |
I figured out a way to test the conversions, and it's only moderately ugly! |
src/requests.rs
Outdated
|
||
use super::{KeysClaimRequest, KeysQueryRequest, KeysUploadRequest}; | ||
|
||
#[wasm_bindgen(js_name = "_test_make_keys_claim_request")] |
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.
I deliberately used ugly names here since they're only intended for testing
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.
I found these macros very difficult to understand, but as far as I did understand, this looks sensible, and the tests appear to demonstrate it works :-)
@@ -316,7 +318,7 @@ macro_rules! request { | |||
( | |||
$destination_request:ident from $source_request:ident | |||
$( extracts $( $field_name:ident : $field_type:tt ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident $( { $transformation:expr } )? $( $optional:literal )? ),+ $(,)? )? |
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 we check at runtime that the token is optional
? It would be nice to have some kind of check.
@@ -316,7 +318,7 @@ macro_rules! request { | |||
( | |||
$destination_request:ident from $source_request:ident | |||
$( extracts $( $field_name:ident : $field_type:tt ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident $( { $transformation:expr } )? $( $optional:literal )? ),+ $(,)? )? |
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.
Or I guess you could have two alternatives, one with optional
and one without, and give the metavariables different names? I've not done many of these macros so I'm just guessing.
@@ -316,7 +318,7 @@ macro_rules! request { | |||
( | |||
$destination_request:ident from $source_request:ident | |||
$( extracts $( $field_name:ident : $field_type:tt ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident $( { $transformation:expr } )? $( $optional:literal )? ),+ $(,)? )? |
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.
What about simply optional
?
$( $( and )? groups $( $grouped_field_name:ident $( { $transformation:expr } )? $( optional )? ),+ $(,)? )?
@@ -316,7 +318,7 @@ macro_rules! request { | |||
( | |||
$destination_request:ident from $source_request:ident | |||
$( extracts $( $field_name:ident : $field_type:tt ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident ),+ $(,)? )? | |||
$( $( and )? groups $( $grouped_field_name:ident $( { $transformation:expr } )? $( $optional:literal )? ),+ $(,)? )? |
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.
Let's keep things as they are now, I may update this later.
PR #72 landed in 4.0.1, not 4.0.0.
PR #72 landed in 4.0.1, not 4.0.0. Also: add UNRELEASED section
fixes #56, #57, and (hopefully) element-hq/element-web#26566
I ported matrix-org/matrix-rust-sdk#817 over, and added another parameter to mark fields as optional if they're
Option<...>
, to avoid stickingnull
in responses. It's kind of ugly, so suggestions welcome.I'm not sure what's the best way to test this. All the existing tests are in JS, and as far as I can tell, from JS the only way to get these structs is to get them from OlmMachine, which means coercing OlmMachine to spit out the right requests. Otherwise, I could write a test in Rust that creates the ruma request struct and test that it transforms into the wasm request struct correctly, but that would mean adding another testing system. That's not too bad since Rust has its own testing built-in, but I don't know if we care about keeping the tests in JS.