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

388 lines
14 KiB
Raw Normal View History

a bunch of builtins
12 years ago
/*
* Error built-ins
*/
#include "duk_internal.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 <-> 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_error_constructor_shared(duk_hthread *thr) {
a bunch of builtins
12 years ago
/* Behavior for constructor and non-constructor call is
augment built-in errors even when created with a non-constructor call
11 years ago
* the same except for augmenting the created error. When
* called as a constructor, the caller (duk_new()) will handle
* augmentation; when called as normal function, we need to do
* it here.
a bunch of 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 <-> 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_small_int_t bidx_prototype = duk_get_current_magic(thr);
augment built-in errors even when created with a non-constructor call
11 years ago
add missing built-in error constructors (TypeError etc) and a testcase for them
11 years ago
/* same for both error and each subclass like TypeError */
A round of internal typing fixes (midcommit)
11 years ago
duk_uint_t flags_and_class = DUK_HOBJECT_FLAG_EXTENSIBLE |
Add DUK_HOBJECT_FLAG_FASTREFS for DECREF/marking When the flag is set, there is either no subclass C struct for the duk_hobject, or there is a subclass C struct but there are no references needing DECREF/marking in the struct. This allows DECREF and mark-and-sweep to handle duk_hobjects with less overhead for the common cases of plain objects and arrays (and some other less commonly collected structs like duk_hnatfunc). Also change Duktape.Thread.prototype internal class from Thread to Object: with the other changes internal code now assumes that if an object's class is Thread, it has the duk_hthread memory layout which wouldn't be the case for Duktape.Thread.prototype.
8 years ago
DUK_HOBJECT_FLAG_FASTREFS |
A round of internal typing fixes (midcommit)
11 years ago
DUK_HOBJECT_CLASS_AS_FLAGS(DUK_HOBJECT_CLASS_ERROR);
Code policy issue fix trivia
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 <-> 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
(void) duk_push_object_helper(thr, flags_and_class, bidx_prototype);
a bunch of builtins
12 years ago
note that 'message' own property is not set for errors when message not given (E5.1 behavior)
11 years ago
/* If message is undefined, the own property 'message' is not set at
* all to save property space. An empty message is inherited anyway.
*/
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
if (!duk_is_undefined(thr, 0)) {
duk_to_string(thr, 0);
duk_dup_0(thr); /* [ message error message ] */
duk_xdef_prop_stridx_short(thr, -2, DUK_STRIDX_MESSAGE, DUK_PROPDESC_FLAGS_WC);
a bunch of builtins
12 years ago
}
augment built-in errors even when created with a non-constructor call
11 years ago
/* Augment the error if called as a normal function. __FILE__ and __LINE__
* are not desirable in this case.
*/
Source fixes for #ifdef and #ifndef convention
8 years ago
#if defined(DUK_USE_AUGMENT_ERROR_CREATE)
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
if (!duk_is_constructor_call(thr)) {
Allow yield from constructor calls
8 years ago
duk_err_augment_error_create(thr, thr, NULL, 0, DUK_AUGMENT_FLAG_NOBLAME_FILELINE);
augment built-in errors even when created with a non-constructor call
11 years ago
}
#endif
a bunch of builtins
12 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 <-> 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_error_prototype_to_string(duk_hthread *thr) {
FIXME cleanups
10 years ago
/* XXX: optimize with more direct internal access */
a bunch of 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 <-> 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_push_this(thr);
(void) duk_require_hobject_promote_mask(thr, -1, DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER);
a bunch of builtins
12 years ago
/* [ ... this ] */
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_get_prop_stridx_short(thr, -1, DUK_STRIDX_NAME);
if (duk_is_undefined(thr, -1)) {
duk_pop(thr);
duk_push_string(thr, "Error");
a bunch of 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 <-> 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_to_string(thr, -1);
a bunch of builtins
12 years ago
}
/* [ ... this name ] */
FIXME cleanups
10 years ago
/* XXX: Are steps 6 and 7 in E5 Section 15.11.4.4 duplicated by
a bunch of builtins
12 years ago
* accident or are they actually needed? The first ToString()
* could conceivably return 'undefined'.
*/
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_get_prop_stridx_short(thr, -2, DUK_STRIDX_MESSAGE);
if (duk_is_undefined(thr, -1)) {
duk_pop(thr);
duk_push_hstring_empty(thr);
a bunch of 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 <-> 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_to_string(thr, -1);
a bunch of builtins
12 years ago
}
/* [ ... this name message ] */
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
if (duk_get_length(thr, -2) == 0) {
a bunch of builtins
12 years ago
/* name is empty -> return message */
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 <-> 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
if (duk_get_length(thr, -1) == 0) {
a bunch of builtins
12 years ago
/* message is empty -> return name */
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_pop(thr);
a bunch of builtins
12 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 <-> 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_push_string(thr, ": ");
duk_insert(thr, -2); /* ... name ': ' message */
duk_concat(thr, 3);
a bunch of builtins
12 years ago
return 1;
}
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
9 years ago
#if defined(DUK_USE_TRACEBACKS)
fix traceback related built-ins when tracebacks are disabled
11 years ago
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
/*
* Traceback handling
*
* The unified helper decodes the traceback and produces various requested
* outputs. It should be optimized for size, and may leave garbage on stack,
* only the topmost return value matters. For instance, traceback separator
* and decoded strings are pushed even when looking for filename only.
security note on 'tracedata' handling
11 years ago
*
Source comment fixes for int key capitalization
10 years ago
* NOTE: although _Tracedata is an internal property, user code can currently
* write to the array (or replace it with something other than an array).
* The code below must tolerate arbitrary _Tracedata. It can throw errors
* etc, but cannot cause a segfault or memory unsafe behavior.
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
*/
/* constants arbitrary, chosen for small loads */
clean up #define, #undef, #ifdef etc to have a single space after the directive
11 years ago
#define DUK__OUTPUT_TYPE_TRACEBACK (-1)
#define DUK__OUTPUT_TYPE_FILENAME 0
#define DUK__OUTPUT_TYPE_LINENUMBER 1
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
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 <-> 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_ret_t duk__error_getter_helper(duk_hthread *thr, duk_small_int_t output_type) {
A round of internal typing fixes (midcommit)
11 years ago
duk_idx_t idx_td;
duk_small_int_t i; /* traceback depth fits into 16 bits */
duk_small_int_t t; /* stack type fits into 16 bits */
Fix stacktrace [...] handling The compilation error and C call site were not taken into account, which caused the traceback to contain a truncation marker early.
9 years ago
duk_small_int_t count_func = 0; /* traceback depth ensures fits into 16 bits */
Make .stack format more user friendly * Add 'at foo' to indicate function name * Put file/line into parentheses for better readability * Use [anon] for anymous functions, which is better than an empty string but distinguishable from a function actually named 'anon' * Rename tailcalled flag to tailcall * Switch from tab indent to 4 space indent
9 years ago
const char *str_tailcall = " tailcall";
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
const char *str_strict = " strict";
const char *str_construct = " construct";
indicate prevents yield flag in traceback
11 years ago
const char *str_prevyield = " preventsyield";
add direct eval flag to traceback
11 years ago
const char *str_directeval = " directeval";
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
const char *str_empty = "";
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_ASSERT_TOP(thr, 0); /* fixed arg count */
add accessor property support to built-in initializer format; make 'stack' an accessor
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 <-> 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_push_this(thr);
duk_get_prop_stridx_short(thr, -1, DUK_STRIDX_INT_TRACEDATA);
idx_td = duk_get_top_index(thr);
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
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 <-> 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_push_hstring_stridx(thr, DUK_STRIDX_NEWLINE_4SPACE);
duk_push_this(thr);
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
Avoid error tostring for .fileName/.lineNumber
9 years ago
/* [ ... this tracedata sep this ] */
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
FIXME cleanups
10 years ago
/* XXX: skip null filename? */
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
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 <-> 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
if (duk_check_type(thr, idx_td, DUK_TYPE_OBJECT)) {
truncated traceback denoted with ellipsis
11 years ago
/* Current tracedata contains 2 entries per callstack entry. */
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
for (i = 0; ; i += 2) {
A round of internal typing fixes (midcommit)
11 years ago
duk_int_t pc;
duk_int_t line;
duk_int_t flags;
duk_double_t d;
interpret empty name as anon function in tracebacks
11 years ago
const char *funcname;
Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.
10 years ago
const char *filename;
interpret empty name as anon function in tracebacks
11 years ago
duk_hobject *h_func;
duk_hstring *h_name;
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
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 <-> 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_require_stack(thr, 5);
duk_get_prop_index(thr, idx_td, i);
duk_get_prop_index(thr, idx_td, i + 1);
d = duk_to_number_m1(thr);
A round of internal typing fixes (midcommit)
11 years ago
pc = (duk_int_t) DUK_FMOD(d, DUK_DOUBLE_2TO32);
flags = (duk_int_t) DUK_FLOOR(d / DUK_DOUBLE_2TO32);
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
t = (duk_small_int_t) duk_get_type(thr, -2);
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
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 'length' property of a bound function now comes out wrong. We could simply look up the virtual 'length' 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 'magic' to activation for lightfuncs. It will be needed for lightweight functions: we don'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 (t == DUK_TYPE_OBJECT || t == DUK_TYPE_LIGHTFUNC) {
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
/*
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 'length' property of a bound function now comes out wrong. We could simply look up the virtual 'length' 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 'magic' to activation for lightfuncs. It will be needed for lightweight functions: we don'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
* Ecmascript/native function call or lightfunc call
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
*/
Fix stacktrace [...] handling The compilation error and C call site were not taken into account, which caused the traceback to contain a truncation marker early.
9 years ago
count_func++;
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
/* [ ... v1(func) v2(pc+flags) ] */
Opts for func .name and .fileName, attr fixes
8 years ago
/* These may be systematically omitted by Duktape
* with certain config options, but allow user to
* set them on a case-by-case basis.
*/
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_get_prop_stridx_short(thr, -2, DUK_STRIDX_NAME);
duk_get_prop_stridx_short(thr, -3, DUK_STRIDX_FILE_NAME);
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
make compiler line number tracking conditionl to DUK_USE_PC2LINE; now always enabled, but can be disabled for memory optimization later
11 years ago
#if defined(DUK_USE_PC2LINE)
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
line = duk_hobject_pc2line_query(thr, -4, (duk_uint_fast32_t) pc);
make compiler line number tracking conditionl to DUK_USE_PC2LINE; now always enabled, but can be disabled for memory optimization later
11 years ago
#else
line = 0;
#endif
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
interpret empty name as anon function in tracebacks
11 years ago
/* [ ... v1 v2 name filename ] */
Better error .fileName and .lineNumber default Use the first traceback entry which actually has a .fileName to provide virtual .fileName and .lineNumber. This works better for expressions such as 'Duktape.enc(123)' which currently get 'undefined' as .fileName (comes from the enc() function, which has no .fileName property).
9 years ago
/* When looking for .fileName/.lineNumber, blame first
* function which has a .fileName.
*/
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
if (duk_is_string_notsymbol(thr, -1)) {
Better error .fileName and .lineNumber default Use the first traceback entry which actually has a .fileName to provide virtual .fileName and .lineNumber. This works better for expressions such as 'Duktape.enc(123)' which currently get 'undefined' as .fileName (comes from the enc() function, which has no .fileName property).
9 years ago
if (output_type == DUK__OUTPUT_TYPE_FILENAME) {
return 1;
} else if (output_type == DUK__OUTPUT_TYPE_LINENUMBER) {
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_push_int(thr, line);
Better error .fileName and .lineNumber default Use the first traceback entry which actually has a .fileName to provide virtual .fileName and .lineNumber. This works better for expressions such as 'Duktape.enc(123)' which currently get 'undefined' as .fileName (comes from the enc() function, which has no .fileName property).
9 years ago
return 1;
}
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
}
Change Function .toString() format Emscripten depends on a Function's .toString() having a certain format (beyond what is guaranteed by the E5 specification). In particular, it won't parse Duktape'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() {"ecmascript"} This is equally informational and will work directly with Emscripten. Also change handling for anonymous functions: substituting "anon" for an anonymous function in an Ecmascript function'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
/* XXX: Change 'anon' handling here too, to use empty string for anonymous functions? */
/* XXX: Could be improved by coercing to a readable duk_tval (especially string escaping) */
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
h_name = duk_get_hstring_notsymbol(thr, -2); /* may be NULL */
interpret empty name as anon function in tracebacks
11 years ago
funcname = (h_name == NULL || h_name == DUK_HTHREAD_STRING_EMPTY_STRING(thr)) ?
Make .stack format more user friendly * Add 'at foo' to indicate function name * Put file/line into parentheses for better readability * Use [anon] for anymous functions, which is better than an empty string but distinguishable from a function actually named 'anon' * Rename tailcalled flag to tailcall * Switch from tab indent to 4 space indent
9 years ago
"[anon]" : (const char *) DUK_HSTRING_GET_DATA(h_name);
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
filename = duk_get_string_notsymbol(thr, -1);
Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.
10 years ago
filename = filename ? filename : "";
DUK_ASSERT(funcname != NULL);
DUK_ASSERT(filename != NULL);
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
h_func = duk_get_hobject(thr, -4); /* NULL for lightfunc */
Use %NativeFunctionPrototype% for native functions Not applied to built-in native functions which must inherit directly from Function.prototype.
8 years ago
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 'length' property of a bound function now comes out wrong. We could simply look up the virtual 'length' 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 'magic' to activation for lightfuncs. It will be needed for lightweight functions: we don'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 (h_func == NULL) {
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_push_sprintf(thr, "at %s light%s%s%s%s%s",
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 'length' property of a bound function now comes out wrong. We could simply look up the virtual 'length' 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 'magic' to activation for lightfuncs. It will be needed for lightweight functions: we don'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
(const char *) funcname,
(const char *) ((flags & DUK_ACT_FLAG_STRICT) ? str_strict : str_empty),
Make .stack format more user friendly * Add 'at foo' to indicate function name * Put file/line into parentheses for better readability * Use [anon] for anymous functions, which is better than an empty string but distinguishable from a function actually named 'anon' * Rename tailcalled flag to tailcall * Switch from tab indent to 4 space indent
9 years ago
(const char *) ((flags & DUK_ACT_FLAG_TAILCALLED) ? str_tailcall : str_empty),
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 'length' property of a bound function now comes out wrong. We could simply look up the virtual 'length' 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 'magic' to activation for lightfuncs. It will be needed for lightweight functions: we don'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
(const char *) ((flags & DUK_ACT_FLAG_CONSTRUCT) ? str_construct : str_empty),
(const char *) ((flags & DUK_ACT_FLAG_DIRECT_EVAL) ? str_directeval : str_empty),
(const char *) ((flags & DUK_ACT_FLAG_PREVENT_YIELD) ? str_prevyield : str_empty));
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
} else if (DUK_HOBJECT_HAS_NATFUNC(h_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 <-> 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_push_sprintf(thr, "at %s (%s) native%s%s%s%s%s",
Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.
10 years ago
(const char *) funcname,
(const char *) filename,
(const char *) ((flags & DUK_ACT_FLAG_STRICT) ? str_strict : str_empty),
Make .stack format more user friendly * Add 'at foo' to indicate function name * Put file/line into parentheses for better readability * Use [anon] for anymous functions, which is better than an empty string but distinguishable from a function actually named 'anon' * Rename tailcalled flag to tailcall * Switch from tab indent to 4 space indent
9 years ago
(const char *) ((flags & DUK_ACT_FLAG_TAILCALLED) ? str_tailcall : str_empty),
Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.
10 years ago
(const char *) ((flags & DUK_ACT_FLAG_CONSTRUCT) ? str_construct : str_empty),
(const char *) ((flags & DUK_ACT_FLAG_DIRECT_EVAL) ? str_directeval : str_empty),
(const char *) ((flags & DUK_ACT_FLAG_PREVENT_YIELD) ? str_prevyield : str_empty));
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 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 <-> 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_push_sprintf(thr, "at %s (%s:%ld)%s%s%s%s%s",
Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.
10 years ago
(const char *) funcname,
(const char *) filename,
A round of internal typing fixes (midcommit)
11 years ago
(long) line,
Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.
10 years ago
(const char *) ((flags & DUK_ACT_FLAG_STRICT) ? str_strict : str_empty),
Make .stack format more user friendly * Add 'at foo' to indicate function name * Put file/line into parentheses for better readability * Use [anon] for anymous functions, which is better than an empty string but distinguishable from a function actually named 'anon' * Rename tailcalled flag to tailcall * Switch from tab indent to 4 space indent
9 years ago
(const char *) ((flags & DUK_ACT_FLAG_TAILCALLED) ? str_tailcall : str_empty),
Format string cleanups, allow NULL+%s/%p in debug Lots of minor string format cleanups (casts mainly). Add a special check to detect NULL pointers with %s/%p formats in debug logging to avoid calling the platform sprintf() with a NULL value. This is especially important for %s + NULL, which is not portable and may crash on some platforms. Debug logging will now format these specially as "NULL" and avoid calling the platform for formatting, so debug log call sites don't need to be careful with NULL pointers any more.
10 years ago
(const char *) ((flags & DUK_ACT_FLAG_CONSTRUCT) ? str_construct : str_empty),
(const char *) ((flags & DUK_ACT_FLAG_DIRECT_EVAL) ? str_directeval : str_empty),
(const char *) ((flags & DUK_ACT_FLAG_PREVENT_YIELD) ? str_prevyield : str_empty));
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
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 <-> 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_replace(thr, -5); /* [ ... v1 v2 name filename str ] -> [ ... str v2 name filename ] */
duk_pop_3(thr); /* -> [ ... str ] */
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
} else if (t == DUK_TYPE_STRING) {
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof "symbol" but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for('foo') creates the byte representatio: 0x80 "foo" * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 "mySymbol" 0xFF "0-17". * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 <description> 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF <unique suffix> 0xFF.
8 years ago
const char *str_file;
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
/*
* __FILE__ / __LINE__ entry, here 'pc' is line number directly.
don't blame __FILE__ / __LINE__ for Duktape generated errors (but record them in the traceback)
11 years ago
* Sometimes __FILE__ / __LINE__ is reported as the source for
* the error (fileName, lineNumber), sometimes not.
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
*/
/* [ ... v1(filename) v2(line+flags) ] */
Better error .fileName and .lineNumber default Use the first traceback entry which actually has a .fileName to provide virtual .fileName and .lineNumber. This works better for expressions such as 'Duktape.enc(123)' which currently get 'undefined' as .fileName (comes from the enc() function, which has no .fileName property).
9 years ago
/* When looking for .fileName/.lineNumber, blame compilation
* or C call site unless flagged not to do so.
*/
don't blame __FILE__ / __LINE__ for Duktape generated errors (but record them in the traceback)
11 years ago
if (!(flags & DUK_TB_FLAG_NOBLAME_FILELINE)) {
if (output_type == DUK__OUTPUT_TYPE_FILENAME) {
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_pop(thr);
don't blame __FILE__ / __LINE__ for Duktape generated errors (but record them in the traceback)
11 years ago
return 1;
} else if (output_type == DUK__OUTPUT_TYPE_LINENUMBER) {
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_push_int(thr, pc);
don't blame __FILE__ / __LINE__ for Duktape generated errors (but record them in the traceback)
11 years ago
return 1;
}
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
}
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof "symbol" but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for('foo') creates the byte representatio: 0x80 "foo" * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 "mySymbol" 0xFF "0-17". * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 <description> 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF <unique suffix> 0xFF.
8 years ago
/* Tracedata is trusted but avoid any risk of using a NULL
* for %s format because it has undefined behavior. Symbols
* don't need to be explicitly rejected as they pose no memory
* safety issues.
*/
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
str_file = (const char *) duk_get_string(thr, -2);
duk_push_sprintf(thr, "at [anon] (%s:%ld) internal",
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof "symbol" but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for('foo') creates the byte representatio: 0x80 "foo" * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 "mySymbol" 0xFF "0-17". * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 <description> 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF <unique suffix> 0xFF.
8 years ago
(const char *) (str_file ? str_file : "null"), (long) pc);
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_replace(thr, -3); /* [ ... v1 v2 str ] -> [ ... str v2 ] */
duk_pop(thr); /* -> [ ... str ] */
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
} else {
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
/* unknown, ignore */
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_pop_2(thr);
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
break;
}
}
truncated traceback denoted with ellipsis
11 years ago
Fix stacktrace [...] handling The compilation error and C call site were not taken into account, which caused the traceback to contain a truncation marker early.
9 years ago
if (count_func >= DUK_USE_TRACEBACK_DEPTH) {
truncated traceback denoted with ellipsis
11 years ago
/* Possibly truncated; there is no explicit truncation
* marker so this is the best we can do.
*/
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
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 <-> 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_push_hstring_stridx(thr, DUK_STRIDX_BRACKETED_ELLIPSIS);
truncated traceback denoted with ellipsis
11 years ago
}
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
}
Avoid error tostring for .fileName/.lineNumber
9 years ago
/* [ ... this tracedata sep this str1 ... strN ] */
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
11 years ago
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
if (output_type != DUK__OUTPUT_TYPE_TRACEBACK) {
return 0;
} else {
Avoid error tostring for .fileName/.lineNumber
9 years ago
/* The 'this' after 'sep' will get ToString() coerced by
* duk_join() automatically. We don't want to do that
* coercion when providing .fileName or .lineNumber (GH-254).
*/
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_join(thr, duk_get_top(thr) - (idx_td + 2) /*count, not including sep*/);
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
11 years ago
return 1;
}
}
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
9 years ago
/* XXX: Output type could be encoded into native function 'magic' value to
* save space. For setters the stridx could be encoded into 'magic'.
refactor 'stack' getter into a shared helper used for 'stack', 'lineNumber', and 'fileName'
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 <-> 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_error_prototype_stack_getter(duk_hthread *thr) {
return duk__error_getter_helper(thr, DUK__OUTPUT_TYPE_TRACEBACK);
add a prototype implementation for a stack traceback getter (implemented as an actual function for now)
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 <-> 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_error_prototype_filename_getter(duk_hthread *thr) {
return duk__error_getter_helper(thr, DUK__OUTPUT_TYPE_FILENAME);
add fileName and lineNumber accessors to Error.prototype; make stack, fileName, and lineNumber setter be an explicit nop
11 years ago
}
add accessor property support to built-in initializer format; make 'stack' an accessor
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 <-> 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_error_prototype_linenumber_getter(duk_hthread *thr) {
return duk__error_getter_helper(thr, DUK__OUTPUT_TYPE_LINENUMBER);
add fileName and lineNumber accessors to Error.prototype; make stack, fileName, and lineNumber setter be an explicit nop
11 years ago
}
fix traceback related built-ins when tracebacks are disabled
11 years ago
#else /* DUK_USE_TRACEBACKS */
/*
* Traceback handling when tracebacks disabled.
*
make 'stack' return ToString(err) when tracebacks disabled
11 years ago
* The fileName / lineNumber stubs are now necessary because built-in
* data will include the accessor properties in Error.prototype. If those
* are removed for builds without tracebacks, these can also be removed.
* 'stack' should still be present and produce a ToString() equivalent:
* this is useful for user code which prints a stacktrace and expects to
* see something useful. A normal stacktrace also begins with a ToString()
* of the error so this makes sense.
fix traceback related built-ins when tracebacks are disabled
11 years ago
*/
make 'stack' return ToString(err) when tracebacks disabled
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 <-> 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_error_prototype_stack_getter(duk_hthread *thr) {
FIXME cleanups
10 years ago
/* XXX: remove this native function and map 'stack' accessor
make 'stack' call 'toString()' directly
11 years ago
* to the toString() implementation directly.
*/
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
return duk_bi_error_prototype_to_string(thr);
fix traceback related built-ins when tracebacks are disabled
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 <-> 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_error_prototype_filename_getter(duk_hthread *thr) {
DUK_UNREF(thr);
fix traceback related built-ins when tracebacks are disabled
11 years ago
return 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
DUK_INTERNAL duk_ret_t duk_bi_error_prototype_linenumber_getter(duk_hthread *thr) {
DUK_UNREF(thr);
fix traceback related built-ins when tracebacks are disabled
11 years ago
return 0;
}
#endif /* DUK_USE_TRACEBACKS */
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_ret_t duk__error_setter_helper(duk_hthread *thr, duk_small_uint_t stridx_key) {
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
9 years ago
/* Attempt to write 'stack', 'fileName', 'lineNumber' works as if
* user code called Object.defineProperty() to create an overriding
* own property. This allows user code to overwrite .fileName etc
* intuitively as e.g. "err.fileName = 'dummy'" as one might expect.
* See https://github.com/svaarala/duktape/issues/387.
add accessor property support to built-in initializer format; make 'stack' an accessor
11 years ago
*/
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
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 <-> 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_ASSERT_TOP(thr, 1); /* fixed arg count: value */
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
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 <-> 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_push_this(thr);
duk_push_hstring_stridx(thr, (duk_small_int_t) stridx_key);
duk_dup_0(thr);
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
9 years ago
/* [ ... obj key value ] */
DUK_DD(DUK_DDPRINT("error setter: %!T %!T %!T",
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_get_tval(thr, -3), duk_get_tval(thr, -2), duk_get_tval(thr, -1)));
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
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 <-> 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_def_prop(thr, -3, DUK_DEFPROP_HAVE_VALUE |
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
9 years ago
DUK_DEFPROP_HAVE_WRITABLE | DUK_DEFPROP_WRITABLE |
DUK_DEFPROP_HAVE_ENUMERABLE | /*not enumerable*/
DUK_DEFPROP_HAVE_CONFIGURABLE | DUK_DEFPROP_CONFIGURABLE);
add accessor property support to built-in initializer format; make 'stack' an accessor
11 years ago
return 0;
}
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
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 <-> 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_error_prototype_stack_setter(duk_hthread *thr) {
return duk__error_setter_helper(thr, DUK_STRIDX_STACK);
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
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 <-> 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_error_prototype_filename_setter(duk_hthread *thr) {
return duk__error_setter_helper(thr, DUK_STRIDX_FILE_NAME);
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
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 <-> 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_error_prototype_linenumber_setter(duk_hthread *thr) {
return duk__error_setter_helper(thr, DUK_STRIDX_LINE_NUMBER);
Simulate a defprop in error .fileName etc setters Previous behavior was to ignore the setter call, so that attempting a write would be a no-op: "err.fileName = 'dummy';" would do nothing. Because the inherited setter is configurable, the user could still create an own property of the same name using Object.defineProperty() or duk_def_prop() but this is not very intuitive nor very well documented. The updated behavior is to make the .fileName, .lineNumber, and .stack setter make the duk_def_prop() call automatically so that writing to these properties will seem to work as if the property was not an inherited accessor. This matches how e.g. V8 and Spidermonkey work, and also matches how Duktape works when tracebacks are disabled and .fileName and .lineNumber are concrete own properties.
9 years ago
}