With significant-digits presentation mode, NAN would be formatted as
'NAN' followed by zeroes, which looks silly, and +INF would cause an
execution timeout as Moodle tries to divide +∞ by 10 until it becomes
less than 1, which can happen in a divide-by-zero situation.
Note that the user can't answer NAN or INF to any question, but at this
at least now looks consistent and also doesn't break Moodle in the case
of +INF.
Issue 1: While essay question's uploading progress, we need to disable submit
buttons to prevent submit form event.
Issue 2: Enable buttons after pressing cancel button on the popup
confirming overwrite file existed.
version = 2021051700 release version
requires= 2021051100 current rc1 (week7roll1) version
Note that, because we are under parallel development period,
this is being done in the branch that is going to be released
(MOODLE_311_STABLE already existing) for Moodle 3.11.0 and
not in master, that is the one getting the bump under normal
(non-parallel) periods.
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
I've gone over a few of the mofified files (those
which were showing warnings and errors to CiBoT. Some of them
have been fixed completely, while others only have fixed
for the lines belonging to this issue (lib/tests/moodlelib_test.php)
for example.
The methods assertContains() and assertNotContains() now perform
strict (type and value) comparison, pretty much like assertSame()
does.
A couple of new assertContainsEquals() and assertNotContainsEquals()
methods have been created to provide old (non-strict) behavior, pretty
much like assertEquals() do.
Apart from replacing the calls needing a relaxed comparison to those
new methods, there are also a couple of alternative, about how to
fix this, depending of every case:
- If the test is making any array_values() conversion, then it's better
to remove that conversion and use assertArrayHasKey(), that is not
strict.
- Sometimes if may be also possible to, simply, cast the expectation
to the exact type coming in the array. I've not applied this technique
to any of the cases in core.
Link: https://github.com/sebastianbergmann/phpunit/issues/3426
