Author: Tom Sydney Kerckhove <syd@cs-syd.eu>
Committer: Tom Sydney Kerckhove <NorfairKing@users.noreply.github.com>
ical: refuse an out-of-range rule part value GREEN for the tests in the previous commit. Nine rule part parsers now ask whether the value they just read is in range, and refuse it if not. The range itself is not restated anywhere. Each of these types already declares it in its 'Validity' instance, so 'requireInRange' asks that, which keeps the parser and the invariant from drifting apart: tighten one and the other follows. That is also why the two preceding fixes had to land first. The check inherits whatever 'Validity' says, so a wrong bound becomes a wrong refusal, and before those fixes this would have started refusing COUNT=100 and BYDAY=6MO, both of them ordinary. Refused rather than repaired. The spec says which values are valid but not what to do with one that is not, and dropping the value would empty the rule part. For a part that limits rather than expands, an empty part means no restriction at all, so a forbidden value would widen the recurrence set rather than narrow it -- the same shape as the BYDAY widening fixed earlier. BYMONTH already refused an out-of-range value, so refusing is what the rest of the module did anyway. The check is per rule part and deliberately not on the whole 'RecurrenceRule'. 'Validity RecurrenceRule' also rules on combinations, such as a numeric BYDAY at a frequency that forbids one, and those are fixable errors raised while recurring. Refusing the rule outright for one would undo that. It lives in the parsers rather than in 'parseRecurrenceRule', so that 'recurrenceRulePartP' cannot hand back an invalid value either. It is the primitive, so the invariant belongs there.