Direct ranges in fields e.g. foo: 0..255
#174
Conversation
Previously they were only supported at the top-level. Incorrect parsing lead these to be treated as a constant of the lower bound. Fixes #172
tests/core/input.cddl
Outdated
| u_64: uint .size 8, | ||
| i_8: int .size 1, | ||
| i_8: -128..127, |
There was a problem hiding this comment.
could we keep the old test along with the new one?
There was a problem hiding this comment.
@gostkin is this good enough coverage now? to get 100% we'd have to have more structs to test .le, .size and n..m for all cases but this should at least improve it, and is more coverage than we previously had before this PR. The code mostly follows the same path so I don't think we'd gain much from that either.
better coverage between top-level vs signed_ints member for various ranges that map to primitives fix for when >isize::MAX limits are used as we used `isize` when `i128` would be better for covering all possibilities (`i64`, `u64`, `f64`) float ranges now panic when they have a decimal part as we were silently ignoring this. Issue created: #178
| @@ -176,11 +176,19 @@ fn parse_type_choices( | |||
| } | |||
| } | |||
|
|
|||
| fn type2_to_number_literal(type2: &Type2) -> isize { | |||
| fn type2_to_number_literal(type2: &Type2) -> i128 { | |||
There was a problem hiding this comment.
This change was to fix an issue noticed when I tried to add u64::MAX as a bound to something and it was rolling over to -1 silently.
| Type2::UintValue { value, .. } => *value as i128, | ||
| Type2::IntValue { value, .. } => *value as i128, | ||
| Type2::FloatValue { value, .. } => { | ||
| // FloatToInt trait still experimental so just directly check |
There was a problem hiding this comment.
I'm guessing this was more of something copy-pasted that went unnoticed during the float PR that someone made. I don't think we'd want silent converting to integers as the preferred behavior there.
Previously they were only supported at the top-level. Incorrect parsing lead these to be treated as a constant of the lower bound.
Fixes #172
better coverage between top-level vs signed_ints member for various
ranges that map to primitives
fix for when >isize::MAX limits are used as we used
isizewheni128would be better for covering all possibilities (
i64,u64,f64)float ranges now panic when they have a decimal part as we were silently
ignoring this. Issue created: #178