* Rename hobject helper functions for property entry access.
* Add helpers for looking up _Formals and _Varmap without inheritance.
* Add duk_xget_owndataprop() + variants for internal property lookups
without inheritance or side effects.
* Date built-in fix for .setTime(), .setYear(), etc on a frozen Date
instance. These should be allowed because they operate on an internal
slot which is not under normal property access control. Previously
the operations were incorrectly rejected with a TypeError.
* Changes to internal property definition and lookup here and there.
Mostly the changes should be no-op because e.g. inheritance only
matters if the internal property might be missing (which is not
usually the case).
* Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may
cause some sign warnings in calling code.
* Reject attempt to unpack an array-like value whose length is 2G or over;
previously was not checked explicitly, and the length was cast to duk_idx_t
with a sign change and the unpack would then later fail. Now it fails with
a clean RangeError.
* Add wrap check for Node.js Buffer.concat().
* API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
Both duk_hthread and duk_context typedefs resolve to struct duk_hthread
internally. In external API duk_context resolves to struct duk_hthread
which is intentionally left undefined as the struct itself is not
dereferenced. Change internal code to use duk_hthread exclusively which
removes unnecessary and awkward thr <-> ctx casts from internals.
The basic guidelines are:
* Public API uses duk_context in prototype declarations. The intent is to
hide the internal type, and there's already a wide dependency on the
type name.
* All internal code, both declarations and definitions, use duk_hthread
exclusively. This is done even for API functions, i.e. an API function
declared as "void duk_foo(duk_context *ctx);" is then defined as
"void duk_foo(duk_hthread *thr);".
* Strings with 0xFF byte prefix are considered special symbols: they have
typeof "symbol" but still mostly behave as strings (e.g. allow ToString)
so that existing code dealing with internal keys, especially inside
Duktape, can work with fewer changes.
* Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for('foo')
creates the byte representatio: 0x80 "foo"
* Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed
by the Symbol description, and an internal string component ensuring
uniqueness is separated by a 0xFF byte (which can never appear anywhere in
an extended UTF-8 string). The unique suffix is up to Duktape internals,
currently two 32-bit counters are used. For example:
0x81 "mySymbol" 0xFF "0-17".
* Well-known symbols use the 0x81 prefix but lack a unique suffix, so their
format is 0x81 <description> 0xFF.
* ES6 distinguishes between an undefined symbol description and an empty
string symbol description. This distinction is not currently visible via
Ecmascript bindings but may be visible in the future. Append an extra
0xFF to the unique suffix when the description is undefined, i.e.
0x81 0xFF <unique suffix> 0xFF.
* RegExp.prototype is no longer a RegExp instance, so e.g.
Object.prototype.toString.call(RegExp.prototype) now returns
[object Object].
* .source, .global, .ignoreCase, .multiline (and new ES6 properties
.sticky, .unicode, .flags) are inherited getters instead of actual
properties in the RegExp instance.
* RegExp constructor uses .flags rather than reading .global,
.ignoreCase, and .multiline when the argument is a RegExp instance.
These can be used whenever we're 100% certain that the value stack index
exists and the type matches expected type. When these are true, a
duk_hstring, duk_hbuffer, or duk_hobject pointer fetch can be inlined to
small code.
Saves a few hundred bytes of footprint:
* duk_dup_0() = duk_dup(ctx, 0), duk_dup_1() = duk_dup(ctx, 1), etc.
* duk_dup_m2() = duk_dup(ctx, -2), etc.
* duk_dup_m1() is not added, because duk_dup_top() is the same thing
These don't play well with the API currently: the Duktape specific error
codes don't have Ecmascript Error class counterparts so they don't get
represented usefully as Ecmascript objects (e.g. AllocError is a plain
Error from Ecmascript point of view).
There's no real need for Duktape specific error code. Some of the codes
had become unused; a couple were used but Ecmascript standard types can
be used instead.
Also minor error message tweaking.
* Add duk_require_function() and duk_require_callable() API calls
* Make duk_is_callable() a macro which calls duk_is_function()
* Include index for "invalid index" errors
* Add expected type and offending type/value for duk_require_xxx() errors
* Improve Array.prototype.forEach() and other iterator errors
Lots of minor string format cleanups (casts mainly).
Add a special check to detect NULL pointers with %s/%p formats in debug
logging to avoid calling the platform sprintf() with a NULL value. This
is especially important for %s + NULL, which is not portable and may crash
on some platforms. Debug logging will now format these specially as "NULL"
and avoid calling the platform for formatting, so debug log call sites don't
need to be careful with NULL pointers any more.
Sami Vaarala