Isolate all char-offset-to-byte-offset and character access calls
behind helpers to help prepare for a switch to WTF-8 representation.
This change should have no visible effect yet.
* Rework duk_heaphdr and subclass assertions into functions to
reduce debug build size.
* Add explicit object validity assert passes to mark-and-sweep.
This allows detection of invalid internal structures especially
when used with GC torture.
* Rename assertion macros for consistency, e.g. from
DUK_ASSERT_HSTRING_VALID to DUK_HSTRING_ASSERT_VALID.
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);".
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.
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.
Improve readability by doing the following renames:
* duk_hcompiledfunction -> duk_hcompfunc
* duk_hnativefunction -> duk_hnatfunc
* duk_hbufferobject -> duk_hbufobj
Corresponding renames for all caps defines.
This makes it easier to pass C pointers to state structs etc without having
to use duk_push_pointer() and the value stack.
Change internal duk_safe_call() sites to use udata where appropriate.
Eval code doesn't need an automatic prototype object, so avoid creating one.
This also avoids making the internal function which eval compiles to part of
a reference loop so that eval functions collect immediately.
Previously `__FILE__` was used, but this leads to some confusing error
file/line pairs: https://github.com/svaarala/duktape/issues/516.
Change the behavior so that:
* Eval code which doesn't have an explicit filename uses "eval" for the
eval temporary function .fileName. As a result, errors thrown from
eval code will be identified e.g. as "eval:17" (17th line in the eval
input). The native function or __FILE__ is not apparent.
* Compiled code which doesn't have an explicit filename uses "input" for
the function .fileName.
duk_push_string_file_raw() can be made to push undefined for a file read
error; after that, compile will throw a "no sourcecode" error. This is
not an ideal error messages but good enough for now.
Use duk_compile_lstring() instead of duk_compile_userbuffer() to remain
consistant with the rest of the API. The variant which doesn't automagic
the filename argument is duk_compile_lstring_filename(). Similarly for
eval.
String variants referred to both 'src' and 'DUK_STRLEN(src)' which would
cause double evaluation of macro arguments. For instance, if 'src' was
obtained from a call to a function, the function would be called twice.
Fixed by taking the strlen() inside duk_api_compile.c. Not the most elegant
thing as it would be nicer to push this to the caller's footprint, but there
is no reasonably way of doing that with C expression syntax.
Compile from user buffer without interning. The current API is probably
not final because it defaults result fileName from __FILE__ which may not
be appropriate in general (cf. duk_compile() where caller provides the
fileName explicitly).