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.
8872 Commits
65 Branches
60 Tags
84 MiB
Tree: 44534e0385
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '44534e0385'
${ noResults }
duktape/src-input/duk_bi_function.c

443 lines
14 KiB
Raw Normal View History

more incomplete builtins
12 years ago
/*
* Function built-ins
*/
#include "duk_internal.h"
Make built-ins optional in metadata and source
8 years ago
/* Needed even when Function built-in is disabled. */
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_INTERNAL duk_ret_t duk_bi_function_prototype(duk_hthread *thr) {
Make built-ins optional in metadata and source
8 years ago
/* ignore arguments, return undefined (E5 Section 15.3.4) */
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_UNREF(thr);
Make built-ins optional in metadata and source
8 years ago
return 0;
}
#if defined(DUK_USE_FUNCTION_BUILTIN)
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_INTERNAL duk_ret_t duk_bi_function_constructor(duk_hthread *thr) {
Fix internal calls to duk_js_compile()
11 years ago
duk_hstring *h_sourcecode;
Miscellaneous typing work here and there
11 years ago
duk_idx_t nargs;
duk_idx_t i;
duk_small_uint_t comp_flags;
Rename internal struct/define names Improve readability by doing the following renames: * duk_hcompiledfunction -> duk_hcompfunc * duk_hnativefunction -> duk_hnatfunc * duk_hbufferobject -> duk_hbufobj Corresponding renames for all caps defines.
9 years ago
duk_hcompfunc *func;
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
duk_hobject *outer_lex_env;
duk_hobject *outer_var_env;
/* normal and constructor calls have identical semantics */
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
nargs = duk_get_top(thr);
Miscellaneous typing work here and there
11 years ago
for (i = 0; i < nargs; i++) {
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_to_string(thr, i); /* Rejects Symbols during coercion. */
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
}
Miscellaneous typing work here and there
11 years ago
if (nargs == 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_push_hstring_empty(thr);
duk_push_hstring_empty(thr);
Miscellaneous typing work here and there
11 years ago
} else if (nargs == 1) {
/* XXX: cover this with the generic >1 case? */
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_push_hstring_empty(thr);
more incomplete builtins
12 years ago
} else {
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, 0); /* [ arg1 ... argN-1 body] -> [body arg1 ... argN-1] */
duk_push_string(thr, ",");
duk_insert(thr, 1);
duk_join(thr, nargs - 1);
more incomplete builtins
12 years ago
}
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
/* [ body formals ], formals is comma separated list that needs to be parsed */
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_TOP(thr, 2);
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
FIXME cleanups
10 years ago
/* XXX: this placeholder is not always correct, but use for now.
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
* It will fail in corner cases; see test-dev-func-cons-args.js.
*/
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_push_string(thr, "function(");
duk_dup_1(thr);
duk_push_string(thr, "){");
duk_dup_0(thr);
duk_push_string(thr, "}");
duk_concat(thr, 5);
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
Fix internal calls to duk_js_compile()
11 years ago
/* [ body formals source ] */
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_TOP(thr, 3);
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
/* strictness is not inherited, intentional */
Use DUK_COMPILE_xxx flags are internally Avoids unnecessary translation.
8 years ago
comp_flags = DUK_COMPILE_FUNCEXPR;
placeholder implementation for Function constructor, should work in almost all cases
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_push_hstring_stridx(thr, DUK_STRIDX_COMPILE); /* XXX: copy from caller? */ /* XXX: ignored now */
h_sourcecode = duk_require_hstring(thr, -2); /* no symbol check needed; -2 is concat'd code */
Fix internal calls to duk_js_compile()
11 years ago
duk_js_compile(thr,
(const duk_uint8_t *) DUK_HSTRING_GET_DATA(h_sourcecode),
(duk_size_t) DUK_HSTRING_GET_BYTELEN(h_sourcecode),
comp_flags);
ES6 anon function and new Function() .name * Anonymous functions don&#39;t have an own &#39;.name&#39; property but inherit an empty string .name from Function.prototype. * new Function() returns a function whose name is &#39;anonymous&#39;.
8 years ago
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* Force .name to 'anonymous' (ES2015). */
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_push_string(thr, "anonymous");
duk_xdef_prop_stridx_short(thr, -2, DUK_STRIDX_NAME, DUK_PROPDESC_FLAGS_C);
ES6 anon function and new Function() .name * Anonymous functions don&#39;t have an own &#39;.name&#39; property but inherit an empty string .name from Function.prototype. * new Function() returns a function whose name is &#39;anonymous&#39;.
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
func = (duk_hcompfunc *) duk_known_hobject(thr, -1);
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_ASSERT(DUK_HOBJECT_IS_COMPFUNC((duk_hobject *) func));
Fix constructable/namebinding flags for compile
8 years ago
DUK_ASSERT(DUK_HOBJECT_HAS_CONSTRUCTABLE((duk_hobject *) func));
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
Fix internal calls to duk_js_compile()
11 years ago
/* [ body formals source template ] */
fix closure assertions related to outer_var_env==outer_lex_env, which is not the case
12 years ago
/* only outer_lex_env matters, as functions always get a new
* variable declaration environment.
*/
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
outer_lex_env = thr->builtins[DUK_BIDX_GLOBAL_ENV];
outer_var_env = thr->builtins[DUK_BIDX_GLOBAL_ENV];
Avoid .prototype for eval code Eval code doesn&#39;t need an automatic prototype object, so avoid creating one. This also avoids making the internal function which eval compiles to part of a reference loop so that eval functions collect immediately.
9 years ago
duk_js_push_closure(thr, func, outer_var_env, outer_lex_env, 1 /*add_auto_proto*/);
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
Fix internal calls to duk_js_compile()
11 years ago
/* [ body formals source template closure ] */
placeholder implementation for Function constructor, should work in almost all cases
12 years ago
return 1;
more incomplete builtins
12 years ago
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_FUNCTION_BUILTIN */
more incomplete builtins
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_FUNCTION_BUILTIN)
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_ret_t duk_bi_function_prototype_to_string(duk_hthread *thr) {
more incomplete builtins
12 years ago
duk_tval *tv;
function.prototype.toString() output must conform to FunctionDeclaration; in particular, the declaration must have a non-empty name in every case
12 years ago
/*
* E5 Section 15.3.4.2 places few requirements on the output of
Change function .toString() behavior to match ES6 String output must either (a) eval() back as an equivalent object, OR (b) eval() to a SyntaxError. Previous Duktape output, conformant to ES5/ES5.1, matched FunctionDeclaration syntax but didn&#39;t parse back as an equivalent function.
8 years ago
* this function: the result is implementation dependent, must
* follow FunctionDeclaration syntax (in particular, must have a
* name even for anonymous functions or functions with empty name).
* The output does NOT need to compile into anything useful.
function.prototype.toString() output must conform to FunctionDeclaration; in particular, the declaration must have a non-empty name in every case
12 years ago
*
Change function .toString() behavior to match ES6 String output must either (a) eval() back as an equivalent object, OR (b) eval() to a SyntaxError. Previous Duktape output, conformant to ES5/ES5.1, matched FunctionDeclaration syntax but didn&#39;t parse back as an equivalent function.
8 years ago
* E6 Section 19.2.3.5 changes the requirements completely: the
* result must either eval() to a functionally equivalent object
* OR eval() to a SyntaxError.
function.prototype.toString() output must conform to FunctionDeclaration; in particular, the declaration must have a non-empty name in every case
12 years ago
*
Change function .toString() behavior to match ES6 String output must either (a) eval() back as an equivalent object, OR (b) eval() to a SyntaxError. Previous Duktape output, conformant to ES5/ES5.1, matched FunctionDeclaration syntax but didn&#39;t parse back as an equivalent function.
8 years ago
* We opt for the SyntaxError approach for now, with a syntax that
* mimics V8's native function syntax:
function.prototype.toString() output must conform to FunctionDeclaration; in particular, the declaration must have a non-empty name in every case
12 years ago
*
Change function .toString() behavior to match ES6 String output must either (a) eval() back as an equivalent object, OR (b) eval() to a SyntaxError. Previous Duktape output, conformant to ES5/ES5.1, matched FunctionDeclaration syntax but didn&#39;t parse back as an equivalent function.
8 years ago
* 'function cos() { [native code] }'
*
* but extended with [ecmascript code], [bound code], and
* [lightfunc code].
function.prototype.toString() output must conform to FunctionDeclaration; in particular, the declaration must have a non-empty name in every case
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_push_this(thr);
tv = DUK_GET_TVAL_NEGIDX(thr, -1);
more incomplete builtins
12 years ago
DUK_ASSERT(tv != NULL);
if (DUK_TVAL_IS_OBJECT(tv)) {
duk_hobject *obj = DUK_TVAL_GET_OBJECT(tv);
Change Function .toString() format Emscripten depends on a Function&#39;s .toString() having a certain format (beyond what is guaranteed by the E5 specification). In particular, it won&#39;t parse Duktape&#39;s current format where the function body is replaced with a comment indicating the function type, e.g.: function foo() {/* ecmascript */} Change this format to indicate the function type using a string literal (similarly to how directive prologue works): function foo() {&#34;ecmascript&#34;} This is equally informational and will work directly with Emscripten. Also change handling for anonymous functions: substituting &#34;anon&#34; for an anonymous function in an Ecmascript function&#39;s .toString() output is a bit misleading. It also causes an Emscripten issue when a source regexp expects there to be no name for an anonymous function in the .toString() output.
9 years ago
const char *func_name;
Function.prototype.toString() function name printing placeholder
12 years ago
Change Function .toString() format Emscripten depends on a Function&#39;s .toString() having a certain format (beyond what is guaranteed by the E5 specification). In particular, it won&#39;t parse Duktape&#39;s current format where the function body is replaced with a comment indicating the function type, e.g.: function foo() {/* ecmascript */} Change this format to indicate the function type using a string literal (similarly to how directive prologue works): function foo() {&#34;ecmascript&#34;} This is equally informational and will work directly with Emscripten. Also change handling for anonymous functions: substituting &#34;anon&#34; for an anonymous function in an Ecmascript function&#39;s .toString() output is a bit misleading. It also causes an Emscripten issue when a source regexp expects there to be no name for an anonymous function in the .toString() output.
9 years ago
/* Function name: missing/undefined is mapped to empty string,
Change function .toString() behavior to match ES6 String output must either (a) eval() back as an equivalent object, OR (b) eval() to a SyntaxError. Previous Duktape output, conformant to ES5/ES5.1, matched FunctionDeclaration syntax but didn&#39;t parse back as an equivalent function.
8 years ago
* otherwise coerce to string. No handling for invalid identifier
* characters or e.g. '{' in the function name. This doesn't
* really matter as long as a SyntaxError results. Technically
* if the name contained a suitable prefix followed by '//' it
* might cause the result to parse without error.
Function.prototype.toString() function name printing placeholder
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_get_prop_stridx_short(thr, -1, DUK_STRIDX_NAME);
if (duk_is_undefined(thr, -1)) {
Change Function .toString() format Emscripten depends on a Function&#39;s .toString() having a certain format (beyond what is guaranteed by the E5 specification). In particular, it won&#39;t parse Duktape&#39;s current format where the function body is replaced with a comment indicating the function type, e.g.: function foo() {/* ecmascript */} Change this format to indicate the function type using a string literal (similarly to how directive prologue works): function foo() {&#34;ecmascript&#34;} This is equally informational and will work directly with Emscripten. Also change handling for anonymous functions: substituting &#34;anon&#34; for an anonymous function in an Ecmascript function&#39;s .toString() output is a bit misleading. It also causes an Emscripten issue when a source regexp expects there to be no name for an anonymous function in the .toString() output.
9 years ago
func_name = "";
} else {
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
func_name = duk_to_string(thr, -1);
Function.prototype.toString() function name printing placeholder
12 years ago
DUK_ASSERT(func_name != NULL);
}
Add duk_harray internal type Also rename &#34;BOUND&#34; to &#34;BOUNDFUNC&#34; in internal flags for consistency with &#34;COMPFUNC&#34; and &#34;NATIVEFUNC&#34;.
9 years ago
if (DUK_HOBJECT_IS_COMPFUNC(obj)) {
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_push_sprintf(thr, "function %s() { [ecmascript code] }", (const char *) func_name);
Add duk_harray internal type Also rename &#34;BOUND&#34; to &#34;BOUNDFUNC&#34; in internal flags for consistency with &#34;COMPFUNC&#34; and &#34;NATIVEFUNC&#34;.
9 years ago
} else if (DUK_HOBJECT_IS_NATFUNC(obj)) {
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_push_sprintf(thr, "function %s() { [native code] }", (const char *) func_name);
Add duk_harray internal type Also rename &#34;BOUND&#34; to &#34;BOUNDFUNC&#34; in internal flags for consistency with &#34;COMPFUNC&#34; and &#34;NATIVEFUNC&#34;.
9 years ago
} else if (DUK_HOBJECT_IS_BOUNDFUNC(obj)) {
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_push_sprintf(thr, "function %s() { [bound code] }", (const char *) func_name);
more incomplete builtins
12 years ago
} else {
goto type_error;
}
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)) {
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_push_lightfunc_tostring(thr, tv);
more incomplete builtins
12 years ago
} else {
goto type_error;
}
return 1;
type_error:
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_DCERROR_TYPE_INVALID_ARGS(thr);
more incomplete builtins
12 years ago
}
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
#endif
more incomplete builtins
12 years ago
Direct call handling of .call() and .apply() Handle .call() and .apply() directly without them being visible on the call stack.
8 years ago
/* Always present because the native function pointer is needed in 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_INTERNAL duk_ret_t duk_bi_function_prototype_call(duk_hthread *thr) {
Direct call handling of .call() and .apply() Handle .call() and .apply() directly without them being visible on the call stack.
8 years ago
/* .call() is dealt with in call handling by simulating its
* effects so this function is actually never called.
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
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_UNREF(thr);
Direct call handling of .call() and .apply() Handle .call() and .apply() directly without them being visible on the call stack.
8 years ago
return DUK_RET_TYPE_ERROR;
}
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
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_INTERNAL duk_ret_t duk_bi_function_prototype_apply(duk_hthread *thr) {
Direct call handling of .call() and .apply() Handle .call() and .apply() directly without them being visible on the call stack.
8 years ago
/* Like .call(), never actually called. */
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_UNREF(thr);
Direct call handling of .call() and .apply() Handle .call() and .apply() directly without them being visible on the call stack.
8 years ago
return DUK_RET_TYPE_ERROR;
}
more incomplete builtins
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_ret_t duk_bi_reflect_apply(duk_hthread *thr) {
Direct call handling of .call() and .apply() Handle .call() and .apply() directly without them being visible on the call stack.
8 years ago
/* Like .call(), never actually called. */
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_UNREF(thr);
Direct call handling of .call() and .apply() Handle .call() and .apply() directly without them being visible on the call stack.
8 years ago
return DUK_RET_TYPE_ERROR;
more incomplete builtins
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_ret_t duk_bi_reflect_construct(duk_hthread *thr) {
Direct Reflect.construct() call handling
8 years ago
/* Like .call(), never actually called. */
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_UNREF(thr);
Direct Reflect.construct() call handling
8 years ago
return DUK_RET_TYPE_ERROR;
more incomplete builtins
12 years ago
}
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_FUNCTION_BUILTIN)
Add duk_hboundfunc internal type
8 years ago
/* Create a bound function which points to a target function which may
* be bound or non-bound. If the target is bound, the argument lists
* and 'this' binding of the functions are merged and the resulting
* function points directly to the non-bound target.
more incomplete builtins
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_ret_t duk_bi_function_prototype_bind(duk_hthread *thr) {
Add duk_hboundfunc internal type
8 years ago
duk_hboundfunc *h_bound;
Function .bind() optimizations
8 years ago
duk_idx_t nargs; /* bound args, not counting 'this' binding */
Add duk_hboundfunc internal type
8 years ago
duk_idx_t bound_nargs;
duk_int_t bound_len;
duk_tval *tv_prevbound;
duk_idx_t n_prevbound;
duk_tval *tv_res;
duk_tval *tv_tmp;
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
/* XXX: C API call, e.g. duk_push_bound_function(thr, target_idx, nargs); */
Add duk_hboundfunc internal type
8 years ago
/* Vararg function, careful arg handling, e.g. thisArg may not
* be 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 &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
nargs = duk_get_top(thr) - 1; /* actual args, not counting 'this' binding */
Function .bind() optimizations
8 years ago
if (nargs < 0) {
more incomplete builtins
12 years ago
nargs++;
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_push_undefined(thr);
more incomplete builtins
12 years ago
}
Function .bind() optimizations
8 years ago
DUK_ASSERT(nargs >= 0);
more incomplete builtins
12 years ago
Add duk_hboundfunc internal type
8 years ago
/* Limit 'nargs' for bound functions to guarantee arithmetic
* below will never wrap.
*/
Function .bind() optimizations
8 years ago
if (nargs > (duk_idx_t) DUK_HBOUNDFUNC_MAX_ARGS) {
Add duk_hboundfunc internal type
8 years ago
DUK_DCERROR_RANGE_INVALID_COUNT(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
duk_push_this(thr);
duk_require_callable(thr, -1);
more incomplete builtins
12 years ago
Function .bind() optimizations
8 years ago
/* [ thisArg arg1 ... argN func ] (thisArg+args == nargs+1 total) */
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_TOP(thr, nargs + 2);
more incomplete builtins
12 years ago
Add duk_hboundfunc internal type
8 years ago
/* Create bound function object. */
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
h_bound = duk_push_hboundfunc(thr);
Add duk_hboundfunc internal type
8 years ago
DUK_ASSERT(DUK_TVAL_IS_UNDEFINED(&h_bound->target));
DUK_ASSERT(DUK_TVAL_IS_UNDEFINED(&h_bound->this_binding));
DUK_ASSERT(h_bound->args == NULL);
DUK_ASSERT(h_bound->nargs == 0);
DUK_ASSERT(DUK_HOBJECT_GET_PROTOTYPE(thr->heap, (duk_hobject *) h_bound) == NULL);
more incomplete builtins
12 years ago
/* [ thisArg arg1 ... argN func boundFunc ] */
Add duk_hboundfunc internal type
8 years ago
/* If the target is a bound function, argument lists must be
* merged. The 'this' binding closest to the target function
* wins because in call handling the 'this' gets replaced over
* and over again until we call the non-bound function.
*/
tv_prevbound = NULL;
n_prevbound = 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
tv_tmp = DUK_GET_TVAL_POSIDX(thr, 0);
Add duk_hboundfunc internal type
8 years ago
DUK_TVAL_SET_TVAL(&h_bound->this_binding, tv_tmp);
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_tmp = DUK_GET_TVAL_NEGIDX(thr, -2);
Function .bind() optimizations
8 years ago
DUK_TVAL_SET_TVAL(&h_bound->target, tv_tmp);
Add duk_hboundfunc internal type
8 years ago
Function .bind() optimizations
8 years ago
if (DUK_TVAL_IS_OBJECT(tv_tmp)) {
duk_hobject *h_target;
Add duk_hboundfunc internal type
8 years ago
duk_hobject *bound_proto;
more incomplete builtins
12 years ago
Function .bind() optimizations
8 years ago
h_target = DUK_TVAL_GET_OBJECT(tv_tmp);
DUK_ASSERT(DUK_HOBJECT_IS_CALLABLE(h_target));
Add duk_hboundfunc internal type
8 years ago
/* Internal prototype must be copied from the target.
* For lightfuncs Function.prototype is used and is already
* in place.
*/
bound_proto = DUK_HOBJECT_GET_PROTOTYPE(thr->heap, h_target);
DUK_HOBJECT_SET_PROTOTYPE_INIT_INCREF(thr, (duk_hobject *) h_bound, bound_proto);
more incomplete builtins
12 years ago
Add duk_hboundfunc internal type
8 years ago
/* The 'strict' flag is copied to get the special [[Get]] of E5.1
* Section 15.3.5.4 to apply when a 'caller' value is a strict bound
* function. Not sure if this is correct, because the specification
* is a bit ambiguous on this point but it would make sense.
*/
/* Strictness is inherited from target. */
if (DUK_HOBJECT_HAS_STRICT(h_target)) {
DUK_HOBJECT_SET_STRICT((duk_hobject *) h_bound);
}
more incomplete builtins
12 years ago
Add duk_hboundfunc internal type
8 years ago
if (DUK_HOBJECT_HAS_BOUNDFUNC(h_target)) {
duk_hboundfunc *h_boundtarget;
more incomplete builtins
12 years ago
Add duk_hboundfunc internal type
8 years ago
h_boundtarget = (duk_hboundfunc *) h_target;
more incomplete builtins
12 years ago
Add duk_hboundfunc internal type
8 years ago
/* The final function should always be non-bound, unless
* there's a bug in the internals. Assert for it.
*/
DUK_ASSERT(DUK_TVAL_IS_LIGHTFUNC(&h_boundtarget->target) ||
(DUK_TVAL_IS_OBJECT(&h_boundtarget->target) &&
DUK_HOBJECT_IS_CALLABLE(DUK_TVAL_GET_OBJECT(&h_boundtarget->target)) &&
!DUK_HOBJECT_IS_BOUNDFUNC(DUK_TVAL_GET_OBJECT(&h_boundtarget->target))));
Copy bound func prototype from target (ES6)
8 years ago
Add duk_hboundfunc internal type
8 years ago
DUK_TVAL_SET_TVAL(&h_bound->target, &h_boundtarget->target);
DUK_TVAL_SET_TVAL(&h_bound->this_binding, &h_boundtarget->this_binding);
tv_prevbound = h_boundtarget->args;
n_prevbound = h_boundtarget->nargs;
}
} else {
/* Lightfuncs are always strict. */
duk_hobject *bound_proto;
Function .bind() optimizations
8 years ago
DUK_ASSERT(DUK_TVAL_IS_LIGHTFUNC(tv_tmp));
Add duk_hboundfunc internal type
8 years ago
DUK_HOBJECT_SET_STRICT((duk_hobject *) h_bound);
bound_proto = thr->builtins[DUK_BIDX_FUNCTION_PROTOTYPE];
DUK_HOBJECT_SET_PROTOTYPE_INIT_INCREF(thr, (duk_hobject *) h_bound, bound_proto);
}
DUK_TVAL_INCREF(thr, &h_bound->target); /* old values undefined, no decref needed */
DUK_TVAL_INCREF(thr, &h_bound->this_binding);
Function .bind() optimizations
8 years ago
bound_nargs = n_prevbound + nargs;
Add duk_hboundfunc internal type
8 years ago
if (bound_nargs > (duk_idx_t) DUK_HBOUNDFUNC_MAX_ARGS) {
DUK_DCERROR_RANGE_INVALID_COUNT(thr);
Copy bound func prototype from target (ES6)
8 years ago
}
Add duk_hboundfunc internal type
8 years ago
tv_res = (duk_tval *) DUK_ALLOC_CHECKED(thr, ((duk_size_t) bound_nargs) * sizeof(duk_tval));
DUK_ASSERT(tv_res != NULL);
DUK_ASSERT(h_bound->args == NULL);
DUK_ASSERT(h_bound->nargs == 0);
h_bound->args = tv_res;
h_bound->nargs = bound_nargs;
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
DUK_ASSERT(n_prevbound >= 0);
duk_copy_tvals_incref(thr, tv_res, tv_prevbound, (duk_size_t) n_prevbound);
DUK_ASSERT(nargs >= 0);
duk_copy_tvals_incref(thr, tv_res + n_prevbound, DUK_GET_TVAL_POSIDX(thr, 1), (duk_size_t) nargs);
Add duk_hboundfunc internal type
8 years ago
/* [ thisArg arg1 ... argN func boundFunc ] */
Copy bound func prototype from target (ES6)
8 years ago
Function .bind() optimizations
8 years ago
/* Bound function 'length' property is interesting.
* For lightfuncs, simply read the virtual 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_get_prop_stridx_short(thr, -2, DUK_STRIDX_LENGTH);
bound_len = duk_get_int(thr, -1); /* ES2015: no coercion */
Function .bind() optimizations
8 years ago
if (bound_len < nargs) {
bound_len = 0;
} else {
bound_len -= nargs;
}
if (sizeof(duk_int_t) > 4 && bound_len > (duk_int_t) DUK_UINT32_MAX) {
bound_len = (duk_int_t) DUK_UINT32_MAX;
more incomplete builtins
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_pop(thr);
Function .bind() optimizations
8 years ago
DUK_ASSERT(bound_len >= 0);
tv_tmp = thr->valstack_top++;
DUK_ASSERT(DUK_TVAL_IS_UNDEFINED(tv_tmp));
DUK_ASSERT(!DUK_TVAL_NEEDS_REFCOUNT_UPDATE(tv_tmp));
DUK_TVAL_SET_U32(tv_tmp, (duk_uint32_t) bound_len); /* in-place update, fastint */
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_xdef_prop_stridx_short(thr, -2, DUK_STRIDX_LENGTH, DUK_PROPDESC_FLAGS_C); /* attrs in E6 Section 9.2.4 */
more incomplete builtins
12 years ago
Add duk_hboundfunc internal type
8 years ago
/* XXX: could these be virtual? */
/* Caller and arguments must use the same thrower, [[ThrowTypeError]]. */
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_xdef_prop_stridx_thrower(thr, -1, DUK_STRIDX_CALLER);
duk_xdef_prop_stridx_thrower(thr, -1, DUK_STRIDX_LC_ARGUMENTS);
add &#39;caller&#39; and &#39;arguments&#39; properties to bound functions, as required by E5.1 Section 15.3.4.5, steps 20-21
11 years ago
Add duk_hboundfunc internal type
8 years ago
/* Function name and fileName (non-standard). */
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_push_string(thr, "bound "); /* ES2015 19.2.3.2. */
duk_get_prop_stridx(thr, -3, DUK_STRIDX_NAME);
if (!duk_is_string_notsymbol(thr, -1)) {
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* ES2015 has requirement to check that .name of target is a string
Bound function name ES6 handling
8 years ago
* (also must check for Symbol); if not, targetName should be the
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
* empty string. ES2015 19.2.3.2.
Bound function name ES6 handling
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_pop(thr);
duk_push_hstring_empty(thr);
Bound function name ES6 handling
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_concat(thr, 2);
duk_xdef_prop_stridx_short(thr, -2, DUK_STRIDX_NAME, DUK_PROPDESC_FLAGS_C);
Opts for func .name and .fileName, attr fixes
8 years ago
#if defined(DUK_USE_FUNC_FILENAME_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_get_prop_stridx_short(thr, -2, DUK_STRIDX_FILE_NAME);
duk_xdef_prop_stridx_short(thr, -2, DUK_STRIDX_FILE_NAME, DUK_PROPDESC_FLAGS_C);
Opts for func .name and .fileName, attr fixes
8 years ago
#endif
copy &#39;name&#39; and &#39;fileName&#39; to bound functions for convenience
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_DDD(DUK_DDDPRINT("created bound function: %!iT", (duk_tval *) duk_get_tval(thr, -1)));
more incomplete builtins
12 years ago
return 1;
}
Make built-ins optional in metadata and source
8 years ago
#endif /* DUK_USE_FUNCTION_BUILTIN */
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
/* %NativeFunctionPrototype% .length getter. */
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_ret_t duk_bi_native_function_length(duk_hthread *thr) {
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
duk_tval *tv;
duk_hnatfunc *h;
duk_int16_t func_nargs;
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_borrowed_this_tval(thr);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
DUK_ASSERT(tv != NULL);
if (DUK_TVAL_IS_OBJECT(tv)) {
h = (duk_hnatfunc *) DUK_TVAL_GET_OBJECT(tv);
DUK_ASSERT(h != NULL);
if (!DUK_HOBJECT_IS_NATFUNC((duk_hobject *) h)) {
goto fail_type;
}
func_nargs = h->nargs;
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_push_int(thr, func_nargs == DUK_HNATFUNC_NARGS_VARARGS ? 0 : func_nargs);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
} else if (DUK_TVAL_IS_LIGHTFUNC(tv)) {
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
duk_small_uint_t lf_flags;
duk_small_uint_t lf_len;
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
lf_flags = DUK_TVAL_GET_LIGHTFUNC_FLAGS(tv);
lf_len = DUK_LFUNC_FLAGS_GET_LENGTH(lf_flags);
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
duk_push_uint(thr, lf_len);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
} else {
goto fail_type;
}
return 1;
fail_type:
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_DCERROR_TYPE_INVALID_ARGS(thr);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
}
/* %NativeFunctionPrototype% .name getter. */
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_ret_t duk_bi_native_function_name(duk_hthread *thr) {
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
duk_tval *tv;
duk_hnatfunc *h;
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_borrowed_this_tval(thr);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
DUK_ASSERT(tv != NULL);
if (DUK_TVAL_IS_OBJECT(tv)) {
h = (duk_hnatfunc *) DUK_TVAL_GET_OBJECT(tv);
DUK_ASSERT(h != NULL);
if (!DUK_HOBJECT_IS_NATFUNC((duk_hobject *) h)) {
goto fail_type;
}
#if 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_push_hnatfunc_name(thr, h);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
#endif
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_push_hstring_empty(thr);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
} else if (DUK_TVAL_IS_LIGHTFUNC(tv)) {
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_push_lightfunc_name(thr, tv);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
} else {
goto fail_type;
}
return 1;
fail_type:
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_DCERROR_TYPE_INVALID_ARGS(thr);
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
}