GitLab

In the beginning I wasn't sure if I perhaps should make errors return
a value (e.g. undef, or an error object of some kind) or let it throw
an exception. it was the latter then, but there were many remains of
the former ("return error(...") everywhere. That didn't matter a lot,
but over the time had become a nuisance.

And then there were notions of catching and somehow acting on the error
before passing it on that were unneeded in between or simply wrong. All
these have been straightened, and errors are now caught only in places
where things must be restored to a previous state (let, labels, eval_form)
or where a traceback shall be printed.

The new one requires at least one argument; that is a not so welcome
consequence, but the speed gain by nearly a factor of two is worth it

So that was the thing that broke proper error handling in the test runner:
a test fail file triggered a (real) error in the test runner, because
the variable test-file, assumed to contain the name of the file under
test, was undefined. Fixed by making that a global defvar'ed variable,
which then can be accessed -- through the lexical environment, yay! --
by the testcmp function.

(The general mapcar is far more expensive.)