Had a real yak shave this morning with disabling assertions in release
builds in our C/C++ code. It turns out that our unit tests use
`assert()` which we intended to use from `test_assert.h`, but in some
cases `cassert` or `assert.h` had been #included after `test_assert.h`,
overriding our special `assert()` macro. The chain of includes is
somewhat hard to puzzle out -- it's often buried several levels deep.
This meant that a release build would drop all test assertions, meaning
most tests passed, unsurprisingly, as there were no assertions left to
fail ... but some tests failed with crashes because we optimized out
important lines such as `assert(some_important_function())`.
I was quite unhappy with this fragility, so I have opted to rename
`assert()` to `test_assert()` in all of our home-grown C/C++ unit tests,
which further highlighted unit tests which were only using the C/C++
`assert()` and not ours, so then had to figure out which unit test
executables needed to have `test_assert` added, and then ... then ...
discovered a bug in `test_color.h`, where we were #including
`io.h`/`unistd.h` inside a `namespace console_color {}` block, which
just happened to be the first ref to those beautiful headers, and thus
(because `#pragma once`) meant that useful little functions like
`access()` were no longer accessible to us in the global namespace.
I have also audited Every Single Call to `assert()` to verify that we do
not do Important Work inside the parentheses, and, apart from those
offending unit tests, now resolved with `test_assert()`, it looks like
all is good.
I would like to present one very well-shaved yak in this commit.
Fixes: #12619
This change adds the mocha-teamcity-reporter which outputs the running
tests in a special format that TeamCity can interpret. This allows TC
to show which tests run as well as the number of tests run.
Many of the types had very generic names (e.g. `Configuration`), and as
the types are now exported from `@keymanapp/common-types`, this was
unhelpful.
For units with many references, I used TypeScript's import-equals to
reduce the change impact. For units with only a few references, I added
the `LexicalModelTypes.` prefix to the references in source.
(Best reference I could find for import-equals: b722fa4e49)
Fixes: #12516
The package subfile description field is never really used in the
end-user apps. As it is meaningless metadata, we'll make it fully
optional, and start to remove all references in the designers and
compilers.
TODO: For packages targeting Keyman 18.0+, we should consider removing
the description field altogether from the subfiles.
- pattern parser update
- correct spelling of Error_InvalidVariableIdentifier
- track and report bad marker strings (look like markers but not)
- fix: may have missed markers mentioned in variables
- tests for above
Fixes: 12467
This improves #12440. The previous change was a bit fragile if we updated
commander versions. This change now implements a better solution that
doesn't rely on dependencies and their locations for detecting if we need
to run the `configure` action for hextobin.
This change fixes a dependency problem when building Core. Previously
this failed on a clean source tree because hextobin was missing
dependencies but didn't run its `configure` action if the top-level
`node_modules` folder did already exist.
Validation of vars was not properly checking for forward references to
string variables. This, coupled with a null vs undefined bug in
subsequent use, meant that forward reference variables were ending up
with a literal string value of 'undefined'.
This also fixes the test for visual-keyboard-compiler, where the fixture
was actually buggy and was the trigger for investigating this problem.
Fixes: #12403
Relates-to: #12395