A fix for one bug in 0.19.0, found within hours of release by someone building a compression library on it.
#Looking up a missing number key in a map
m[999] on a map that has no such key gives you
nil. In 0.19.0 it reported an error about records having
named fields, which is a message about a different kind of value
entirely, and on some builds it could stop the program.
Any map keyed by numbers could hit it: a sparse grid, an index by id, the hash chain inside a compression algorithm, which is where it was found. Maps keyed by strings, arrays and records were unaffected.
If you are on 0.19.0 and using number-keyed maps, upgrade. If you are on 0.18.0 you were never affected, and everything in the 0.19.0 notes still applies.
#Why the tests did not catch it
Worth writing down, because the shape of it is more interesting than the bug.
The check that broke was added to make a genuinely useful error:
indexing a record by position, r[0], tells you
that records have named fields rather than answering nil
and letting that nil flow onward. It asked whether a table's layout was
fixed without first asking whether it had a layout at all. A plain map
does not, so the question read memory that was never set.
Two test suites cover this area and both passed. The record tests used records. The map tests used string keys. The broken check only fired on a missing key that was not a string, so it sat in the gap between them, and neither suite is the one you would call inadequate.
The build that ships has its safety assertions compiled out, which is why the released binary produced a confident, plausible sentence instead of stopping. That is also why the release process runs the test suite twice, once with those assertions on. It is the run that caught this.