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

173 lines
4.5 KiB
Raw Normal View History

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
/*
* Symbol built-in
*/
#include "duk_internal.h"
#if defined(DUK_USE_SYMBOL_BUILTIN)
/*
* Constructor
*/
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_symbol_constructor_shared(duk_hthread *thr) {
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 duk_uint8_t *desc;
duk_size_t len;
duk_uint8_t *buf;
duk_uint8_t *p;
duk_int_t magic;
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> 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
magic = duk_get_current_magic(thr);
if (duk_is_undefined(thr, 0) && (magic == 0)) {
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
/* Symbol() accepts undefined and empty string, but they are
* treated differently.
*/
desc = NULL;
len = 0;
} else {
/* Symbol.for() coerces undefined to '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
desc = (const duk_uint8_t *) duk_to_lstring(thr, 0, &len);
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
}
/* Maximum symbol data length:
* +1 initial byte (0x80 or 0x81)
* +len description
* +1 0xff after description, before unique suffix
* +17 autogenerated unique suffix: 'ffffffff-ffffffff' is longest
* +1 0xff after unique suffix for symbols with undefined description
*/
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
buf = (duk_uint8_t *) duk_push_fixed_buffer(thr, 1 + len + 1 + 17 + 1);
Further cleanup for memory helpers * Convert memory helpers like duk_memcmp() to macros where possible: for some reason automatic inlining with -Os doesn't do the right thing and the footprint impact is over 1kB. The duk_memcmp() helper is an inlined function because it returns a value and assertions would otherwise lead to multiple evaluation of arguments. * Differentiate between C99+ and "unsafe" call sites. For example, use duk_memcpy() when the call site obeys C99+ restrictions, and duk_memcpy_unsafe() when either pointer may be NULL when the size is zero. Same for all helpers.
7 years ago
DUK_ASSERT(buf != NULL);
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
p = buf + 1;
Reformat some source files with clang-format
3 years ago
DUK_ASSERT(desc != NULL || len == 0); /* may be NULL if len is 0 */
Further cleanup for memory helpers * Convert memory helpers like duk_memcmp() to macros where possible: for some reason automatic inlining with -Os doesn't do the right thing and the footprint impact is over 1kB. The duk_memcmp() helper is an inlined function because it returns a value and assertions would otherwise lead to multiple evaluation of arguments. * Differentiate between C99+ and "unsafe" call sites. For example, use duk_memcpy() when the call site obeys C99+ restrictions, and duk_memcpy_unsafe() when either pointer may be NULL when the size is zero. Same for all helpers.
7 years ago
duk_memcpy_unsafe((void *) p, (const void *) desc, len);
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
p += len;
if (magic == 0) {
/* Symbol(): create unique symbol. Use two 32-bit values
* to avoid dependency on 64-bit types and 64-bit integer
* formatting (at least for now).
*/
if (++thr->heap->sym_counter[0] == 0) {
thr->heap->sym_counter[1]++;
}
Reformat some source files with clang-format
3 years ago
p += DUK_SPRINTF((char *) p,
"\xFF"
"%lx-%lx",
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
(unsigned long) thr->heap->sym_counter[1],
(unsigned long) thr->heap->sym_counter[0]);
if (desc == NULL) {
/* Special case for 'undefined' description, trailing
* 0xff distinguishes from empty string description,
* but needs minimal special case handling elsewhere.
*/
*p++ = 0xff;
}
buf[0] = 0x81;
} else {
/* Symbol.for(): create a global symbol */
buf[0] = 0x80;
}
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_lstring(thr, (const char *) buf, (duk_size_t) (p - buf));
DUK_DDD(DUK_DDDPRINT("created symbol: %!T", duk_get_tval(thr, -1)));
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
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_LOCAL duk_hstring *duk__auto_unbox_symbol(duk_hthread *thr, duk_tval *tv_arg) {
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
duk_tval *tv;
duk_hobject *h_obj;
duk_hstring *h_str;
DUK_ASSERT(tv_arg != 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
/* XXX: add internal helper: duk_auto_unbox_tval(thr, tv, mask); */
/* XXX: add internal helper: duk_auto_unbox(thr, tv, idx); */
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
tv = tv_arg;
if (DUK_TVAL_IS_OBJECT(tv)) {
h_obj = DUK_TVAL_GET_OBJECT(tv);
DUK_ASSERT(h_obj != NULL);
Source changes for property code switch
3 years ago
if (DUK_HOBJECT_GET_HTYPE(h_obj) == DUK_HTYPE_SYMBOL_OBJECT) {
Internal property handling fixes * Rename hobject helper functions for property entry access. * Add helpers for looking up _Formals and _Varmap without inheritance. * Add duk_xget_owndataprop() + variants for internal property lookups without inheritance or side effects. * Date built-in fix for .setTime(), .setYear(), etc on a frozen Date instance. These should be allowed because they operate on an internal slot which is not under normal property access control. Previously the operations were incorrectly rejected with a TypeError. * Changes to internal property definition and lookup here and there. Mostly the changes should be no-op because e.g. inheritance only matters if the internal property might be missing (which is not usually the case).
5 years ago
tv = duk_hobject_get_internal_value_tval_ptr(thr->heap, h_obj);
if (tv == NULL) {
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
return NULL;
}
} else {
return NULL;
}
}
if (!DUK_TVAL_IS_STRING(tv)) {
return NULL;
}
h_str = DUK_TVAL_GET_STRING(tv);
DUK_ASSERT(h_str != NULL);
Make symbol checks unlikely Usually symbol checks are in code paths expecting a string; make these unlikely. For code paths where a symbol is expected, make the check likely.
8 years ago
/* Here symbol is more expected than not. */
if (DUK_UNLIKELY(!DUK_HSTRING_HAS_SYMBOL(h_str))) {
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
return NULL;
}
return h_str;
}
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_symbol_tostring_shared(duk_hthread *thr) {
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
duk_hstring *h_str;
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_str = duk__auto_unbox_symbol(thr, DUK_HTHREAD_THIS_PTR(thr));
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
if (h_str == NULL) {
return DUK_RET_TYPE_ERROR;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> 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_current_magic(thr) == 0) {
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
/* .toString() */
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_symbol_descriptive_string(thr, h_str);
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
} else {
/* .valueOf() */
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(thr, h_str);
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
}
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_symbol_key_for(duk_hthread *thr) {
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
duk_hstring *h;
const duk_uint8_t *p;
/* Argument must be a symbol but not checked here. The initial byte
* check will catch non-symbol strings.
*/
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 = duk_require_hstring(thr, 0);
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
DUK_ASSERT(h != NULL);
Add explicit string char access helpers Isolate all char-offset-to-byte-offset and character access calls behind helpers to help prepare for a switch to WTF-8 representation. This change should have no visible effect yet.
4 years ago
p = (const duk_uint8_t *) duk_hstring_get_data(h);
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
DUK_ASSERT(p != NULL);
/* Even for zero length strings there's at least one NUL byte so
* we can safely check the initial byte.
*/
if (p[0] == 0x80) {
/* Global symbol, return its key (bytes just after the initial byte). */
Add explicit string char access helpers Isolate all char-offset-to-byte-offset and character access calls behind helpers to help prepare for a switch to WTF-8 representation. This change should have no visible effect yet.
4 years ago
duk_push_lstring(thr, (const char *) (p + 1), (duk_size_t) (duk_hstring_get_bytelen(h) - 1));
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
return 1;
Use 0x82 prefix for Duktape internal symbols
7 years ago
} else if (p[0] == 0x81 || p[0] == 0x82 || p[0] == 0xff) {
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
/* Local symbol or hidden symbol, return undefined. */
return 0;
}
/* Covers normal strings and unknown initial bytes. */
return DUK_RET_TYPE_ERROR;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> 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_symbol_toprimitive(duk_hthread *thr) {
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
duk_hstring *h_str;
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_str = duk__auto_unbox_symbol(thr, DUK_HTHREAD_THIS_PTR(thr));
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
if (h_str == NULL) {
return DUK_RET_TYPE_ERROR;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> 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(thr, h_str);
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
return 1;
}
Reformat some source files with clang-format
3 years ago
#endif /* DUK_USE_SYMBOL_BUILTIN */