-
-
Notifications
You must be signed in to change notification settings - Fork 31
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
Fixed bugs with different enum formats, closes #3 #4
Merged
Merged
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
2560e74
Got adjacently tagged enums working
awestlake87 d5f83c3
Got internally tagged enums working with float numbers only
awestlake87 373b58e
Got internally tagged enums working with ints
awestlake87 19735a9
Got it working with untagged enums too
awestlake87 c41d8e0
Combined is_object() and is_string() in assert_json
awestlake87 a5745b8
undefined values are the only problematic ones in assert_json
awestlake87 c326b7f
Simplified the assert_json conditions
awestlake87 d2c4dbd
Added test cases for integer sequences
awestlake87 3636fb2
Added tests for maps and sequences in enums
awestlake87 e6fe98a
Added sequence and map tests to the test_enum! variant
awestlake87 54b9c7c
Changed back to verification with assert_json
awestlake87 4ae6133
Removed redundant tests
awestlake87 c827527
Remove unneeded dependency
RReverser ab19368
cargo fmt
RReverser df09c8b
Exclude iterables from deserialize_any
RReverser 793f42b
Changed internally tagged enums to only test deserialization from Obj…
awestlake87 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Are these conversions covered by new tests somehow?
Generally I'd be wary of extending
deserialize_any
with casts, and prefer that users specify explicit destination types, unless there is a compelling reason to use dynamic heuristics.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.
Yeah, this gets into the weeds of how serde handles internally tagged enums. Basically what happens is serde buffers the variant into an intermediate Content structure. When it encounters a JS number, it stores it as an f64, which ends up breaking deserialization for integer types when it converts this intermediate structure to the one we actually want to deserialize.
The same is true for sequences and objects, which is why I added checks for the Array and Object types.
In the test cases, I test one with type B as a float, and one with type B as an int. I believe this also covers the Object type, since the struct has to be deserialized as a map first, but I'm not certain. We will probably want to add a test for a sequence type (I guess I only verified that this worked in my project).
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.
Ughh this is unfortunate, but makes sense...
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.
Coming back to this - can you please make sure to cover these branches by tests (outside of internally tagged enums)? I want to make sure that assumptions about representation of new types are clearly defined for future regressions. Thanks!
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 running into a few problems with this. I added two variants to the
test_enum!
macro, making it look like this:This should at least touch on some sequences and maps in non-internally tagged enums. However, I ran into the following error with this setup:
Not sure why the
HashMap
is being skipped over here, but it appears to be another bug (unless I'm missing something). Note that serializing structs works perfectly fine, but notHashMap
, which I believe works fine forserde_json
.Another thing I saw was due to the way
assert_json
checks the serialization results. When I add another test case totest_enum!
for sequences of floats:I get this error due to floating points not being serialized exactly the same by
serde_json
andjs_sys::JSON
:This indicates that we need a more robust method of asserting that values are serialized and deserialized properly in order to provide more comprehensive coverage.
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.
So after looking into df09c8b, I'm a little unclear as to why iterables get excluded there. I agree that we should have a serialization switch for
Map
vsObject
, but if we don't at the moment, then isn't it ok just to allow deserialization from iterables?It might not be the best policy, but it wouldn't be unreasonable until a
serde(with = ...)
switch is implemented or serde-rs/serde#1183 gets resolved in my opinion. At the very least, it might save someone a gotcha if they just naively replace theirserde_json
code withserde_wasm_bindgen
.I suspended that changeset and ran this test and it seemed to do fine:
I'll upload the deserialization test and the README change so you can look at it, though.
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.
My hesitation with allowing such conversions that is that someone will most likely start relying on that behaviour, and removing it afterwards in a favour of "the right way" will be a breaking change.
I'd rather be as restrictive as possible and throw an explicit error, until someone comes up with a use-case where this is important, rather than silently allow some conversions through and deal with the challenge of deprecating them later.
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.
Another thing to consider is that excluding Iterables also affects untagged enums since they go through
deserialize_any
as well. So this test fails with df09c8b as well: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.
Oof and basically maps at any level in the variant. This also fails:
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 uploaded 793f42b with the changes to tests and an update to the README. I think this should cover what we talked about before I brought up df09c8b, but let me know if you think we should add some more info or tests.