github
/
duktape
mirror of https://github.com/svaarala/duktape.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
9988 Commits
65 Branches
60 Tags
84 MiB
Tree: bb6e4911b5
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bb6e4911b5'
${ noResults }
duktape/src-input/duk_api_call.c

527 lines
15 KiB
Raw Normal View History

public and internal stack API code
12 years ago
/*
* Calls.
*
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
* Protected variants should avoid ever throwing an error. Must be careful
* to catch errors related to value stack manipulation and property lookup,
* not just the call itself.
*
* The only exception is when arguments are insane, e.g. nargs/nrets are out
* of bounds; in such cases an error is thrown for two reasons. First, we
* can't always respect the value stack input/output guarantees in such cases
* so the caller would end up with the value stack in an unexpected state.
* Second, an attempt to create an error might itself fail (although this
* could be avoided by pushing a preallocated object/string or a primitive
* value).
public and internal stack API code
12 years ago
*/
#include "duk_internal.h"
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
/*
* Helpers
*/
struct duk__pcall_prop_args {
duk_idx_t obj_idx;
duk_idx_t nargs;
duk_small_uint_t call_flags;
};
typedef struct duk__pcall_prop_args duk__pcall_prop_args;
struct duk__pcall_method_args {
duk_idx_t nargs;
duk_small_uint_t call_flags;
};
typedef struct duk__pcall_method_args duk__pcall_method_args;
struct duk__pcall_args {
duk_idx_t nargs;
duk_small_uint_t call_flags;
};
typedef struct duk__pcall_args duk__pcall_args;
/* Compute and validate idx_func for a certain 'nargs' and 'other'
* parameter count (1 or 2, depending on whether 'this' binding is
* present).
*/
Use duk_hthread, not duk_context in internals 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);".
7 years ago
DUK_LOCAL duk_idx_t duk__call_get_idx_func(duk_hthread *thr, duk_idx_t nargs, duk_idx_t other) {
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk_idx_t idx_func;
/* XXX: byte arithmetic? */
DUK_ASSERT(other >= 0);
Use duk_hthread, not duk_context in internals 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);".
7 years ago
idx_func = duk_get_top(thr) - nargs - other;
Reformat some source files with clang-format
3 years ago
if (DUK_UNLIKELY((idx_func | nargs) < 0)) { /* idx_func < 0 || nargs < 0; OR sign bits */
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ERROR_TYPE_INVALID_ARGS(thr);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return 0;);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT(duk_is_valid_index(thr, idx_func));
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
return idx_func;
}
/* Compute idx_func, assume index will be valid. This is a valid assumption
* for protected calls: nargs < 0 is checked explicitly and duk_safe_call()
* validates the argument count.
*/
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_LOCAL duk_idx_t duk__call_get_idx_func_unvalidated(duk_hthread *thr, duk_idx_t nargs, duk_idx_t other) {
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk_idx_t idx_func;
/* XXX: byte arithmetic? */
DUK_ASSERT(nargs >= 0);
DUK_ASSERT(other >= 0);
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
idx_func = duk_get_top(thr) - nargs - other;
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
DUK_ASSERT(idx_func >= 0);
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT(duk_is_valid_index(thr, idx_func));
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
return idx_func;
}
public and internal stack API code
12 years ago
/* Prepare value stack for a method call through an object property.
* May currently throw an error e.g. when getting the property.
*/
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_LOCAL void duk__call_prop_prep_stack(duk_hthread *thr, duk_idx_t normalized_obj_idx, duk_idx_t nargs) {
Extend internal struct validity assertions in GC * 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.
6 years ago
DUK_CTX_ASSERT_VALID(thr);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
DUK_ASSERT(nargs >= 0);
Add DUK_ASSERT_CTX_VALID() to API entrypoints
10 years ago
Avoid &#39;index&#39; as variable/argument name
9 years ago
DUK_DDD(DUK_DDDPRINT("duk__call_prop_prep_stack, normalized_obj_idx=%ld, nargs=%ld, stacktop=%ld",
Reformat some source files with clang-format
3 years ago
(long) normalized_obj_idx,
(long) nargs,
(long) duk_get_top(thr)));
public and internal stack API code
12 years ago
/* [... key arg1 ... argN] */
/* duplicate key */
Reformat some source files with clang-format
3 years ago
duk_dup(thr, -nargs - 1); /* Note: -nargs alone would fail for nargs == 0, this is OK */
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
(void) duk_get_prop(thr, normalized_obj_idx);
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_DDD(DUK_DDDPRINT("func: %!T", (duk_tval *) duk_get_tval(thr, -1)));
public and internal stack API code
12 years ago
Use verbose error for duk_(p)call_prop too
7 years ago
#if defined(DUK_USE_VERBOSE_ERRORS)
if (DUK_UNLIKELY(!duk_is_callable(thr, -1))) {
duk_tval *tv_base;
duk_tval *tv_key;
Fix GETPROPC error handling corner case When calling via a property and an error happens during call setup, the error is delayed to be thrown later on, so that proper ECMAScript side effect ordering semantics are observed. Previous approach just created the Error object and marked it with a special _Target symbol marker property. The code assumed that the Error was non-callable which would trigger an error path in call handling, and the special _Target symbol marker would only need to be checked in the error path. This overlooked the possibility that a Duktape.errCreate would replace the non-callable Error object with a callable one, e.g. when one simply says: Duktape.errCreate = function () { return Float64Array; }. Modify the approach so that instead of marking the Error object we use a bare wrapper object which points to the error. This ensures that any modifications or replacements to the Error itself won&#39;t affect the call error logic. Also eliminate one unnecessary call argument from the propcall error setup helper.
6 years ago
/* tv_targ is passed on stack top (at index -1). */
Use verbose error for duk_(p)call_prop too
7 years ago
tv_base = DUK_GET_TVAL_POSIDX(thr, normalized_obj_idx);
tv_key = DUK_GET_TVAL_NEGIDX(thr, -nargs - 2);
DUK_ASSERT(tv_base >= thr->valstack_bottom && tv_base < thr->valstack_top);
DUK_ASSERT(tv_key >= thr->valstack_bottom && tv_key < thr->valstack_top);
Fix GETPROPC error handling corner case When calling via a property and an error happens during call setup, the error is delayed to be thrown later on, so that proper ECMAScript side effect ordering semantics are observed. Previous approach just created the Error object and marked it with a special _Target symbol marker property. The code assumed that the Error was non-callable which would trigger an error path in call handling, and the special _Target symbol marker would only need to be checked in the error path. This overlooked the possibility that a Duktape.errCreate would replace the non-callable Error object with a callable one, e.g. when one simply says: Duktape.errCreate = function () { return Float64Array; }. Modify the approach so that instead of marking the Error object we use a bare wrapper object which points to the error. This ensures that any modifications or replacements to the Error itself won&#39;t affect the call error logic. Also eliminate one unnecessary call argument from the propcall error setup helper.
6 years ago
duk_call_setup_propcall_error(thr, tv_base, tv_key);
Use verbose error for duk_(p)call_prop too
7 years ago
}
#endif
public and internal stack API code
12 years ago
/* [... key arg1 ... argN func] */
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_replace(thr, -nargs - 2);
public and internal stack API code
12 years ago
/* [... func arg1 ... argN] */
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_dup(thr, normalized_obj_idx);
duk_insert(thr, -nargs - 1);
public and internal stack API code
12 years ago
/* [... func this arg1 ... argN] */
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL void duk_call(duk_hthread *thr, duk_idx_t nargs) {
API call handling minor improvements
11 years ago
duk_small_uint_t call_flags;
A round of public API typing fixes All public calls have now been fixed to some extent (FIXME notes left behind for issues to resolve).
11 years ago
duk_idx_t idx_func;
public and internal stack API code
12 years ago
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
idx_func = duk__call_get_idx_func(thr, nargs, 1);
DUK_ASSERT(duk_is_valid_index(thr, idx_func));
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_insert_undefined(thr, idx_func + 1);
public and internal stack API code
12 years ago
Reformat some source files with clang-format
3 years ago
call_flags = 0; /* not protected, respect reclimit, not constructor */
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk_handle_call_unprotected(thr, idx_func, call_flags);
public and internal stack API code
12 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL void duk_call_method(duk_hthread *thr, duk_idx_t nargs) {
API call handling minor improvements
11 years ago
duk_small_uint_t call_flags;
A round of public API typing fixes All public calls have now been fixed to some extent (FIXME notes left behind for issues to resolve).
11 years ago
duk_idx_t idx_func;
public and internal stack API code
12 years ago
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
idx_func = duk__call_get_idx_func(thr, nargs, 2);
DUK_ASSERT(duk_is_valid_index(thr, idx_func));
public and internal stack API code
12 years ago
Reformat some source files with clang-format
3 years ago
call_flags = 0; /* not protected, respect reclimit, not constructor */
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk_handle_call_unprotected(thr, idx_func, call_flags);
public and internal stack API code
12 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL void duk_call_prop(duk_hthread *thr, duk_idx_t obj_idx, duk_idx_t nargs) {
public and internal stack API code
12 years ago
/*
* XXX: if duk_handle_call() took values through indices, this could be
* made much more sensible. However, duk_handle_call() needs to fudge
Add duk_hboundfunc internal type
8 years ago
* the 'this' and 'func' values to handle bound functions, which is now
* done "in-place", so this is not a trivial change.
public and internal stack API code
12 years ago
*/
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Add DUK_ASSERT_CTX_VALID() to API entrypoints
10 years ago
Reformat some source files with clang-format
3 years ago
obj_idx = duk_require_normalize_index(thr, obj_idx); /* make absolute */
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
if (DUK_UNLIKELY(nargs < 0)) {
DUK_ERROR_TYPE_INVALID_ARGS(thr);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return;);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
}
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk__call_prop_prep_stack(thr, obj_idx, nargs);
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_call_method(thr, nargs);
public and internal stack API code
12 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_LOCAL duk_ret_t duk__pcall_raw(duk_hthread *thr, void *udata) {
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk__pcall_args *args;
A round of public API typing fixes All public calls have now been fixed to some extent (FIXME notes left behind for issues to resolve).
11 years ago
duk_idx_t idx_func;
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk_int_t ret;
public and internal stack API code
12 years ago
Extend internal struct validity assertions in GC * 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.
6 years ago
DUK_CTX_ASSERT_VALID(thr);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
DUK_ASSERT(udata != NULL);
args = (duk__pcall_args *) udata;
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
idx_func = duk__call_get_idx_func_unvalidated(thr, args->nargs, 1);
DUK_ASSERT(duk_is_valid_index(thr, idx_func));
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_insert_undefined(thr, idx_func + 1);
public and internal stack API code
12 years ago
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
ret = duk_handle_call_unprotected(thr, idx_func, args->call_flags);
DUK_ASSERT(ret == 0);
DUK_UNREF(ret);
return 1;
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_int_t duk_pcall(duk_hthread *thr, duk_idx_t nargs) {
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk__pcall_args args;
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
args.nargs = nargs;
if (DUK_UNLIKELY(nargs < 0)) {
Remove Duktape specific error subtypes These don&#39;t play well with the API currently: the Duktape specific error codes don&#39;t have Ecmascript Error class counterparts so they don&#39;t get represented usefully as Ecmascript objects (e.g. AllocError is a plain Error from Ecmascript point of view). There&#39;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.
9 years ago
DUK_ERROR_TYPE_INVALID_ARGS(thr);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return DUK_EXEC_ERROR;);
public and internal stack API code
12 years ago
}
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
args.call_flags = 0;
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
return duk_safe_call(thr, duk__pcall_raw, (void *) &args /*udata*/, nargs + 1 /*nargs*/, 1 /*nrets*/);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
}
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_LOCAL duk_ret_t duk__pcall_method_raw(duk_hthread *thr, void *udata) {
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk__pcall_method_args *args;
duk_idx_t idx_func;
duk_int_t ret;
public and internal stack API code
12 years ago
Extend internal struct validity assertions in GC * 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.
6 years ago
DUK_CTX_ASSERT_VALID(thr);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
DUK_ASSERT(udata != NULL);
public and internal stack API code
12 years ago
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
args = (duk__pcall_method_args *) udata;
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
idx_func = duk__call_get_idx_func_unvalidated(thr, args->nargs, 2);
DUK_ASSERT(duk_is_valid_index(thr, idx_func));
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
ret = duk_handle_call_unprotected(thr, idx_func, args->call_flags);
DUK_ASSERT(ret == 0);
DUK_UNREF(ret);
return 1;
public and internal stack API code
12 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_int_t duk_pcall_method_flags(duk_hthread *thr, duk_idx_t nargs, duk_small_uint_t call_flags) {
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk__pcall_method_args args;
public and internal stack API code
12 years ago
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
public and internal stack API code
12 years ago
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
args.nargs = nargs;
if (DUK_UNLIKELY(nargs < 0)) {
Remove Duktape specific error subtypes These don&#39;t play well with the API currently: the Duktape specific error codes don&#39;t have Ecmascript Error class counterparts so they don&#39;t get represented usefully as Ecmascript objects (e.g. AllocError is a plain Error from Ecmascript point of view). There&#39;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.
9 years ago
DUK_ERROR_TYPE_INVALID_ARGS(thr);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return DUK_EXEC_ERROR;);
public and internal stack API code
12 years ago
}
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
args.call_flags = call_flags;
public and internal stack API code
12 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
return duk_safe_call(thr, duk__pcall_method_raw, (void *) &args /*udata*/, nargs + 2 /*nargs*/, 1 /*nrets*/);
public and internal stack API code
12 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_int_t duk_pcall_method(duk_hthread *thr, duk_idx_t nargs) {
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
return duk_pcall_method_flags(thr, nargs, 0);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
}
make duk_pcall_prop() safer: errors related to stack shape or property lookup are also now caught properly
11 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_LOCAL duk_ret_t duk__pcall_prop_raw(duk_hthread *thr, void *udata) {
Add udata argument to duk_safe_call() 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.
9 years ago
duk__pcall_prop_args *args;
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
duk_idx_t obj_idx;
duk_int_t ret;
make duk_pcall_prop() safer: errors related to stack shape or property lookup are also now caught properly
11 years ago
Extend internal struct validity assertions in GC * 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.
6 years ago
DUK_CTX_ASSERT_VALID(thr);
Add udata argument to duk_safe_call() 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.
9 years ago
DUK_ASSERT(udata != NULL);
Add DUK_ASSERT_CTX_VALID() to API entrypoints
10 years ago
Add udata argument to duk_safe_call() 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.
9 years ago
args = (duk__pcall_prop_args *) udata;
make duk_pcall_prop() safer: errors related to stack shape or property lookup are also now caught properly
11 years ago
Reformat some source files with clang-format
3 years ago
obj_idx = duk_require_normalize_index(thr, args->obj_idx); /* make absolute */
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk__call_prop_prep_stack(thr, obj_idx, args->nargs);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
ret = duk_handle_call_unprotected_nargs(thr, args->nargs, args->call_flags);
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
DUK_ASSERT(ret == 0);
DUK_UNREF(ret);
make duk_pcall_prop() safer: errors related to stack shape or property lookup are also now caught properly
11 years ago
return 1;
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_int_t duk_pcall_prop(duk_hthread *thr, duk_idx_t obj_idx, duk_idx_t nargs) {
Add udata argument to duk_safe_call() 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.
9 years ago
duk__pcall_prop_args args;
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Add DUK_ASSERT_CTX_VALID() to API entrypoints
10 years ago
Avoid &#39;index&#39; as variable/argument name
9 years ago
args.obj_idx = obj_idx;
Add udata argument to duk_safe_call() 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.
9 years ago
args.nargs = nargs;
Fix some protected call arg checks * Fix duk_pcall_prop() nargs check to check for negative nargs explicitly. Otherwise negative arguments would be accepted in some cases. * Fix duk_safe_call() nargs check similarly. * Fix duk_pnew() nargs check similarly.
8 years ago
if (DUK_UNLIKELY(nargs < 0)) {
DUK_ERROR_TYPE_INVALID_ARGS(thr);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return DUK_EXEC_ERROR;);
Fix some protected call arg checks * Fix duk_pcall_prop() nargs check to check for negative nargs explicitly. Otherwise negative arguments would be accepted in some cases. * Fix duk_safe_call() nargs check similarly. * Fix duk_pnew() nargs check similarly.
8 years ago
}
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
args.call_flags = 0;
fix to duk_pcall_prop() arg handling
11 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
return duk_safe_call(thr, duk__pcall_prop_raw, (void *) &args /*udata*/, nargs + 1 /*nargs*/, 1 /*nrets*/);
public and internal stack API code
12 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_int_t duk_safe_call(duk_hthread *thr, duk_safe_call_function func, void *udata, duk_idx_t nargs, duk_idx_t nrets) {
Internal API typing rework
11 years ago
duk_int_t rc;
public and internal stack API code
12 years ago
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
public and internal stack API code
12 years ago
Shared call setup for Ecma-to-Ecma calls Remove the special ecma-to-ecma call setup code and just use the normal unprotected call setup code for that instead. Most of the code is the same; just before calling into the bytecode executor check if the current executor can be reused, and if so, indicate the situation using a special return code. Also remove internal duk_handle_call_protected() and implement all protected API calls via duk_safe_call(). This reduces footprint and code duplication further. Rework call handling to use helpers more to make the call handling code easier to follow. Various other minor changer, e.g. DUK_OP_NEW is now DUK_OP_CONSCALL and bytecode sets up the initial default instance.
8 years ago
/* nargs condition; fail if: top - bottom < nargs
* <=> top < bottom + nargs
* nrets condition; fail if: end - (top - nargs) < nrets
* <=> end - top + nargs < nrets
* <=> end + nargs < top + nrets
*/
/* XXX: check for any reserve? */
Reformat some source files with clang-format
3 years ago
if (DUK_UNLIKELY((nargs | nrets) < 0 || /* nargs < 0 || nrets < 0; OR sign bits */
thr->valstack_top < thr->valstack_bottom + nargs || /* nargs too large compared to top */
thr->valstack_end + nargs < thr->valstack_top + nrets)) { /* nrets too large compared to reserve */
Fix call related asserts triggered in stress tests
7 years ago
DUK_D(DUK_DPRINT("not enough stack reserve for safe call or invalid arguments: "
"nargs=%ld < 0 (?), nrets=%ld < 0 (?), top=%ld < bottom=%ld + nargs=%ld (?), "
"end=%ld + nargs=%ld < top=%ld + nrets=%ld (?)",
Reformat some source files with clang-format
3 years ago
(long) nargs,
(long) nrets,
(long) (thr->valstack_top - thr->valstack),
(long) (thr->valstack_bottom - thr->valstack),
(long) nargs,
(long) (thr->valstack_end - thr->valstack),
(long) nargs,
(long) (thr->valstack_top - thr->valstack),
(long) nrets));
Remove Duktape specific error subtypes These don&#39;t play well with the API currently: the Duktape specific error codes don&#39;t have Ecmascript Error class counterparts so they don&#39;t get represented usefully as Ecmascript objects (e.g. AllocError is a plain Error from Ecmascript point of view). There&#39;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.
9 years ago
DUK_ERROR_TYPE_INVALID_ARGS(thr);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return DUK_EXEC_ERROR;);
public and internal stack API code
12 years ago
}
Reformat some source files with clang-format
3 years ago
rc = duk_handle_safe_call(thr, /* thread */
func, /* func */
udata, /* udata */
nargs, /* num_stack_args */
nrets); /* num_stack_res */
public and internal stack API code
12 years ago
return rc;
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL void duk_new(duk_hthread *thr, duk_idx_t nargs) {
Allow yield from constructor calls
8 years ago
duk_idx_t idx_func;
public and internal stack API code
12 years ago
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Add DUK_ASSERT_CTX_VALID() to API entrypoints
10 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
idx_func = duk__call_get_idx_func(thr, nargs, 1);
DUK_ASSERT(duk_is_valid_index(thr, idx_func));
public and internal stack API code
12 years ago
Reformat some source files with clang-format
3 years ago
duk_push_object(thr); /* default instance; internal proto updated by call handling */
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_insert(thr, idx_func + 1);
augment errors thrown by Ecmascript code (when error object is created)
11 years ago
Shared handling for EVALCALL in call setup
7 years ago
duk_handle_call_unprotected(thr, idx_func, DUK_CALL_FLAG_CONSTRUCT);
public and internal stack API code
12 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_LOCAL duk_ret_t duk__pnew_helper(duk_hthread *thr, void *udata) {
Add udata argument to duk_safe_call() 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.
9 years ago
duk_idx_t nargs;
Add duk_pnew() API call
9 years ago
Add udata argument to duk_safe_call() 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.
9 years ago
DUK_ASSERT(udata != NULL);
nargs = *((duk_idx_t *) udata);
Add duk_pnew() API call
9 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_new(thr, nargs);
Add duk_pnew() API call
9 years ago
return 1;
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_int_t duk_pnew(duk_hthread *thr, duk_idx_t nargs) {
Add duk_pnew() API call
9 years ago
duk_int_t rc;
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Add duk_pnew() API call
9 years ago
/* For now, just use duk_safe_call() to wrap duk_new(). We can't
Allow yield from constructor calls
8 years ago
* simply use a protected duk_handle_call() because pushing the
* default instance might throw.
Add duk_pnew() API call
9 years ago
*/
Fix some protected call arg checks * Fix duk_pcall_prop() nargs check to check for negative nargs explicitly. Otherwise negative arguments would be accepted in some cases. * Fix duk_safe_call() nargs check similarly. * Fix duk_pnew() nargs check similarly.
8 years ago
if (DUK_UNLIKELY(nargs < 0)) {
DUK_ERROR_TYPE_INVALID_ARGS(thr);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return DUK_EXEC_ERROR;);
Fix some protected call arg checks * Fix duk_pcall_prop() nargs check to check for negative nargs explicitly. Otherwise negative arguments would be accepted in some cases. * Fix duk_safe_call() nargs check similarly. * Fix duk_pnew() nargs check similarly.
8 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
rc = duk_safe_call(thr, duk__pnew_helper, (void *) &nargs /*udata*/, nargs + 1 /*nargs*/, 1 /*nrets*/);
Add duk_pnew() API call
9 years ago
return rc;
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_bool_t duk_is_constructor_call(duk_hthread *thr) {
public and internal stack API code
12 years ago
duk_activation *act;
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
public and internal stack API code
12 years ago
Add thr-&gt;callstack_curr Makes common idiom of act = thr-&gt;callstack + thr-&gt;callstack_top - 1 shorter, footprint impact is about -0.5kB.
8 years ago
act = thr->callstack_curr;
Fix duk_is_constructor_call() empty callstack
8 years ago
if (act != NULL) {
return ((act->flags & DUK_ACT_FLAG_CONSTRUCT) != 0 ? 1 : 0);
}
return 0;
public and internal stack API code
12 years ago
}
API duk_require_{constructor_call,constructable}()
6 years ago
DUK_EXTERNAL void duk_require_constructor_call(duk_hthread *thr) {
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
if (!duk_is_constructor_call(thr)) {
DUK_ERROR_TYPE(thr, DUK_STR_CONSTRUCT_ONLY);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return;);
Encoding API implementation minor improvements
8 years ago
}
}
Source changes for property code switch
3 years ago
DUK_INTERNAL void duk_reject_constructor_call(duk_hthread *thr) {
DUK_ASSERT_API_ENTRY(thr);
if (duk_is_constructor_call(thr)) {
DUK_ERROR_TYPE(thr, DUK_STR_NONCONSTRUCT_ONLY);
DUK_WO_NORETURN(return;);
}
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_bool_t duk_is_strict_call(duk_hthread *thr) {
public and internal stack API code
12 years ago
duk_activation *act;
Fix duk_is_strict_call()/duk_is_constructor_call() Strictness change was in incorrect function.
10 years ago
/* For user code this could just return 1 (strict) always
* because all Duktape/C functions are considered strict,
* and strict is also the default when nothing is running.
* However, Duktape may call this function internally when
Use &#39;ECMAScript&#39; spelling in src-input
7 years ago
* the current activation is an ECMAScript function, so
Comment cleanups
10 years ago
* this cannot be replaced by a 'return 1' without fixing
* the internal call sites.
Fix duk_is_strict_call()/duk_is_constructor_call() Strictness change was in incorrect function.
10 years ago
*/
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
public and internal stack API code
12 years ago
Add thr-&gt;callstack_curr Makes common idiom of act = thr-&gt;callstack + thr-&gt;callstack_top - 1 shorter, footprint impact is about -0.5kB.
8 years ago
act = thr->callstack_curr;
if (act != NULL) {
return ((act->flags & DUK_ACT_FLAG_STRICT) != 0 ? 1 : 0);
} else {
Fix duk_is_strict_call()/duk_is_constructor_call() Strictness change was in incorrect function.
10 years ago
/* Strict by default. */
return 1;
}
public and internal stack API code
12 years ago
}
add a 16-bit &#39;magic&#39; field to native functions
11 years ago
/*
* Duktape/C function magic
*/
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_int_t duk_get_current_magic(duk_hthread *thr) {
add a 16-bit &#39;magic&#39; field to native functions
11 years ago
duk_activation *act;
duk_hobject *func;
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
add a 16-bit &#39;magic&#39; field to native functions
11 years ago
Add thr-&gt;callstack_curr Makes common idiom of act = thr-&gt;callstack + thr-&gt;callstack_top - 1 shorter, footprint impact is about -0.5kB.
8 years ago
act = thr->callstack_curr;
API call handling minor improvements
11 years ago
if (act) {
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
func = DUK_ACT_GET_FUNC(act);
if (!func) {
duk_tval *tv = &act->tv_func;
duk_small_uint_t lf_flags;
lf_flags = DUK_TVAL_GET_LIGHTFUNC_FLAGS(tv);
return (duk_int_t) DUK_LFUNC_FLAGS_GET_MAGIC(lf_flags);
}
API call handling minor improvements
11 years ago
DUK_ASSERT(func != NULL);
add a 16-bit &#39;magic&#39; field to native functions
11 years ago
Rename internal struct/define names Improve readability by doing the following renames: * duk_hcompiledfunction -&gt; duk_hcompfunc * duk_hnativefunction -&gt; duk_hnatfunc * duk_hbufferobject -&gt; duk_hbufobj Corresponding renames for all caps defines.
9 years ago
if (DUK_HOBJECT_IS_NATFUNC(func)) {
duk_hnatfunc *nf = (duk_hnatfunc *) func;
API call handling minor improvements
11 years ago
return (duk_int_t) nf->magic;
}
add a 16-bit &#39;magic&#39; field to native functions
11 years ago
}
return 0;
}
Add duk_{get,set}_magic() API calls
10 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL duk_int_t duk_get_magic(duk_hthread *thr, duk_idx_t idx) {
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
duk_tval *tv;
duk_hobject *h;
Add duk_{get,set}_magic() API calls
10 years ago
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Add duk_{get,set}_magic() API calls
10 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
tv = duk_require_tval(thr, idx);
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
if (DUK_TVAL_IS_OBJECT(tv)) {
h = DUK_TVAL_GET_OBJECT(tv);
DUK_ASSERT(h != NULL);
Rename internal struct/define names Improve readability by doing the following renames: * duk_hcompiledfunction -&gt; duk_hcompfunc * duk_hnativefunction -&gt; duk_hnatfunc * duk_hbufferobject -&gt; duk_hbufobj Corresponding renames for all caps defines.
9 years ago
if (!DUK_HOBJECT_HAS_NATFUNC(h)) {
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
goto type_error;
}
Rename internal struct/define names Improve readability by doing the following renames: * duk_hcompiledfunction -&gt; duk_hcompfunc * duk_hnativefunction -&gt; duk_hnatfunc * duk_hbufferobject -&gt; duk_hbufobj Corresponding renames for all caps defines.
9 years ago
return (duk_int_t) ((duk_hnatfunc *) h)->magic;
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
} else if (DUK_TVAL_IS_LIGHTFUNC(tv)) {
Second round of lightfunc support improvements * Fix outstanding FIXME issues for lightfunc semantics. * Improve API and Ecmascript testcases to match. * Clarify lightfunc limitations, e.g. finalizer limitations. * Guide and API documentation changes for lightfuncs. * Fix compile warning: duk_str_not_object unused.
10 years ago
duk_small_uint_t lf_flags = DUK_TVAL_GET_LIGHTFUNC_FLAGS(tv);
return (duk_int_t) DUK_LFUNC_FLAGS_GET_MAGIC(lf_flags);
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
}
/* fall through */
Reformat some source files with clang-format
3 years ago
type_error:
Reduce error call site footprint, internal changes * Use shared error macros and shared error handler to reduce the size of call sites of common errors. * Make zero argument DUK_ERROR() calls non-vararg calls to reduce call site footprint. Non-vararg calls have smaller call sites and because there are a lot of call sites, this turns out to be significant. * Remove variadic macros from internal DUK_ERROR() macro set and add separate macros for argument counts 0 to 4; this is more portable and requires less conditional code, and works well when a non-vararg call is used for most error call sites. * Rework macro / function argument order for the error path, try to keep &#39;thr&#39; in the same argument slot to avoid unnecessary register moves. * Pack linenumber and error code into a single 32-bit argument when possible, removes one more constant load from the call site. * Convert some internal errors to RangeErrors when the underlying cause is an implementation limit (such as a compiler temp limit) rather than an actual unexpected internal situation. * Simplify and share a few error messages to reduce string count.
9 years ago
DUK_ERROR_TYPE(thr, DUK_STR_UNEXPECTED_TYPE);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return 0;);
Add duk_{get,set}_magic() API calls
10 years ago
}
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_EXTERNAL void duk_set_magic(duk_hthread *thr, duk_idx_t idx, duk_int_t magic) {
Rename internal struct/define names Improve readability by doing the following renames: * duk_hcompiledfunction -&gt; duk_hcompfunc * duk_hnativefunction -&gt; duk_hnatfunc * duk_hbufferobject -&gt; duk_hbufobj Corresponding renames for all caps defines.
9 years ago
duk_hnatfunc *nf;
Add duk_{get,set}_magic() API calls
10 years ago
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
DUK_ASSERT_API_ENTRY(thr);
Add duk_{get,set}_magic() API calls
10 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
nf = duk_require_hnatfunc(thr, idx);
Add duk_{get,set}_magic() API calls
10 years ago
DUK_ASSERT(nf != NULL);
Type fix for magic value cast
10 years ago
nf->magic = (duk_int16_t) magic;
Add duk_{get,set}_magic() API calls
10 years ago
}
Allow bound function as Thread initial function
8 years ago
/*
* Misc helpers
*/
Add duk_hboundfunc internal type
8 years ago
/* Resolve a bound function on value stack top to a non-bound target
* (leave other values as is).
*/
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL void duk_resolve_nonbound_function(duk_hthread *thr) {
Allow bound function as Thread initial function
8 years ago
duk_tval *tv;
Extend internal struct validity assertions in GC * 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.
6 years ago
DUK_HTHREAD_ASSERT_VALID(thr);
Use DUK_ASSERT_API_ENTRY() for API calls
7 years ago
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
tv = DUK_GET_TVAL_NEGIDX(thr, -1);
Add duk_hboundfunc internal type
8 years ago
if (DUK_TVAL_IS_OBJECT(tv)) {
duk_hobject *h;
h = DUK_TVAL_GET_OBJECT(tv);
DUK_ASSERT(h != NULL);
if (DUK_HOBJECT_HAS_BOUNDFUNC(h)) {
Fix some armhf -Wcast-align issues
7 years ago
duk_push_tval(thr, &((duk_hboundfunc *) (void *) h)->target);
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_replace(thr, -2);
Add duk_hboundfunc internal type
8 years ago
#if 0
Source changes for property code switch
3 years ago
DUK_TVAL_SET_TVAL_INCREF(thr, tv, &((duk_hboundfunc *) h)->target);
Add duk_hboundfunc internal type
8 years ago
DUK_HOBJECT_DECREF_NORZ(thr, h);
#endif
/* Rely on Function.prototype.bind() on never creating a bound
* function whose target is not proper. This is now safe
* because the target is not even an internal property but a
* struct member.
*/
Use duk_hthread, not duk_context in internals 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 &lt;-&gt; 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&#39;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 &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT(duk_is_lightfunc(thr, -1) || duk_is_callable(thr, -1));
Allow bound function as Thread initial function
8 years ago
}
Add duk_hboundfunc internal type
8 years ago
}
/* Lightfuncs cannot be bound but are always callable and
* constructable.
*/
Allow bound function as Thread initial function
8 years ago
}