These were previously reporting leaks due to various allocations not
getting cleaned up during the stack unwind, but at the current state of
the transition toward IntrusivePtr usage, theses tests no longer leak.
E.g. ones that throw interpreter exceptions, as those are currently
known to potentially cause leaks. Fixing the underlying leaks involves
the larger task of more IntrusivePtr usage.
Reference cycles may also cause leaks.
Scripting errors/mistakes now consistently generate a runtime error
which have the behavior of unwinding the call stack all the way out of
the current event handler.
Before, such errors were not treated consistently and either aborted
the process entirely or emitted a message while continuing to execute
subsequent statements without well-defined behavior (possibly causing
a cascade of errors).
The previous behavior also would only unwind out of the current
function (if within a function body), not out the current event
handler, which is especially problematic for functions that return
a value: the caller is essentially left a mess with no way to deal
with it.
This also changes the behavior of the startup/initialization process
to abort if there's errors during bro_init() rather than continue one
to the main run loop. The `allow_init_errors` option may change this
new, default behavior.
I was hoping to report this right at startup through a static check
but turns out we don't have the right machinery in place for that.
That would need to be done after the AST has been finalized, but our
AST traversal code can't iterate over types. So instead I've changed
this so that it's still being reported at runtime but at least
doesn't crash Bro anymore.
Closes BIT-1597.
