[v0.9] Breaking: Treat Some like any newtype variant #413
Conversation
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
Codecov ReportBase: 88.84% // Head: 88.89% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #413 +/- ##
==========================================
+ Coverage 88.84% 88.89% +0.04%
==========================================
Files 55 55
Lines 6437 6464 +27
==========================================
+ Hits 5719 5746 +27
Misses 718 718
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
juntyr
force-pushed
the
unwrap-some-variant-newtype
branch
from
62b7571
to
9b94603
Compare
torkleyy
reviewed
Oct 12, 2022
Good point! I agree that we can keep around this change until we’re ready for 0.9 as it’s quite small and won’t be difficult to rebase then |
juntyr
changed the title
juntyr
changed the title
9 tasks
juntyr
added a commit
to juntyr/ron
that referenced
this pull request
Jul 16, 2023
|
#465 shows that this might actually be a bad idea, as |
juntyr
added a commit
to juntyr/ron
that referenced
this pull request
Jul 17, 2023
juntyr
added a commit
to juntyr/ron
that referenced
this pull request
Aug 16, 2023
juntyr
added a commit
to juntyr/ron
that referenced
this pull request
Aug 17, 2023
juntyr
added a commit
to juntyr/ron
that referenced
this pull request
Aug 17, 2023
|
#465 now includes and supersedes this PR |
juntyr
added a commit
to juntyr/ron
that referenced
this pull request
Aug 19, 2023
juntyr
added a commit
to juntyr/ron
that referenced
this pull request
Aug 19, 2023
juntyr
added a commit
that referenced
this pull request
Aug 20, 2023
* Early prototyping with a typed arbitrary fuzzer (ser only so far) and reading in the corpus * Also fuzz the ser::PrettyConfig (identation-excluded) * Start implementing the arbitrary typed data deserialising fuzzing * Fix None inside stack of implicit Some-s * Detect problematic Some inside deserialize_any with unwrap_variant_newtypes * Fix clippy::useless_conversion lint * Another alternative: allow newtype variant unwrapping in deserialize_any, also for Some + Fix check_struct_type lookahead * Fix PartialOrd impls for Map and Float * Implement arbitrary tuple struct (static field names slice FIXME) fuzzing deserialisation * Fully fix Float comparison with total_ord * Fix clippy lints * Finished arbitrary struct and enum deserialisation fuzzing * Create CI workflow for benchmarking * Fix corpus download and unzip * Give benchmark the comparison branch name * Restrict the benchmark to unique cases (ty, value, ron) * Add test for the Serialize identifier validation * Add tests for further fuzzer-found bugs * Add the extensive CHANGELOG entry * Add the test and changelog entry from the subsumed #413 * Add an early return + more tests for the expensive newtype or tuple check for unwrapping newtype variants
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
How should
Somebe treated in the presence of theunwrap_variant_newtypesextension? With that extension,NewtypeVariant(Some(a: 42, b: 24))already worked, butSome(a: 42, b: 24)did not. In my opinionSomeis just a newtype variant and should parse consistently here. @torkleyy what are your thoughts?CHANGELOG.md