When appending two strings together to form a new string, if both of the
strings are already UTF-16, create the new string as UTF-16 as well.
This shaves about 0.5 seconds off the following test262 test:
RegExp/property-escapes/generated/General_Category_-_Decimal_Number.js
The test262 tests under RegExp/property-escapes/generated will invoke
Reflect.apply with up to 10,000 arguments at a time. In LibJS, when the
call stack reached VM::call_internal, we transfer those arguments from
a MarkedValueList to the execution context's arguments Vector.
Because these types differ (MarkedValueList is a Vector<Value, 32>), the
arguments are copied rather than moved. By changing the arguments vector
to a MarkedValueList, we can properly move the passed arguments over.
This shaves about 2 seconds off the following test262 test (from 15sec):
RegExp/property-escapes/generated/General_Category_-_Decimal_Number.js
In addition to invoking js_string() with existing UTF-16 strings when
possible, RegExpExec now takes a Utf16String instead of a Utf16View. The
view was previously fully copied into the returned result object, so
this prevents potentially large copies of string data.
The primary themes here are invoking js_string() with existing instances
of Utf16String when possible, and not creating entire UTF-8 copies when
not needed.
This commit does not go out of its way to reduce copying of the string
data yet, but is a minimum set of changes to compile LibJS after making
PrimitiveString hold a Utf16String.
To help alleviate memory usage when creating and copying large strings,
create a simple wrapper around a Vector<u16> to reference count UTF-16
strings.
This is a tiny difference and only changes anything for primitives in
strict mode. However this is tested in test262 and can be noticed by
overriding toString of primitive values.
This does now require one to wrap an object in a Value to call invoke
but all code using invoke has been migrated.
Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate:
- Forward declarations
- CommonPropertyNames class name members
- Constructor and prototype GlobalObject members, getters, visitors,
and initialize_constructor() calls
This is the start of implementing ECMA-402 in LibJS, better known as the
ECMAScript Internationalization API.
Much like Temporal this gets its own subdirectory (Runtime/Intl/) as
well as a new C++ namespace (JS::Intl) so we don't have to prefix all
the files and classes with "Intl".
https://tc39.es/ecma402/
This commit adds the PlainYearMonth object itself, its constructor and
prototype (currently empty), and the CreateTemporalYearMonth and
ISOYearMonthWithinLimits abstract operations.
Although this is not spec-compliant, we don't have a way to represent
objects larger than `NumericLimits<size_t>::max()`. Since this abstract
operation is only used when dealing with object size, we don't lose any
functionality by taking that limit into account too.
This fixes a UBSAN error when compiling with Clang.
If we call these two functions on a negative value, undefined behavior
occurs due to casting a negative double to an unsigned integer. These
functions are defined to perform modular arithmetic, so negative values
can be fixed up by adding 2^8/2^16.
The reason why this step is not mentioned in ECMA-262 is that it defines
modular arithmetic so that `x mod m` had the same sign as `m`, while
LibM's `fmod(x, m)` copies `x`'s sign.
This issue was found by UBSAN with the Clang toolchain.
Casting a floating point number to an integer and comparing that against
the original value is not a good way to test if it is a whole number. It
may cause unnecessary narrowing conversion issues and UB. This was the
case, which was caught be Clang's `-fsanitize=float-cast-overflow`.
This commit changes the code to use `is_integral_number`, as suggested
in ECMA-262.
If the argument to this function is greater then or equal to 2^32, the
`double` => `u32` cast produces undefined behavior, which Clang catches.
To fix this, we now use `ToUint32` for getting the integer argument, as
specified by ECMA-262.
length is size_t as returned, and so subtracting from it may cause
underflow. We handle this case by just casting it to a signed value, and
the for loop predicate takes care of the rest.
