Separate call handling into three functions: unprotected call wrapper,
protected call wrapper, and a shared inner call handler. Having setjmp
only in a smaller wrapper reduces problems with compiler, including:
* Spurious volatile warnings
* Performance impact on compilers where optimizations must be disabled for
any function involving a setjmp
Also make every DUK_SETJMP() call site compatible with a later refactoring
to supporting C++ exceptions by handling the success case in the then-block
and the error in the else-block. This allows a try-catch structure to
trivially replace the setjmp construct.
Split call error handling to separate function which makes it easier to
share for C++ exception handling which may need a catch (xxx) for Duktape
errors and a separate catch (...) for other errors accidentally thrown by
user code.
Other minor cleanups in call handling.
The bytecode was missing DUK_REOP_SAVE for indices 0 and 1, i.e. the
zeroth capture, which caused the RegExp.prototype to match an empty
input but without providing the zeroth capture which is assumed in
other parts of Duktape internals. This caused the GH-492 assert failure
and, with asserts disabled, a segfault.
DUK_USE_DEBUGGER_THROW_NOTIFY default is "true". If the option "requires"
DUK_USE_DEBUGGER_SUPPORT (which defaults to "false") the option configuraiton
would be inconsistent and rejected by default.
Remove the "required" metadata for debugger options: the options don't really
require debugger support. Instead, if debugger support is disabled, the
debugger config options are just ignored without causing a build error.
* Generate all duk_config.h headers using a single modular approach.
* Remove previous autodetect-header command and replace it with the
modular header.
Accept a plain buffer argument in typedarray constructor. Behavior will be
the same as for a Duktape.Buffer, i.e. the argument is treated as an array-like
initializer.
Zero buffer data explicitly for ArrayBuffer and typedarrays created, even when
DUK_USE_ZERO_BUFFER_DATA option is not set. Buffer zeroing is explicitly
required by Khronos/ES6.
Node.js Buffer does *not* zero buffer data by default, so this behavior
is not changed here: Node.js Buffers will be zeroed when
DUK_USE_ZERO_BUFFER_DATA is set, and left as garbage when not set.