Add support for number ranges - #602
Conversation
Improve test
cargo fmt
|
Thanks @Ztry8 for prototyping this feature! |
|
Also, this addition will need to be documented in the grammar |
|
Thank you! I've already started working about this |
Add test for deserialising inside an untagged context
|
@juntyr, is everything fine now? What should I put into |
juntyr
left a comment
There was a problem hiding this comment.
Thank you for the changes, I left some further comments
|
Thank you! l've already started to working on this |
Co-authored-by: Juniper Tyree <50025784+juntyr@users.noreply.github.com>
Co-authored-by: Juniper Tyree <50025784+juntyr@users.noreply.github.com>
Co-authored-by: Juniper Tyree <50025784+juntyr@users.noreply.github.com>
Co-authored-by: Juniper Tyree <50025784+juntyr@users.noreply.github.com>
juntyr
left a comment
There was a problem hiding this comment.
We're on the home stretch now - there's also a conversation from earlier on about moving the number deserialiser that I unresolved - please have a look at that as well
|
Thanks! l've already started to working on this |
|
@juntyr, many thanks! I've improved the tests, added more clarification in the comments, and moved the number deserializer |
|
@Ztry8 Thanks, we're almost almost there - thank you so much for making all these final adjustments |
…dless of variant order
…h serializer and deserializer pub(crate)
|
@juntyr, thank you for your help and cooperation! What's left to do? |
|
@juntyr, what do you think now? |
|
@juntyr, what do you think now? |
|
@Ztry8 Thank you so much for your amazing work on this feature! I've now merged the PR. Let's give the PR a few days on main to try it out, and then I'll release a new version with the feature (feel free to ping me if I forget). |
|
@juntyr, thank you for your help and cooperation! |
|
@juntyr, has enough time passed for a new release? |
Thanks for the ping, I've now released v0.12.2 |
ron has ~450 correctness tests but none that guard the asymptotic cost of parsing. That gap let ron-rs#534 regress escaped_byte_buf from O(n) to O(n^2) across v0.9.0..=v0.12.2 — four releases — with every test green, and a second O(n^2) entered next_bytes_is_float in v0.12.2 (ron-rs#602). tests/complexity_scaling.rs asserts that parse time grows at most linearly: it doubles the input and checks the time ratio (~2 linear vs ~4 quadratic; threshold 3.0), using min-of-N + median to stay robust to timing noise. The tests are #[ignore]d and run in a dedicated release CI job, so they never slow down or flake the normal test job. Two forms guard the regressions fixed in ron-rs#608 (next_bytes_is_float) and ron-rs#610 (escaped_byte_buf); two linear controls keep the harness honest. On the pre-fix tree (d0e99bc) those two forms report ratio ~4.0 and fail the 3.0 threshold; on current master they are ~2.0 and pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This PR implements #601: support for number ranges in RON.
It's just syntactic sugar for structures with fields
start, endorstart, last.It supports both
std::opsandcore::range.Example: