fe4acac5

Author: Tom Sydney Kerckhove <syd@cs-syd.eu>

Committer: Tom Sydney Kerckhove <NorfairKing@users.noreply.github.com>

ical: report a recurrence rule that specifies both UNTIL and COUNT

GREEN for the tests in the previous commit, and the TODO that asked for
this is gone.

A rule specifying both is not conforming, but neither part is ambiguous on
its own, so one is kept and the other reported as a fixable error.  Strict
parsing now refuses such a rule and lenient parsing keeps the COUNT.

Which one is kept is arbitrary, because the spec does not say.  The COUNT
wins, which is what the code already did.

Two things about that code were wrong on the way past.  The type is

    recurrenceRuleUntilCount :: !(Maybe (Either Until Count))

so 'Right' is the count, and the two local bindings were each bound to the
other one's value: 'mUntil' held the COUNT and 'mCount' held the UNTIL.
The comment then said the case "ignore[s] the count" when it was dropping
the UNTIL.  The bindings are named after what they hold now, and the case
enumerates all four combinations rather than falling through, so which
part survives is stated once and checked by the compiler.

The error carries the two values as the text they were written as.  'Until'
and 'Count' would say it better but they are defined in a module that
imports the one where 'PropertyTypeFixableError' lives.

The calendar goes in 'test_resources/calendar/fixable', so it is covered
by the existing pair of scenario tests: strict parsing must refuse it, and
lenient parsing must produce something valid that then parses strictly.

Timeline