Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/Value.cpp

1660 lines
58 KiB
C++
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
LibJS: Use __builtin_isnan in static_assert instead of isnan For the fuzzer build isnan was not usable in a constexpr context however __builtin_isnan seems to always be. Also while we're here add my name to the copyright since I forgot after the Value rewrite.
2022-08-23 20:24:59 +02:00
* Copyright (c) 2022, David Tuin <davidot@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*/
LibJS: Use all_of() in JS::Value's BigInt validation
2021-02-17 11:18:51 +01:00
#include <AK/AllOf.h>
LibJS: Unify exponentiation logic for ** operator and Math.pow The JS behaviour of exponentiation on two number typed values is not a simple matter of forwarding to ::pow(double, double). So, this factors out the Math.pow logic to allow it to be shared with Value::exp.
2022-02-17 11:52:45 -08:00
#include <AK/Assertions.h>
LibJS: Implement conversion of strings to BigInts according to the spec The spec defines a StringToBigInt AO which allows for converting binary, octal, decimal, and hexadecimal strings to a BigInt. Our conversion was only allowing for decimal strings.
2022-01-31 10:23:51 -05:00
#include <AK/CharacterTypes.h>
LibJS: Make string_to_double use the new double parser
2022-10-12 02:23:50 +02:00
#include <AK/FloatingPointStringConversions.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
#include <AK/String.h>
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
#include <AK/StringBuilder.h>
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
#include <AK/Utf8View.h>
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
#include <LibCrypto/BigInt/SignedBigInteger.h>
#include <LibCrypto/NumberTheory/ModularFunctions.h>
Everywhere: Convert VM::call() to JS::call()
2022-01-23 02:12:26 -07:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
#include <LibJS/Runtime/Accessor.h>
LibJS: Handle empty strings and arrays in Value::to_number() - An empty string is converted to 0 - An empty array is converted to 0 - An array with one item is converted to that item's numeric value - An array with more than one item is converted to NaN
2020-03-29 15:20:09 +01:00
#include <LibJS/Runtime/Array.h>
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
#include <LibJS/Runtime/BigInt.h>
#include <LibJS/Runtime/BigIntObject.h>
LibJS: Add Boolean constructor object
2020-04-06 22:51:16 -05:00
#include <LibJS/Runtime/BooleanObject.h>
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
#include <LibJS/Runtime/BoundFunction.h>
LibJS: Convert to_string() to ThrowCompletionOr Also update get_function_name() to use ThrowCompletionOr, but this is not a standard AO and should be refactored out of existence eventually.
2021-10-12 17:49:01 +01:00
#include <LibJS/Runtime/Completion.h>
LibJS: Rework how native functions are called to improve |this| value Native functions now only get the Interpreter& as an argument. They can then extract |this| along with any indexed arguments it wants from it. This forces functions that want |this| to actually deal with calling interpreter.this_value().to_object(), and dealing with the possibility of a non-object |this|. This is still not great but let's keep massaging it forward.
2020-03-28 22:48:35 +01:00
#include <LibJS/Runtime/Error.h>
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
#include <LibJS/Runtime/FunctionObject.h>
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
#include <LibJS/Runtime/NativeFunction.h>
LibJS: Add NumberObject and make to_object() on number values create it
2020-04-04 23:13:13 +02:00
#include <LibJS/Runtime/NumberObject.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Object.h>
#include <LibJS/Runtime/PrimitiveString.h>
LibJS: Handle Proxy with Array target in IsArray() abstract operation This was missing from Value::is_array(), which is equivalent to the spec's IsArray() abstract operation - it treats a Proxy value with an Array target object as being an Array. It can throw, so needs both the global object and an exception check now.
2021-06-08 21:53:36 +01:00
#include <LibJS/Runtime/ProxyObject.h>
LibJS: Remove hand-rolled Object is_foo() helpers in favor of RTTI
2021-01-01 17:46:39 +01:00
#include <LibJS/Runtime/RegExpObject.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/StringObject.h>
LibJS: Trim all types of whitespace characters before parsing numbers
2022-02-19 22:47:05 +02:00
#include <LibJS/Runtime/StringPrototype.h>
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
#include <LibJS/Runtime/SymbolObject.h>
LibJS: Move Object::invoke to Value::invoke and fix it for primitives 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.
2021-08-09 16:45:43 +02:00
#include <LibJS/Runtime/VM.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.h>
LibJS: Implement exponentiation (** operator)
2020-04-05 13:40:00 +01:00
#include <math.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
namespace JS {
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
static inline bool same_type_for_equality(Value const& lhs, Value const& rhs)
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
// If the top two bytes are identical then either:
// both are NaN boxed Values with the same type
// or they are doubles which happen to have the same top bytes.
if ((lhs.encoded() & TAG_EXTRACTION) == (rhs.encoded() & TAG_EXTRACTION))
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
return true;
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
if (lhs.is_number() && rhs.is_number())
return true;
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
// One of the Values is not a number and they do not have the same tag
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
return false;
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
static const Crypto::SignedBigInteger BIGINT_ZERO { 0 };
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
ALWAYS_INLINE bool both_number(Value const& lhs, Value const& rhs)
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
{
return lhs.is_number() && rhs.is_number();
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
ALWAYS_INLINE bool both_bigint(Value const& lhs, Value const& rhs)
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
{
return lhs.is_bigint() && rhs.is_bigint();
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 6.1.6.1.20 Number::toString ( x ), https://tc39.es/ecma262/#sec-numeric-types-number-tostring
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
static String double_to_string(double d)
{
if (isnan(d))
return "NaN";
if (d == +0.0 || d == -0.0)
return "0";
if (d < +0.0) {
StringBuilder builder;
builder.append('-');
builder.append(double_to_string(-d));
return builder.to_string();
}
LibM: Fix INFITITY to float POSIX mandates it.
2021-04-26 19:11:11 +02:00
if (d == static_cast<double>(INFINITY))
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
return "Infinity";
StringBuilder number_string_builder;
size_t start_index = 0;
size_t end_index = 0;
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
size_t int_part_end = 0;
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
// generate integer part (reversed)
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
double int_part;
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
double frac_part;
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
frac_part = modf(d, &int_part);
while (int_part > 0) {
number_string_builder.append('0' + (int)fmod(int_part, 10));
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
end_index++;
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
int_part = floor(int_part / 10);
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
}
auto reversed_integer_part = number_string_builder.to_string().reverse();
number_string_builder.clear();
number_string_builder.append(reversed_integer_part);
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
int_part_end = end_index;
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
int exponent = 0;
// generate fractional part
while (frac_part > 0) {
double old_frac_part = frac_part;
frac_part *= 10;
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
frac_part = modf(frac_part, &int_part);
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
if (old_frac_part == frac_part)
break;
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
number_string_builder.append('0' + (int)int_part);
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
end_index++;
exponent--;
}
auto number_string = number_string_builder.to_string();
LibJS: Fix old object numeric key test now that toString() is correct
2020-12-27 01:27:10 +01:00
// FIXME: Remove this hack.
// FIXME: Instead find the shortest round-trippable representation.
// Remove decimals after the 15th position
LibJS: Fix variable name coding style int{Part => _part} ...and rename intpart_end to int_part_end for consistency.
2021-02-01 20:29:11 +01:00
if (end_index > int_part_end + 15) {
exponent += end_index - int_part_end - 15;
end_index = int_part_end + 15;
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
}
// remove leading zeroes
while (start_index < end_index && number_string[start_index] == '0') {
start_index++;
}
// remove trailing zeroes
while (end_index > 0 && number_string[end_index - 1] == '0') {
end_index--;
exponent++;
}
if (end_index <= start_index)
return "0";
auto digits = number_string.substring_view(start_index, end_index - start_index);
int number_of_digits = end_index - start_index;
exponent += number_of_digits;
StringBuilder builder;
if (number_of_digits <= exponent && exponent <= 21) {
builder.append(digits);
builder.append(String::repeated('0', exponent - number_of_digits));
return builder.to_string();
}
if (0 < exponent && exponent <= 21) {
builder.append(digits.substring_view(0, exponent));
builder.append('.');
builder.append(digits.substring_view(exponent));
return builder.to_string();
}
if (-6 < exponent && exponent <= 0) {
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
builder.append("0."sv);
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
builder.append(String::repeated('0', -exponent));
builder.append(digits);
return builder.to_string();
}
if (number_of_digits == 1) {
builder.append(digits);
builder.append('e');
if (exponent - 1 > 0)
builder.append('+');
else
builder.append('-');
AK+Userland: Add generic `AK::abs()` function and use it Previously, in LibGFX's `Point` class, calculated distances were passed to the integer `abs` function, even if the stored type was a float. This caused the value to unexpectedly be truncated. Luckily, this API was not used with floating point types, but that can change in the future, so why not fix it now :^) Since we are in C++, we can use function overloading to make things easy, and to automatically use the right version. This is even better than the LibC/LibM functions, as using a bit of hackery, they are able to be constant-evaluated. They use compiler intrinsics, so they do not depend on external code and the compiler can emit the most optimized code by default. Since we aren't using the C++ standard library's trick of importing everything into the `AK` namespace, this `abs` function cannot be exported to the global namespace, as the names would clash.
2021-07-05 18:38:17 +02:00
builder.append(String::number(AK::abs(exponent - 1)));
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
return builder.to_string();
}
builder.append(digits[0]);
builder.append('.');
builder.append(digits.substring_view(1));
builder.append('e');
if (exponent - 1 > 0)
builder.append('+');
else
builder.append('-');
AK+Userland: Add generic `AK::abs()` function and use it Previously, in LibGFX's `Point` class, calculated distances were passed to the integer `abs` function, even if the stored type was a float. This caused the value to unexpectedly be truncated. Luckily, this API was not used with floating point types, but that can change in the future, so why not fix it now :^) Since we are in C++, we can use function overloading to make things easy, and to automatically use the right version. This is even better than the LibC/LibM functions, as using a bit of hackery, they are able to be constant-evaluated. They use compiler intrinsics, so they do not depend on external code and the compiler can emit the most optimized code by default. Since we aren't using the C++ standard library's trick of importing everything into the `AK` namespace, this `abs` function cannot be exported to the global namespace, as the names would clash.
2021-07-05 18:38:17 +02:00
builder.append(String::number(AK::abs(exponent - 1)));
LibJS: Implement (mostly) spec compliant version of Number.toString()
2020-12-26 11:30:14 +01:00
return builder.to_string();
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.2 IsArray ( argument ), https://tc39.es/ecma262/#sec-isarray
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<bool> Value::is_array(VM& vm) const
LibJS: Add Value::is_array()
2020-03-26 12:02:18 +01:00
{
LibJS: Handle Proxy with Array target in IsArray() abstract operation This was missing from Value::is_array(), which is equivalent to the spec's IsArray() abstract operation - it treats a Proxy value with an Array target object as being an Array. It can throw, so needs both the global object and an exception check now.
2021-06-08 21:53:36 +01:00
if (!is_object())
return false;
auto& object = as_object();
LibJS: Remove Object::is_array() in favor of Value::is_array() and RTTI It's way too easy to get this wrong: for the IsArray abstract operation, Value::is_array() needs to be called. Since we have RTTI, the virtual Object::is_array() method is not needed anymore - if we need to know whether something is *actually* a JS::Array (we currently check in more cases than we should, I think) and not a Proxy with an Array target, we should do that in a way that doesn't look like an abstract operation.
2021-07-05 18:58:51 +01:00
if (is<Array>(object))
LibJS: Handle Proxy with Array target in IsArray() abstract operation This was missing from Value::is_array(), which is equivalent to the spec's IsArray() abstract operation - it treats a Proxy value with an Array target object as being an Array. It can throw, so needs both the global object and an exception check now.
2021-06-08 21:53:36 +01:00
return true;
if (is<ProxyObject>(object)) {
auto& proxy = static_cast<ProxyObject const&>(object);
LibJS: Switch is_array to ThrowCompletionOr
2021-09-23 20:05:34 +03:00
if (proxy.is_revoked())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::ProxyRevoked);
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return Value(&proxy.target()).is_array(vm);
LibJS: Handle Proxy with Array target in IsArray() abstract operation This was missing from Value::is_array(), which is equivalent to the spec's IsArray() abstract operation - it treats a Proxy value with an Array target object as being an Array. It can throw, so needs both the global object and an exception check now.
2021-06-08 21:53:36 +01:00
}
return false;
LibJS: Add Value::is_array()
2020-03-26 12:02:18 +01:00
}
LibJS: Add JSON.stringify
2020-06-10 11:01:00 -07:00
Array& Value::as_array()
{
LibJS: Remove Object::is_array() in favor of Value::is_array() and RTTI It's way too easy to get this wrong: for the IsArray abstract operation, Value::is_array() needs to be called. Since we have RTTI, the virtual Object::is_array() method is not needed anymore - if we need to know whether something is *actually* a JS::Array (we currently check in more cases than we should, I think) and not a Proxy with an Array target, we should do that in a way that doesn't look like an abstract operation.
2021-07-05 18:58:51 +01:00
VERIFY(is_object() && is<Array>(as_object()));
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
return static_cast<Array&>(as_object());
LibJS: Add JSON.stringify
2020-06-10 11:01:00 -07:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.3 IsCallable ( argument ), https://tc39.es/ecma262/#sec-iscallable
LibJS: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
bool Value::is_function() const
{
return is_object() && as_object().is_function();
}
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
FunctionObject& Value::as_function()
LibJS: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(is_function());
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
return static_cast<FunctionObject&>(as_object());
LibJS: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
}
LibJS: Add const Value::as_function()
2021-09-25 09:43:34 +02:00
FunctionObject const& Value::as_function() const
{
VERIFY(is_function());
return static_cast<FunctionObject const&>(as_object());
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.4 IsConstructor ( argument ), https://tc39.es/ecma262/#sec-isconstructor
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
bool Value::is_constructor() const
LibJS: Implement IsRegExp abstract operation This is needed by various String.prototype operations, as well as the RegExp constructor.
2020-12-25 12:52:19 +11:00
{
LibJS: Move has_constructor() from NativeFunction to FunctionObject At a later point this will indicate whether some FunctionObject "has a [[Construct]] internal method" (separate from the current FunctionObject call() / construct()), to help with a more spec-compliant implementation of [[Call]] and [[Construct]]. This means that it is no longer relevant to just NativeFunction.
2021-09-25 09:52:49 +02:00
// 1. If Type(argument) is not Object, return false.
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
if (!is_function())
return false;
LibJS: Move has_constructor() from NativeFunction to FunctionObject At a later point this will indicate whether some FunctionObject "has a [[Construct]] internal method" (separate from the current FunctionObject call() / construct()), to help with a more spec-compliant implementation of [[Call]] and [[Construct]]. This means that it is no longer relevant to just NativeFunction.
2021-09-25 09:52:49 +02:00
// 2. If argument has a [[Construct]] internal method, return true.
if (as_function().has_constructor())
return true;
// 3. Return false.
return false;
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
}
LibJS: Implement IsRegExp abstract operation This is needed by various String.prototype operations, as well as the RegExp constructor.
2020-12-25 12:52:19 +11:00
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.8 IsRegExp ( argument ), https://tc39.es/ecma262/#sec-isregexp
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<bool> Value::is_regexp(VM& vm) const
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
{
LibJS: Implement IsRegExp abstract operation This is needed by various String.prototype operations, as well as the RegExp constructor.
2020-12-25 12:52:19 +11:00
if (!is_object())
return false;
LibJS: Convert Object::get() to ThrowCompletionOr To no one's surprise, this patch is pretty big - this is possibly the most used AO of all of them. Definitely worth it though.
2021-10-02 23:52:27 +01:00
auto matcher = TRY(as_object().get(*vm.well_known_symbol_match()));
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
if (!matcher.is_undefined())
LibJS: Implement IsRegExp abstract operation This is needed by various String.prototype operations, as well as the RegExp constructor.
2020-12-25 12:52:19 +11:00
return matcher.to_boolean();
LibJS: Remove hand-rolled Object is_foo() helpers in favor of RTTI
2021-01-01 17:46:39 +01:00
return is<RegExpObject>(as_object());
LibJS: Implement IsRegExp abstract operation This is needed by various String.prototype operations, as well as the RegExp constructor.
2020-12-25 12:52:19 +11:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.5.3 The typeof Operator, https://tc39.es/ecma262/#sec-typeof-operator
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
String Value::typeof() const
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (is_number())
return "number";
switch (m_value.tag) {
case UNDEFINED_TAG:
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
return "undefined";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case NULL_TAG:
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
return "object";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case STRING_TAG:
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
return "string";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case OBJECT_TAG:
LibJS: Implement support for the [[IsHTMLDDA]] internal slot Best regards from Annex B and document.all :^)
2021-06-20 17:08:29 +01:00
// B.3.7.3 Changes to the typeof Operator, https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot-typeof
if (as_object().is_htmldda())
return "undefined";
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
if (is_function())
return "function";
return "object";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BOOLEAN_TAG:
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
return "boolean";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case SYMBOL_TAG:
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
return "symbol";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BIGINT_TAG:
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
return "bigint";
default:
VERIFY_NOT_REACHED();
}
}
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
String Value::to_string_without_side_effects() const
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (is_double())
return double_to_string(m_value.as_double);
switch (m_value.tag) {
case UNDEFINED_TAG:
LibJS: Fix string representation for value of type undefined
2020-03-07 23:11:17 +01:00
return "undefined";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case NULL_TAG:
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
return "null";
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BOOLEAN_TAG:
return as_bool() ? "true" : "false";
case INT32_TAG:
return String::number(as_i32());
case STRING_TAG:
return as_string().string();
case SYMBOL_TAG:
return as_symbol().to_string();
case BIGINT_TAG:
return as_bigint().to_string();
case OBJECT_TAG:
LibJS: Use string::formatted() in to_string() functions
2020-10-04 15:18:12 +01:00
return String::formatted("[object {}]", as_object().class_name());
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case ACCESSOR_TAG:
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return "<accessor>";
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
default:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
}
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<PrimitiveString*> Value::to_primitive_string(VM& vm)
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
{
if (is_string())
return &as_string();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto string = TRY(to_string(vm));
return js_string(vm, string);
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.17 ToString ( argument ), https://tc39.es/ecma262/#sec-tostring
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<String> Value::to_string(VM& vm) const
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (is_double())
return double_to_string(m_value.as_double);
switch (m_value.tag) {
case UNDEFINED_TAG:
LibJS: Use implicit ThrowCompletionOr<T> constructor where possible Luckily this is not very widespread yet as most of it would happen in the various JS functions instead of AOs.
2021-10-20 19:17:45 +01:00
return "undefined"sv;
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case NULL_TAG:
LibJS: Use implicit ThrowCompletionOr<T> constructor where possible Luckily this is not very widespread yet as most of it would happen in the various JS functions instead of AOs.
2021-10-20 19:17:45 +01:00
return "null"sv;
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BOOLEAN_TAG:
return as_bool() ? "true"sv : "false"sv;
case INT32_TAG:
return String::number(as_i32());
case STRING_TAG:
return as_string().string();
case SYMBOL_TAG:
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::Convert, "symbol", "string");
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BIGINT_TAG:
return as_bigint().big_integer().to_base(10);
case OBJECT_TAG: {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto primitive_value = TRY(to_primitive(vm, PreferredType::String));
return primitive_value.to_string(vm);
LibJS: Throw error in Object::to_string() if string conversion fails
2020-04-29 16:29:26 +01:00
}
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
default:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Utf16String> Value::to_utf16_string(VM& vm) const
LibJS: Transcode UTF-8 strings to UTF-16 and add UTF-16 accessors LibJS parses JavaScript as UTF-8, so when creating a string, we must transcode it to UTF-16 to handle encoded surrogate pairs. For example, consider the following string: "\ud83d\ude00" The UTF-8 encoding of this surrogate pair is: 0xf0 0x9f 0x98 0x80 However, LibJS will currently store the two surrogates individually as UTF-8 encoded bytes, rather than combining the pair: 0xed 0xa0 0xb8, 0xed 0xb8 0x80 These are not equivalent. So, as String.prototype becomes UTF-16 aware, this encoding will no longer work for abstractions like strict equality.
2021-07-20 10:46:53 -04:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (is_string())
return as_string().utf16_string();
LibJS: Transcode UTF-8 strings to UTF-16 and add UTF-16 accessors LibJS parses JavaScript as UTF-8, so when creating a string, we must transcode it to UTF-16 to handle encoded surrogate pairs. For example, consider the following string: "\ud83d\ude00" The UTF-8 encoding of this surrogate pair is: 0xf0 0x9f 0x98 0x80 However, LibJS will currently store the two surrogates individually as UTF-8 encoded bytes, rather than combining the pair: 0xed 0xa0 0xb8, 0xed 0xb8 0x80 These are not equivalent. So, as String.prototype becomes UTF-16 aware, this encoding will no longer work for abstractions like strict equality.
2021-07-20 10:46:53 -04:00
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto utf8_string = TRY(to_string(vm));
LibJS: Replace Vector<u16> usage in PrimitiveString wth Utf16String 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.
2021-08-09 09:06:45 -04:00
return Utf16String(utf8_string);
LibJS: Transcode UTF-8 strings to UTF-16 and add UTF-16 accessors LibJS parses JavaScript as UTF-8, so when creating a string, we must transcode it to UTF-16 to handle encoded surrogate pairs. For example, consider the following string: "\ud83d\ude00" The UTF-8 encoding of this surrogate pair is: 0xf0 0x9f 0x98 0x80 However, LibJS will currently store the two surrogates individually as UTF-8 encoded bytes, rather than combining the pair: 0xed 0xa0 0xb8, 0xed 0xb8 0x80 These are not equivalent. So, as String.prototype becomes UTF-16 aware, this encoding will no longer work for abstractions like strict equality.
2021-07-20 10:46:53 -04:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.2 ToBoolean ( argument ), https://tc39.es/ecma262/#sec-toboolean
LibJS: Implement basic boolean coercion We can't expect the conditionals in "if" and "while" statements to always return a bool, so we need to know how to boolify a JS::Value.
2020-03-10 08:46:20 +01:00
bool Value::to_boolean() const
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (is_double()) {
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
if (is_nan())
LibJS: Return false for NaN numbers in Value::to_boolean()
2020-04-06 22:48:47 -05:00
return false;
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
return m_value.as_double != 0;
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
}
switch (m_value.tag) {
case UNDEFINED_TAG:
case NULL_TAG:
return false;
case BOOLEAN_TAG:
return as_bool();
case INT32_TAG:
return as_i32() != 0;
case STRING_TAG:
return !as_string().is_empty();
case SYMBOL_TAG:
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return true;
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BIGINT_TAG:
return as_bigint().big_integer() != BIGINT_ZERO;
case OBJECT_TAG:
LibJS: Implement support for the [[IsHTMLDDA]] internal slot Best regards from Annex B and document.all :^)
2021-06-20 17:08:29 +01:00
// B.3.7.1 Changes to ToBoolean, https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot-to-boolean
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (as_object().is_htmldda())
LibJS: Implement support for the [[IsHTMLDDA]] internal slot Best regards from Annex B and document.all :^)
2021-06-20 17:08:29 +01:00
return false;
LibJS: Implement basic boolean coercion We can't expect the conditionals in "if" and "while" statements to always return a bool, so we need to know how to boolify a JS::Value.
2020-03-10 08:46:20 +01:00
return true;
default:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement basic boolean coercion We can't expect the conditionals in "if" and "while" statements to always return a bool, so we need to know how to boolify a JS::Value.
2020-03-10 08:46:20 +01:00
}
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.1 ToPrimitive ( input [ , preferredType ] ), https://tc39.es/ecma262/#sec-toprimitive
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> Value::to_primitive(VM& vm, PreferredType preferred_type) const
LibJS: Adding two values should convert them to primitives first
2020-04-15 09:32:44 +02:00
{
LibJS: Support @@toPrimitive in ToPrimitive abstract operation Fixes #3961.
2021-03-02 19:22:36 +01:00
auto get_hint_for_preferred_type = [&]() -> String {
switch (preferred_type) {
case PreferredType::Default:
return "default";
case PreferredType::String:
return "string";
case PreferredType::Number:
return "number";
default:
VERIFY_NOT_REACHED();
}
};
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
if (is_object()) {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto to_primitive_method = TRY(get_method(vm, *vm.well_known_symbol_to_primitive()));
LibJS: Support @@toPrimitive in ToPrimitive abstract operation Fixes #3961.
2021-03-02 19:22:36 +01:00
if (to_primitive_method) {
auto hint = get_hint_for_preferred_type();
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 19:24:32 +01:00
auto result = TRY(call(vm, *to_primitive_method, *this, js_string(vm, hint)));
LibJS: Support @@toPrimitive in ToPrimitive abstract operation Fixes #3961.
2021-03-02 19:22:36 +01:00
if (!result.is_object())
return result;
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::ToPrimitiveReturnedObject, to_string_without_side_effects(), hint);
LibJS: Support @@toPrimitive in ToPrimitive abstract operation Fixes #3961.
2021-03-02 19:22:36 +01:00
}
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
if (preferred_type == PreferredType::Default)
preferred_type = PreferredType::Number;
LibJS: Convert to_primitive() to ThrowCompletionOr
2021-10-12 18:09:14 +01:00
return as_object().ordinary_to_primitive(preferred_type);
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
}
LibJS: Adding two values should convert them to primitives first
2020-04-15 09:32:44 +02:00
return *this;
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.18 ToObject ( argument ), https://tc39.es/ecma262/#sec-toobject
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Object*> Value::to_object(VM& vm) const
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto& realm = *vm.current_realm();
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
VERIFY(!is_empty());
if (is_number())
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
return NumberObject::create(realm, as_double());
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
switch (m_value.tag) {
case UNDEFINED_TAG:
case NULL_TAG:
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return vm.throw_completion<TypeError>(ErrorType::ToObjectNullOrUndefined);
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BOOLEAN_TAG:
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
return BooleanObject::create(realm, as_bool());
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case STRING_TAG:
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
return StringObject::create(realm, const_cast<JS::PrimitiveString&>(as_string()), *realm.intrinsics().string_prototype());
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case SYMBOL_TAG:
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
return SymbolObject::create(realm, const_cast<JS::Symbol&>(as_symbol()));
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BIGINT_TAG:
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
return BigIntObject::create(realm, const_cast<JS::BigInt&>(as_bigint()));
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case OBJECT_TAG:
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
return &const_cast<Object&>(as_object());
default:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Rework how native functions are called to improve |this| value Native functions now only get the Interpreter& as an argument. They can then extract |this| along with any indexed arguments it wants from it. This forces functions that want |this| to actually deal with calling interpreter.this_value().to_object(), and dealing with the possibility of a non-object |this|. This is still not great but let's keep massaging it forward.
2020-03-28 22:48:35 +01:00
}
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.3 ToNumeric ( value ), https://tc39.es/ecma262/#sec-tonumeric
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
FLATTEN ThrowCompletionOr<Value> Value::to_numeric(VM& vm) const
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto primitive = TRY(to_primitive(vm, Value::PreferredType::Number));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (primitive.is_bigint())
return primitive;
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return primitive.to_number(vm);
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Handle non-decimal integer literals in Value::to_number Implements support for parsing binary and octal literals, and fixes instances where a hex literal is parsed in ways the spec doesn't allow.
2022-08-26 11:14:04 -05:00
constexpr bool is_ascii_number(u32 code_point)
{
return is_ascii_digit(code_point) || code_point == '.' || (code_point == 'e' || code_point == 'E') || code_point == '+' || code_point == '-';
}
struct NumberParseResult {
StringView literal;
u8 base;
};
static Optional<NumberParseResult> parse_number_text(StringView text)
{
NumberParseResult result {};
auto check_prefix = [&](auto lower_prefix, auto upper_prefix) {
if (text.length() <= 2)
return false;
if (!text.starts_with(lower_prefix) && !text.starts_with(upper_prefix))
return false;
return true;
};
// https://tc39.es/ecma262/#sec-tonumber-applied-to-the-string-type
if (check_prefix("0b"sv, "0B"sv)) {
if (!all_of(text.substring_view(2), is_ascii_binary_digit))
return {};
result.literal = text.substring_view(2);
result.base = 2;
} else if (check_prefix("0o"sv, "0O"sv)) {
if (!all_of(text.substring_view(2), is_ascii_octal_digit))
return {};
result.literal = text.substring_view(2);
result.base = 8;
} else if (check_prefix("0x"sv, "0X"sv)) {
if (!all_of(text.substring_view(2), is_ascii_hex_digit))
return {};
result.literal = text.substring_view(2);
result.base = 16;
} else {
if (!all_of(text, is_ascii_number))
return {};
result.literal = text;
result.base = 10;
}
return result;
}
// 7.1.4.1.1 StringToNumber ( str ), https://tc39.es/ecma262/#sec-stringtonumber
LibJS: Expose the StringToNumber AO for public use This will be needed outside of Value.cpp.
2022-10-14 09:22:47 -04:00
Optional<Value> string_to_number(StringView string)
LibJS: Handle non-decimal integer literals in Value::to_number Implements support for parsing binary and octal literals, and fixes instances where a hex literal is parsed in ways the spec doesn't allow.
2022-08-26 11:14:04 -05:00
{
// 1. Let text be StringToCodePoints(str).
LibJS: Trim non-ASCII whitespace as well in StringToNumber This regressed in f4b3bb5.
2022-08-30 10:20:45 +01:00
String text = Utf8View(string).trim(whitespace_characters, AK::TrimMode::Both).as_string();
LibJS: Handle non-decimal integer literals in Value::to_number Implements support for parsing binary and octal literals, and fixes instances where a hex literal is parsed in ways the spec doesn't allow.
2022-08-26 11:14:04 -05:00
// 2. Let literal be ParseText(text, StringNumericLiteral).
if (text.is_empty())
return Value(0);
if (text == "Infinity" || text == "+Infinity")
return js_infinity();
if (text == "-Infinity")
return js_negative_infinity();
auto result = parse_number_text(text);
// 3. If literal is a List of errors, return NaN.
if (!result.has_value())
return js_nan();
// 4. Return StringNumericValue of literal.
if (result->base != 10) {
auto bigint = Crypto::UnsignedBigInteger::from_base(result->base, result->literal);
return Value(bigint.to_double());
}
LibJS: Make string_to_double use the new double parser
2022-10-12 02:23:50 +02:00
auto maybe_double = text.to_double(AK::TrimWhitespace::No);
if (!maybe_double.has_value())
LibJS: Handle non-decimal integer literals in Value::to_number Implements support for parsing binary and octal literals, and fixes instances where a hex literal is parsed in ways the spec doesn't allow.
2022-08-26 11:14:04 -05:00
return js_nan();
LibJS: Make string_to_double use the new double parser
2022-10-12 02:23:50 +02:00
return Value(*maybe_double);
LibJS: Handle non-decimal integer literals in Value::to_number Implements support for parsing binary and octal literals, and fixes instances where a hex literal is parsed in ways the spec doesn't allow.
2022-08-26 11:14:04 -05:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.4 ToNumber ( argument ), https://tc39.es/ecma262/#sec-tonumber
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> Value::to_number(VM& vm) const
LibJS: Add Value::to_i32() helper function
2020-03-15 15:00:18 +01:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
VERIFY(!is_empty());
if (is_number())
return *this;
switch (m_value.tag) {
case UNDEFINED_TAG:
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return js_nan();
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case NULL_TAG:
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return Value(0);
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BOOLEAN_TAG:
return Value(as_bool() ? 1 : 0);
LibJS: Handle non-decimal integer literals in Value::to_number Implements support for parsing binary and octal literals, and fixes instances where a hex literal is parsed in ways the spec doesn't allow.
2022-08-26 11:14:04 -05:00
case STRING_TAG:
return string_to_number(as_string().string().view());
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case SYMBOL_TAG:
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return vm.throw_completion<TypeError>(ErrorType::Convert, "symbol", "number");
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BIGINT_TAG:
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return vm.throw_completion<TypeError>(ErrorType::Convert, "BigInt", "number");
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case OBJECT_TAG: {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto primitive = TRY(to_primitive(vm, PreferredType::Number));
return primitive.to_number(vm);
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
}
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
default:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Use switch/case for Value::to_{string{_w/o_side_effects},boolean} This makes them a bit more compact and improves consistency as to_boolean() and to_number() already use this style as well. Also re-order the types to match the table in the spec document.
2020-06-04 21:36:52 +01:00
}
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
}
LibJS: Make string_to_bigint() a standalone function This now matches the newly added string_to_number().
2022-08-30 10:29:13 +01:00
static Optional<BigInt*> string_to_bigint(VM& vm, StringView string);
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.13 ToBigInt ( argument ), https://tc39.es/ecma262/#sec-tobigint
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<BigInt*> Value::to_bigint(VM& vm) const
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto primitive = TRY(to_primitive(vm, PreferredType::Number));
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
VERIFY(!primitive.is_empty());
if (primitive.is_number())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::Convert, "number", "BigInt");
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
switch (primitive.m_value.tag) {
case UNDEFINED_TAG:
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::Convert, "undefined", "BigInt");
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case NULL_TAG:
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::Convert, "null", "BigInt");
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BOOLEAN_TAG: {
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
auto value = primitive.as_bool() ? 1 : 0;
LibJS: Add a js_bigint(VM&, ...) overload and use it We already have js_string(VM&, ...) and js_symbol(VM&, ...) overloads, so feels very familiar.
2021-08-03 00:14:48 +01:00
return js_bigint(vm, Crypto::SignedBigInteger { value });
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case BIGINT_TAG:
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return &primitive.as_bigint();
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case STRING_TAG: {
// 1. Let n be ! StringToBigInt(prim).
LibJS: Make string_to_bigint() a standalone function This now matches the newly added string_to_number().
2022-08-30 10:29:13 +01:00
auto bigint = string_to_bigint(vm, primitive.as_string().string());
LibJS: Implement conversion of strings to BigInts according to the spec The spec defines a StringToBigInt AO which allows for converting binary, octal, decimal, and hexadecimal strings to a BigInt. Our conversion was only allowing for decimal strings.
2022-01-31 10:23:51 -05:00
// 2. If n is undefined, throw a SyntaxError exception.
if (!bigint.has_value())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<SyntaxError>(ErrorType::BigIntInvalidValue, primitive);
LibJS: Implement conversion of strings to BigInts according to the spec The spec defines a StringToBigInt AO which allows for converting binary, octal, decimal, and hexadecimal strings to a BigInt. Our conversion was only allowing for decimal strings.
2022-01-31 10:23:51 -05:00
// 3. Return n.
return bigint.release_value();
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
case SYMBOL_TAG:
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::Convert, "symbol", "BigInt");
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
default:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
}
LibJS: Implement conversion of strings to BigInts according to the spec The spec defines a StringToBigInt AO which allows for converting binary, octal, decimal, and hexadecimal strings to a BigInt. Our conversion was only allowing for decimal strings.
2022-01-31 10:23:51 -05:00
struct BigIntParseResult {
StringView literal;
u8 base { 10 };
bool is_negative { false };
};
static Optional<BigIntParseResult> parse_bigint_text(StringView text)
{
BigIntParseResult result {};
auto parse_for_prefixed_base = [&](auto lower_prefix, auto upper_prefix, auto validator) {
if (text.length() <= 2)
return false;
if (!text.starts_with(lower_prefix) && !text.starts_with(upper_prefix))
return false;
return all_of(text.substring_view(2), validator);
};
if (parse_for_prefixed_base("0b"sv, "0B"sv, is_ascii_binary_digit)) {
result.literal = text.substring_view(2);
result.base = 2;
} else if (parse_for_prefixed_base("0o"sv, "0O"sv, is_ascii_octal_digit)) {
result.literal = text.substring_view(2);
result.base = 8;
} else if (parse_for_prefixed_base("0x"sv, "0X"sv, is_ascii_hex_digit)) {
result.literal = text.substring_view(2);
result.base = 16;
} else {
if (text.starts_with('-')) {
text = text.substring_view(1);
result.is_negative = true;
} else if (text.starts_with('+')) {
text = text.substring_view(1);
}
if (!all_of(text, is_ascii_digit))
return {};
result.literal = text;
result.base = 10;
}
return result;
}
// 7.1.14 StringToBigInt ( str ), https://tc39.es/ecma262/#sec-stringtobigint
LibJS: Make string_to_bigint() a standalone function This now matches the newly added string_to_number().
2022-08-30 10:29:13 +01:00
static Optional<BigInt*> string_to_bigint(VM& vm, StringView string)
LibJS: Implement conversion of strings to BigInts according to the spec The spec defines a StringToBigInt AO which allows for converting binary, octal, decimal, and hexadecimal strings to a BigInt. Our conversion was only allowing for decimal strings.
2022-01-31 10:23:51 -05:00
{
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 1. Let text be StringToCodePoints(str).
LibJS: Make string_to_bigint() a standalone function This now matches the newly added string_to_number().
2022-08-30 10:29:13 +01:00
auto text = Utf8View(string).trim(whitespace_characters, AK::TrimMode::Both).as_string();
LibJS: Implement conversion of strings to BigInts according to the spec The spec defines a StringToBigInt AO which allows for converting binary, octal, decimal, and hexadecimal strings to a BigInt. Our conversion was only allowing for decimal strings.
2022-01-31 10:23:51 -05:00
// 2. Let literal be ParseText(text, StringIntegerLiteral).
auto result = parse_bigint_text(text);
// 3. If literal is a List of errors, return undefined.
if (!result.has_value())
return {};
// 4. Let mv be the MV of literal.
// 5. Assert: mv is an integer.
auto bigint = Crypto::SignedBigInteger::from_base(result->base, result->literal);
if (result->is_negative && (bigint != BIGINT_ZERO))
bigint.negate();
// 6. Return ℤ(mv).
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return js_bigint(vm, move(bigint));
LibJS: Implement conversion of strings to BigInts according to the spec The spec defines a StringToBigInt AO which allows for converting binary, octal, decimal, and hexadecimal strings to a BigInt. Our conversion was only allowing for decimal strings.
2022-01-31 10:23:51 -05:00
}
LibJS: Make section URLs more consistent - Drop index.html - Include trailing slash before anchor - Don't use multipage spec URLs
2021-11-24 18:37:57 +00:00
// 7.1.15 ToBigInt64 ( argument ), https://tc39.es/ecma262/#sec-tobigint64
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<i64> Value::to_bigint_int64(VM& vm) const
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto* bigint = TRY(to_bigint(vm));
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
return static_cast<i64>(bigint->big_integer().to_u64());
}
LibJS: Make section URLs more consistent - Drop index.html - Include trailing slash before anchor - Don't use multipage spec URLs
2021-11-24 18:37:57 +00:00
// 7.1.16 ToBigUint64 ( argument ), https://tc39.es/ecma262/#sec-tobiguint64
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<u64> Value::to_bigint_uint64(VM& vm) const
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto* bigint = TRY(to_bigint(vm));
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
return bigint->big_integer().to_u64();
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<double> Value::to_double(VM& vm) const
LibJS: Add Value::to_double() for convenience
2020-04-08 11:22:20 +02:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return TRY(to_number(vm)).as_double();
LibJS: Add Value::to_double() for convenience
2020-04-08 11:22:20 +02:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.19 ToPropertyKey ( argument ), https://tc39.es/ecma262/#sec-topropertykey
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<PropertyKey> Value::to_property_key(VM& vm) const
LibJS: Replace StringOrSymbol::from_value with Value::to_property_key This is a more specification compliant implementation of the abstract operation 7.1.19 ToPropertyKey which should handle boxed symbols correctly.
2021-06-05 15:22:11 +03:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (is_int32() && as_i32() >= 0)
LibJS: Tweak Value::to_property_key() fast path for Int32 Move the check for Int32 *before* we call to_primitive().
2021-10-25 15:37:28 +02:00
return PropertyKey { as_i32() };
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto key = TRY(to_primitive(vm, PreferredType::String));
LibJS: Replace StringOrSymbol::from_value with Value::to_property_key This is a more specification compliant implementation of the abstract operation 7.1.19 ToPropertyKey which should handle boxed symbols correctly.
2021-06-05 15:22:11 +03:00
if (key.is_symbol())
LibJS: Use implicit ThrowCompletionOr<T> constructor where possible Luckily this is not very widespread yet as most of it would happen in the various JS functions instead of AOs.
2021-10-20 19:17:45 +01:00
return &key.as_symbol();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return TRY(key.to_string(vm));
LibJS: Replace StringOrSymbol::from_value with Value::to_property_key This is a more specification compliant implementation of the abstract operation 7.1.19 ToPropertyKey which should handle boxed symbols correctly.
2021-06-05 15:22:11 +03:00
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<i32> Value::to_i32_slow_case(VM& vm) const
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
VERIFY(!is_int32());
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
double value = TRY(to_number(vm)).as_double();
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
if (!isfinite(value) || value == 0)
LibJS: Treat NaN in Value::to_i32() as zero Let's treat it as zero like the ECMAScript spec does in toInteger(). That way we can use to_i32() and don't have to care about weird input input values where a number is expected, i.e. "foo".charAt() === "f" "foo".charAt("bar") === "f" "foo".charAt(0) === "f"
2020-05-23 15:02:14 +01:00
return 0;
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
auto abs = fabs(value);
auto int_val = floor(abs);
if (signbit(value))
int_val = -int_val;
LibJS: Correct modulo behaviour in to_i32 to match the specification
2021-06-06 02:33:55 +03:00
auto remainder = fmod(int_val, 4294967296.0);
auto int32bit = remainder >= 0.0 ? remainder : remainder + 4294967296.0; // The notation “x modulo y” computes a value k of the same sign as y
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
if (int32bit >= 2147483648.0)
int32bit -= 4294967296.0;
return static_cast<i32>(int32bit);
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<i32> Value::to_i32(VM& vm) const
LibJS: Convert to_i32() to ThrowCompletionOr
2021-10-17 23:33:35 +03:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (is_int32())
return as_i32();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return to_i32_slow_case(vm);
LibJS: Convert to_i32() to ThrowCompletionOr
2021-10-17 23:33:35 +03:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.7 ToUint32 ( argument ), https://tc39.es/ecma262/#sec-touint32
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<u32> Value::to_u32(VM& vm) const
LibJS: Implement String.prototype.split This adds a String.prototype.split implementation modelled after ECMA262 specification. Additionally, `Value::to_u32` was added as an implementation of the standard `ToUint32` abstract operation. There is a tiny kludge for when the separator is an empty string. Basic tests and visiting google.com prove that this is working.
2021-01-09 21:52:47 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
double value = TRY(to_number(vm)).as_double();
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
if (!isfinite(value) || value == 0)
LibJS: Implement String.prototype.split This adds a String.prototype.split implementation modelled after ECMA262 specification. Additionally, `Value::to_u32` was added as an implementation of the standard `ToUint32` abstract operation. There is a tiny kludge for when the separator is an empty string. Basic tests and visiting google.com prove that this is working.
2021-01-09 21:52:47 +01:00
return 0;
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
auto int_val = floor(fabs(value));
if (signbit(value))
int_val = -int_val;
auto int32bit = fmod(int_val, NumericLimits<u32>::max() + 1.0);
LibJS: Avoid undefined static cast of negative values in to_u32 If the value we get after fmod in Value::to_u32 is negative, UBSAN complains that -N is out of bounds for u32. An extra static cast to i64 makes it stop complaining. An alternative implementation could add 2^32 if the fmod'd value is negative. Caught by UBSAN and oss-fuzz.
2021-05-31 13:05:39 -06:00
// Cast to i64 here to ensure that the double --> u32 cast doesn't invoke undefined behavior
// Otherwise, negative numbers cause a UBSAN warning.
return static_cast<u32>(static_cast<i64>(int32bit));
LibJS: Implement String.prototype.split This adds a String.prototype.split implementation modelled after ECMA262 specification. Additionally, `Value::to_u32` was added as an implementation of the standard `ToUint32` abstract operation. There is a tiny kludge for when the separator is an empty string. Basic tests and visiting google.com prove that this is working.
2021-01-09 21:52:47 +01:00
}
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
// 7.1.8 ToInt16 ( argument ), https://tc39.es/ecma262/#sec-toint16
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<i16> Value::to_i16(VM& vm) const
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
double value = TRY(to_number(vm)).as_double();
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
if (!isfinite(value) || value == 0)
return 0;
auto abs = fabs(value);
auto int_val = floor(abs);
if (signbit(value))
int_val = -int_val;
auto remainder = fmod(int_val, 65536.0);
auto int16bit = remainder >= 0.0 ? remainder : remainder + 65536.0; // The notation “x modulo y” computes a value k of the same sign as y
if (int16bit >= 32768.0)
int16bit -= 65536.0;
return static_cast<i16>(int16bit);
}
// 7.1.9 ToUint16 ( argument ), https://tc39.es/ecma262/#sec-touint16
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<u16> Value::to_u16(VM& vm) const
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
double value = TRY(to_number(vm)).as_double();
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
if (!isfinite(value) || value == 0)
return 0;
auto int_val = floor(fabs(value));
if (signbit(value))
int_val = -int_val;
auto int16bit = fmod(int_val, NumericLimits<u16>::max() + 1.0);
LibJS: Fix wraparound UB in `Value::to_u{8,16}` 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.
2021-08-06 20:42:36 +02:00
if (int16bit < 0)
int16bit += NumericLimits<u16>::max() + 1.0;
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
return static_cast<u16>(int16bit);
}
// 7.1.10 ToInt8 ( argument ), https://tc39.es/ecma262/#sec-toint8
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<i8> Value::to_i8(VM& vm) const
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
double value = TRY(to_number(vm)).as_double();
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
if (!isfinite(value) || value == 0)
return 0;
auto abs = fabs(value);
auto int_val = floor(abs);
if (signbit(value))
int_val = -int_val;
auto remainder = fmod(int_val, 256.0);
auto int8bit = remainder >= 0.0 ? remainder : remainder + 256.0; // The notation “x modulo y” computes a value k of the same sign as y
if (int8bit >= 128.0)
int8bit -= 256.0;
return static_cast<i8>(int8bit);
}
// 7.1.11 ToUint8 ( argument ), https://tc39.es/ecma262/#sec-touint8
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<u8> Value::to_u8(VM& vm) const
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
double value = TRY(to_number(vm)).as_double();
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
if (!isfinite(value) || value == 0)
return 0;
auto int_val = floor(fabs(value));
if (signbit(value))
int_val = -int_val;
auto int8bit = fmod(int_val, NumericLimits<u8>::max() + 1.0);
LibJS: Fix wraparound UB in `Value::to_u{8,16}` 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.
2021-08-06 20:42:36 +02:00
if (int8bit < 0)
int8bit += NumericLimits<u8>::max() + 1.0;
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
return static_cast<u8>(int8bit);
}
// 7.1.12 ToUint8Clamp ( argument ), https://tc39.es/ecma262/#sec-touint8clamp
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<u8> Value::to_u8_clamp(VM& vm) const
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto number = TRY(to_number(vm));
LibJS: Add a bunch of numeric conversions to Value Namely: - BigInt64 - BigUint64 - i16 - u16 - i8 - u8 - Clamped u8 These will be used in ArrayBuffer::numeric_to_raw_bytes later.
2021-06-17 00:13:26 +01:00
if (number.is_nan())
return 0;
double value = number.as_double();
if (value <= 0.0)
return 0;
if (value >= 255.0)
return 255;
auto int_val = floor(value);
if (int_val + 0.5 < value)
return static_cast<u8>(int_val + 1.0);
if (value < int_val + 0.5)
return static_cast<u8>(int_val);
if (fmod(int_val, 2.0) == 1.0)
return static_cast<u8>(int_val + 1.0);
return static_cast<u8>(int_val);
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.20 ToLength ( argument ), https://tc39.es/ecma262/#sec-tolength
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<size_t> Value::to_length(VM& vm) const
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto len = TRY(to_integer_or_infinity(vm));
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
if (len <= 0)
return 0;
LibJS: Don't overflow size_t in `Value::to_length()` 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.
2021-08-07 23:47:39 +02:00
// FIXME: The spec says that this function's output range is 0 - 2^53-1. But we don't want to overflow the size_t.
constexpr double length_limit = sizeof(void*) == 4 ? NumericLimits<size_t>::max() : MAX_ARRAY_LIKE_INDEX;
return min(len, length_limit);
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.22 ToIndex ( argument ), https://tc39.es/ecma262/#sec-toindex
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<size_t> Value::to_index(VM& vm) const
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
{
if (is_undefined())
return 0;
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto integer_index = TRY(to_integer_or_infinity(vm));
LibJS: Convert to_index() to ThrowCompletionOr
2021-10-18 00:05:01 +03:00
if (integer_index < 0)
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<RangeError>(ErrorType::InvalidIndex);
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto index = MUST(Value(integer_index).to_length(vm));
LibJS: Convert to_index() to ThrowCompletionOr
2021-10-18 00:05:01 +03:00
if (integer_index != index)
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<RangeError>(ErrorType::InvalidIndex);
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
return index;
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.1.5 ToIntegerOrInfinity ( argument ), https://tc39.es/ecma262/#sec-tointegerorinfinity
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<double> Value::to_integer_or_infinity(VM& vm) const
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto number = TRY(to_number(vm));
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
if (number.is_nan() || number.as_double() == 0)
return 0;
if (number.is_infinity())
return number.as_double();
LibJS: Use fabs() instead of abs() in JS::Value abs() takes an int, so this would only work correctly for numbers smaller than INT_MAX.
2021-02-15 11:51:08 +01:00
auto integer = floor(fabs(number.as_double()));
LibJS: Do not negate zero into negative zero in ToIntegerOrInfinity When the input value was in the range of [-1, 0] we would incorrectly negate the resulting integer, resulting in -0 instead of the expected 0
2022-04-30 21:38:32 +03:00
if (number.as_double() < 0 && integer != 0)
LibJS: Add Value::to_{index,length,integer_or_infinity} abstract operations We should pay more attention to using the well-defined abstract operations from the spec rather than making up our own, often slightly different rules. This is another step in that direction.
2020-12-02 13:23:51 +00:00
integer = -integer;
return integer;
}
LibJS: Add variant of to_integer_or_infinity() for plain doubles In many cases we already know a certain value is a number, or don't have JS values at all and would need to wrap doubles in a value. To optimize these cases and avoid having to pass a global object into functions that won't ever allocate or throw, add a standalone implementation of this function that takes and returns doubles directly.
2022-05-06 20:17:16 +02:00
// Standalone variant using plain doubles for cases where we already got numbers and know the AO won't throw.
double to_integer_or_infinity(double number)
{
// 1. Let number be ? ToNumber(argument).
// 2. If number is NaN, +0𝔽, or -0𝔽, return 0.
if (isnan(number) || number == 0)
return 0;
// 3. If number is +∞𝔽, return +∞.
if (__builtin_isinf_sign(number) > 0)
return static_cast<double>(INFINITY);
// 4. If number is -∞𝔽, return -∞.
if (__builtin_isinf_sign(number) < 0)
return static_cast<double>(-INFINITY);
// 5. Let integer be floor(abs(ℝ(number))).
auto integer = floor(fabs(number));
// 6. If number < -0𝔽, set integer to -integer.
if (number < 0 && integer != 0)
integer = -integer;
// 7. Return integer.
return integer;
}
LibJS: Implement the GetV() abstract operation Like Get(), but with any value instead of an object - it's calling ToObject() for us and passes the value to [[Get]]() as the receiver. This will be used in GetMethod() (and a couple of other places, which can be updated over time). I also tried something new here: adding the three steps from the spec as inline comments :^)
2021-06-26 19:17:28 +01:00
// 7.3.3 GetV ( V, P ), https://tc39.es/ecma262/#sec-getv
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> Value::get(VM& vm, PropertyKey const& property_key) const
LibJS: Implement the GetV() abstract operation Like Get(), but with any value instead of an object - it's calling ToObject() for us and passes the value to [[Get]]() as the receiver. This will be used in GetMethod() (and a couple of other places, which can be updated over time). I also tried something new here: adding the three steps from the spec as inline comments :^)
2021-06-26 19:17:28 +01:00
{
// 1. Assert: IsPropertyKey(P) is true.
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
VERIFY(property_key.is_valid());
LibJS: Implement the GetV() abstract operation Like Get(), but with any value instead of an object - it's calling ToObject() for us and passes the value to [[Get]]() as the receiver. This will be used in GetMethod() (and a couple of other places, which can be updated over time). I also tried something new here: adding the three steps from the spec as inline comments :^)
2021-06-26 19:17:28 +01:00
// 2. Let O be ? ToObject(V).
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto* object = TRY(to_object(vm));
LibJS: Implement the GetV() abstract operation Like Get(), but with any value instead of an object - it's calling ToObject() for us and passes the value to [[Get]]() as the receiver. This will be used in GetMethod() (and a couple of other places, which can be updated over time). I also tried something new here: adding the three steps from the spec as inline comments :^)
2021-06-26 19:17:28 +01:00
// 3. Return ? O.[[Get]](P, V).
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
return TRY(object->internal_get(property_key, *this));
LibJS: Implement the GetV() abstract operation Like Get(), but with any value instead of an object - it's calling ToObject() for us and passes the value to [[Get]]() as the receiver. This will be used in GetMethod() (and a couple of other places, which can be updated over time). I also tried something new here: adding the three steps from the spec as inline comments :^)
2021-06-26 19:17:28 +01:00
}
LibJS: Update spec numbers for Operations on Objects AOs The error cause proposal was merged, so some spec numbers were bumped.
2021-12-21 08:27:04 -05:00
// 7.3.11 GetMethod ( V, P ), https://tc39.es/ecma262/#sec-getmethod
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<FunctionObject*> Value::get_method(VM& vm, PropertyKey const& property_key) const
LibJS: Implement the GetMethod() abstract operation as a Value method This was a standalone function previously (get_method()), but instead of passing a Value to it, we can just make it a method. Also add spec step comments and fix the receiver value by using GetV().
2021-06-26 19:24:35 +01:00
{
// 1. Assert: IsPropertyKey(P) is true.
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
VERIFY(property_key.is_valid());
LibJS: Implement the GetMethod() abstract operation as a Value method This was a standalone function previously (get_method()), but instead of passing a Value to it, we can just make it a method. Also add spec step comments and fix the receiver value by using GetV().
2021-06-26 19:24:35 +01:00
// 2. Let func be ? GetV(V, P).
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto function = TRY(get(vm, property_key));
LibJS: Implement the GetMethod() abstract operation as a Value method This was a standalone function previously (get_method()), but instead of passing a Value to it, we can just make it a method. Also add spec step comments and fix the receiver value by using GetV().
2021-06-26 19:24:35 +01:00
// 3. If func is either undefined or null, return undefined.
if (function.is_nullish())
return nullptr;
// 4. If IsCallable(func) is false, throw a TypeError exception.
LibJS: Convert get_method to ThrowCompletionOr
2021-09-23 21:24:51 +03:00
if (!function.is_function())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::NotAFunction, function.to_string_without_side_effects());
LibJS: Implement the GetMethod() abstract operation as a Value method This was a standalone function previously (get_method()), but instead of passing a Value to it, we can just make it a method. Also add spec step comments and fix the receiver value by using GetV().
2021-06-26 19:24:35 +01:00
// 5. Return func.
return &function.as_function();
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.10 Relational Operators, https://tc39.es/ecma262/#sec-relational-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> greater_than(VM& vm, Value lhs, Value rhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (lhs.is_int32() && rhs.is_int32())
LibJS: Add fast paths for <, >, <=, and >= with Int32 on both sides This gives us a ~5% speed-up on Kraken's ai-astar.js
2021-10-25 14:34:22 +02:00
return lhs.as_i32() > rhs.as_i32();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
TriState relation = TRY(is_less_than(vm, lhs, rhs, false));
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
if (relation == TriState::Unknown)
return Value(false);
return Value(relation == TriState::True);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.10 Relational Operators, https://tc39.es/ecma262/#sec-relational-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> greater_than_equals(VM& vm, Value lhs, Value rhs)
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (lhs.is_int32() && rhs.is_int32())
LibJS: Add fast paths for <, >, <=, and >= with Int32 on both sides This gives us a ~5% speed-up on Kraken's ai-astar.js
2021-10-25 14:34:22 +02:00
return lhs.as_i32() >= rhs.as_i32();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
TriState relation = TRY(is_less_than(vm, lhs, rhs, true));
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
if (relation == TriState::Unknown || relation == TriState::True)
return Value(false);
return Value(true);
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.10 Relational Operators, https://tc39.es/ecma262/#sec-relational-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> less_than(VM& vm, Value lhs, Value rhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (lhs.is_int32() && rhs.is_int32())
LibJS: Add fast paths for <, >, <=, and >= with Int32 on both sides This gives us a ~5% speed-up on Kraken's ai-astar.js
2021-10-25 14:34:22 +02:00
return lhs.as_i32() < rhs.as_i32();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
TriState relation = TRY(is_less_than(vm, lhs, rhs, true));
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
if (relation == TriState::Unknown)
return Value(false);
return Value(relation == TriState::True);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.10 Relational Operators, https://tc39.es/ecma262/#sec-relational-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> less_than_equals(VM& vm, Value lhs, Value rhs)
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
{
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (lhs.is_int32() && rhs.is_int32())
LibJS: Add fast paths for <, >, <=, and >= with Int32 on both sides This gives us a ~5% speed-up on Kraken's ai-astar.js
2021-10-25 14:34:22 +02:00
return lhs.as_i32() <= rhs.as_i32();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
TriState relation = TRY(is_less_than(vm, lhs, rhs, false));
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
if (relation == TriState::Unknown || relation == TriState::True)
return Value(false);
return Value(true);
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.12 Binary Bitwise Operators, https://tc39.es/ecma262/#sec-binary-bitwise-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> bitwise_and(VM& vm, Value lhs, Value rhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add tests for bitwise & and ^ And fix some edge case conversion bugs found by the tests.
2020-07-22 20:27:32 -04:00
if (both_number(lhs_numeric, rhs_numeric)) {
if (!lhs_numeric.is_finite_number() || !rhs_numeric.is_finite_number())
return Value(0);
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return Value(TRY(lhs_numeric.to_i32(vm)) & TRY(rhs_numeric.to_i32(vm)));
LibJS: Add tests for bitwise & and ^ And fix some edge case conversion bugs found by the tests.
2020-07-22 20:27:32 -04:00
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_bigint(lhs_numeric, rhs_numeric))
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().bitwise_and(rhs_numeric.as_bigint().big_integer())));
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "bitwise AND");
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.12 Binary Bitwise Operators, https://tc39.es/ecma262/#sec-binary-bitwise-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> bitwise_or(VM& vm, Value lhs, Value rhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric)) {
if (!lhs_numeric.is_finite_number() && !rhs_numeric.is_finite_number())
return Value(0);
if (!lhs_numeric.is_finite_number())
return rhs_numeric;
if (!rhs_numeric.is_finite_number())
return lhs_numeric;
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return Value(TRY(lhs_numeric.to_i32(vm)) | TRY(rhs_numeric.to_i32(vm)));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
if (both_bigint(lhs_numeric, rhs_numeric))
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().bitwise_or(rhs_numeric.as_bigint().big_integer())));
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "bitwise OR");
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.12 Binary Bitwise Operators, https://tc39.es/ecma262/#sec-binary-bitwise-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> bitwise_xor(VM& vm, Value lhs, Value rhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add tests for bitwise & and ^ And fix some edge case conversion bugs found by the tests.
2020-07-22 20:27:32 -04:00
if (both_number(lhs_numeric, rhs_numeric)) {
if (!lhs_numeric.is_finite_number() && !rhs_numeric.is_finite_number())
return Value(0);
if (!lhs_numeric.is_finite_number())
return rhs_numeric;
if (!rhs_numeric.is_finite_number())
return lhs_numeric;
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return Value(TRY(lhs_numeric.to_i32(vm)) ^ TRY(rhs_numeric.to_i32(vm)));
LibJS: Add tests for bitwise & and ^ And fix some edge case conversion bugs found by the tests.
2020-07-22 20:27:32 -04:00
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_bigint(lhs_numeric, rhs_numeric))
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().bitwise_xor(rhs_numeric.as_bigint().big_integer())));
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "bitwise XOR");
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.5.6 Bitwise NOT Operator ( ~ ), https://tc39.es/ecma262/#sec-bitwise-not-operator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> bitwise_not(VM& vm, Value lhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs_numeric.is_number())
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return Value(~TRY(lhs_numeric.to_i32(vm)));
LibJS+LibCrypto: Fix SignedBitInteger::bitwise_not and use it in LibJS Bitwise operators are defined on two's complement, but SignedBitInteger uses sign-magnitude. Correctly convert between the two. Let LibJS delegate to SignedBitInteger for bitwise_not, like it does for all other bitwise_ operations on bigints. No behavior change (LibJS is now the only client of SignedBitInteger::bitwise_not()).
2022-01-17 12:22:51 -05:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().bitwise_not()));
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.5.4 Unary + Operator, https://tc39.es/ecma262/#sec-unary-plus-operator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> unary_plus(VM& vm, Value lhs)
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return TRY(lhs.to_number(vm));
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.5.5 Unary - Operator, https://tc39.es/ecma262/#sec-unary-minus-operator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> unary_minus(VM& vm, Value lhs)
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs_numeric.is_number()) {
if (lhs_numeric.is_nan())
return js_nan();
return Value(-lhs_numeric.as_double());
}
if (lhs_numeric.as_bigint().big_integer() == BIGINT_ZERO)
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, BIGINT_ZERO));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
auto big_integer_negated = lhs_numeric.as_bigint().big_integer();
big_integer_negated.negate();
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, big_integer_negated));
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.9.1 The Left Shift Operator ( << ), https://tc39.es/ecma262/#sec-left-shift-operator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> left_shift(VM& vm, Value lhs, Value rhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric)) {
if (!lhs_numeric.is_finite_number())
return Value(0);
if (!rhs_numeric.is_finite_number())
return lhs_numeric;
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
// Ok, so this performs toNumber() again but that "can't" throw
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_i32 = MUST(lhs_numeric.to_i32(vm));
auto rhs_u32 = MUST(rhs_numeric.to_u32(vm)) % 32;
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
return Value(lhs_i32 << rhs_u32);
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Add left shift & right shift operator support for BigIntegers Based on https://tc39.es/ecma262/#sec-numeric-types-bigint-leftShift (This commit also includes the matching tests)
2021-05-31 20:27:44 +03:00
if (both_bigint(lhs_numeric, rhs_numeric)) {
LibJS: Fix that leftshift for BigInts did not round down For negative number this previously rounded towards zero instead of the intended always rounding down.
2022-08-20 00:23:11 +02:00
// 6.1.6.2.9 BigInt::leftShift ( x, y ), https://tc39.es/ecma262/#sec-numeric-types-bigint-leftShift
LibJS: Add left shift & right shift operator support for BigIntegers Based on https://tc39.es/ecma262/#sec-numeric-types-bigint-leftShift (This commit also includes the matching tests)
2021-05-31 20:27:44 +03:00
auto multiplier_divisor = Crypto::SignedBigInteger { Crypto::NumberTheory::Power(Crypto::UnsignedBigInteger(2), rhs_numeric.as_bigint().big_integer().unsigned_value()) };
LibJS: Fix that leftshift for BigInts did not round down For negative number this previously rounded towards zero instead of the intended always rounding down.
2022-08-20 00:23:11 +02:00
// 1. If y < 0ℤ, then
if (rhs_numeric.as_bigint().big_integer().is_negative()) {
// a. Return the BigInt value that represents ℝ(x) / 2^-y, rounding down to the nearest integer, including for negative numbers.
// NOTE: Since y is negative we can just do ℝ(x) / 2^|y|
auto const& big_integer = lhs_numeric.as_bigint().big_integer();
auto division_result = big_integer.divided_by(multiplier_divisor);
// For positive initial values and no remainder just return quotient
if (division_result.remainder.is_zero() || !big_integer.is_negative())
return js_bigint(vm, division_result.quotient);
// For negative round "down" to the next negative number
return js_bigint(vm, division_result.quotient.minus(Crypto::SignedBigInteger { 1 }));
}
// 2. Return the BigInt value that represents ℝ(x) × 2^y.
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().multiplied_by(multiplier_divisor)));
LibJS: Add left shift & right shift operator support for BigIntegers Based on https://tc39.es/ecma262/#sec-numeric-types-bigint-leftShift (This commit also includes the matching tests)
2021-05-31 20:27:44 +03:00
}
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "left-shift");
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.9.2 The Signed Right Shift Operator ( >> ), https://tc39.es/ecma262/#sec-signed-right-shift-operator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> right_shift(VM& vm, Value lhs, Value rhs)
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric)) {
if (!lhs_numeric.is_finite_number())
return Value(0);
if (!rhs_numeric.is_finite_number())
return lhs_numeric;
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_i32 = MUST(lhs_numeric.to_i32(vm));
auto rhs_u32 = MUST(rhs_numeric.to_u32(vm)) % 32;
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
return Value(lhs_i32 >> rhs_u32);
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Add left shift & right shift operator support for BigIntegers Based on https://tc39.es/ecma262/#sec-numeric-types-bigint-leftShift (This commit also includes the matching tests)
2021-05-31 20:27:44 +03:00
if (both_bigint(lhs_numeric, rhs_numeric)) {
auto rhs_negated = rhs_numeric.as_bigint().big_integer();
rhs_negated.negate();
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return left_shift(vm, lhs, js_bigint(vm, rhs_negated));
LibJS: Add left shift & right shift operator support for BigIntegers Based on https://tc39.es/ecma262/#sec-numeric-types-bigint-leftShift (This commit also includes the matching tests)
2021-05-31 20:27:44 +03:00
}
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "right-shift");
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.9.3 The Unsigned Right Shift Operator ( >>> ), https://tc39.es/ecma262/#sec-unsigned-right-shift-operator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> unsigned_right_shift(VM& vm, Value lhs, Value rhs)
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric)) {
if (!lhs_numeric.is_finite_number())
return Value(0);
if (!rhs_numeric.is_finite_number())
return lhs_numeric;
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
// Ok, so this performs toNumber() again but that "can't" throw
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_u32 = MUST(lhs_numeric.to_u32(vm));
auto rhs_u32 = MUST(rhs_numeric.to_u32(vm)) % 32;
LibJS: Improve correctness of rounding and bitwise operations Patch from Anonymous
2021-02-05 09:11:58 +01:00
return Value(lhs_u32 >> rhs_u32);
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperator, "unsigned right-shift");
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.8.1 The Addition Operator ( + ), https://tc39.es/ecma262/#sec-addition-operator-plus
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> add(VM& vm, Value lhs, Value rhs)
LibJS: Forgot to move add/sub/typed_eq to Value.cpp
2020-03-11 12:16:26 +01:00
{
LibJS: Add fast path for add() with two numeric JS::Values
2021-03-21 18:13:14 +01:00
if (both_number(lhs, rhs)) {
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (lhs.is_int32() && rhs.is_int32()) {
LibJS: Add fast path for add() with two numeric JS::Values
2021-03-21 18:13:14 +01:00
Checked<i32> result;
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
result = MUST(lhs.to_i32(vm));
result += MUST(rhs.to_i32(vm));
LibJS: Add fast path for add() with two numeric JS::Values
2021-03-21 18:13:14 +01:00
if (!result.has_overflow())
return Value(result.value());
}
return Value(lhs.as_double() + rhs.as_double());
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_primitive = TRY(lhs.to_primitive(vm));
auto rhs_primitive = TRY(rhs.to_primitive(vm));
LibJS: Adding two values should convert them to primitives first
2020-04-15 09:32:44 +02:00
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
if (lhs_primitive.is_string() || rhs_primitive.is_string()) {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_string = TRY(lhs_primitive.to_primitive_string(vm));
auto rhs_string = TRY(rhs_primitive.to_primitive_string(vm));
return js_rope_string(vm, *lhs_string, *rhs_string);
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
}
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs_primitive.to_numeric(vm));
auto rhs_numeric = TRY(rhs_primitive.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric))
return Value(lhs_numeric.as_double() + rhs_numeric.as_double());
if (both_bigint(lhs_numeric, rhs_numeric))
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().plus(rhs_numeric.as_bigint().big_integer())));
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "addition");
LibJS: Forgot to move add/sub/typed_eq to Value.cpp
2020-03-11 12:16:26 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.8.2 The Subtraction Operator ( - ), https://tc39.es/ecma262/#sec-subtraction-operator-minus
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> sub(VM& vm, Value lhs, Value rhs)
LibJS: Forgot to move add/sub/typed_eq to Value.cpp
2020-03-11 12:16:26 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (both_number(lhs_numeric, rhs_numeric)) {
double lhsd = lhs_numeric.as_double();
double rhsd = rhs_numeric.as_double();
double interm = lhsd - rhsd;
return Value(interm);
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_bigint(lhs_numeric, rhs_numeric))
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().minus(rhs_numeric.as_bigint().big_integer())));
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "subtraction");
LibJS: Forgot to move add/sub/typed_eq to Value.cpp
2020-03-11 12:16:26 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.7 Multiplicative Operators, https://tc39.es/ecma262/#sec-multiplicative-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> mul(VM& vm, Value lhs, Value rhs)
LibJS: Implement multiplication and division operators
2020-03-12 23:04:52 +11:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric))
return Value(lhs_numeric.as_double() * rhs_numeric.as_double());
if (both_bigint(lhs_numeric, rhs_numeric))
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().multiplied_by(rhs_numeric.as_bigint().big_integer())));
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "multiplication");
LibJS: Implement multiplication and division operators
2020-03-12 23:04:52 +11:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.7 Multiplicative Operators, https://tc39.es/ecma262/#sec-multiplicative-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> div(VM& vm, Value lhs, Value rhs)
LibJS: Implement multiplication and division operators
2020-03-12 23:04:52 +11:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric))
return Value(lhs_numeric.as_double() / rhs_numeric.as_double());
LibJS: Throw RangeError on BigInt division/modulo by zero https://tc39.es/ecma262/#sec-numeric-types-bigint-divide https://tc39.es/ecma262/#sec-numeric-types-bigint-remainder
2021-03-16 20:34:40 +01:00
if (both_bigint(lhs_numeric, rhs_numeric)) {
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
if (rhs_numeric.as_bigint().big_integer() == BIGINT_ZERO)
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<RangeError>(ErrorType::DivisionByZero);
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().divided_by(rhs_numeric.as_bigint().big_integer()).quotient));
LibJS: Throw RangeError on BigInt division/modulo by zero https://tc39.es/ecma262/#sec-numeric-types-bigint-divide https://tc39.es/ecma262/#sec-numeric-types-bigint-remainder
2021-03-16 20:34:40 +01:00
}
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "division");
LibJS: Implement multiplication and division operators
2020-03-12 23:04:52 +11:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.7 Multiplicative Operators, https://tc39.es/ecma262/#sec-multiplicative-operators
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> mod(VM& vm, Value lhs, Value rhs)
LibJS: Add basic support for modulo (%) in binary expressions
2020-04-04 21:17:34 +02:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric)) {
LibJS: Handle +Infinity, -Infinity, +0 and -0 in modulo operator Fixes 11 test262 cases.
2021-09-01 16:50:56 +01:00
// 6.1.6.1.6 Number::remainder ( n, d ), https://tc39.es/ecma262/#sec-numeric-types-number-remainder
LibJS: Implement the Number::remainder AO using fmod The ECMA verbiage for modulus is the mathematical definition implemented by fmod, so let's just use that rather than trying to reimplement all the edge cases.
2022-02-16 02:14:57 -08:00
// The ECMA specification is describing the mathematical definition of modulus
// implemented by fmod.
auto n = lhs_numeric.as_double();
auto d = rhs_numeric.as_double();
return Value(fmod(n, d));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Throw RangeError on BigInt division/modulo by zero https://tc39.es/ecma262/#sec-numeric-types-bigint-divide https://tc39.es/ecma262/#sec-numeric-types-bigint-remainder
2021-03-16 20:34:40 +01:00
if (both_bigint(lhs_numeric, rhs_numeric)) {
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
if (rhs_numeric.as_bigint().big_integer() == BIGINT_ZERO)
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<RangeError>(ErrorType::DivisionByZero);
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, lhs_numeric.as_bigint().big_integer().divided_by(rhs_numeric.as_bigint().big_integer()).remainder));
LibJS: Throw RangeError on BigInt division/modulo by zero https://tc39.es/ecma262/#sec-numeric-types-bigint-divide https://tc39.es/ecma262/#sec-numeric-types-bigint-remainder
2021-03-16 20:34:40 +01:00
}
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "modulo");
LibJS: Add basic support for modulo (%) in binary expressions
2020-04-04 21:17:34 +02:00
}
LibJS: Unify exponentiation logic for ** operator and Math.pow The JS behaviour of exponentiation on two number typed values is not a simple matter of forwarding to ::pow(double, double). So, this factors out the Math.pow logic to allow it to be shared with Value::exp.
2022-02-17 11:52:45 -08:00
static Value exp_double(Value base, Value exponent)
{
VERIFY(both_number(base, exponent));
if (exponent.is_nan())
return js_nan();
if (exponent.is_positive_zero() || exponent.is_negative_zero())
return Value(1);
if (base.is_nan())
return js_nan();
if (base.is_positive_infinity())
return exponent.as_double() > 0 ? js_infinity() : Value(0);
if (base.is_negative_infinity()) {
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
auto is_odd_integral_number = exponent.is_integral_number() && (static_cast<i32>(exponent.as_double()) % 2 != 0);
LibJS: Unify exponentiation logic for ** operator and Math.pow The JS behaviour of exponentiation on two number typed values is not a simple matter of forwarding to ::pow(double, double). So, this factors out the Math.pow logic to allow it to be shared with Value::exp.
2022-02-17 11:52:45 -08:00
if (exponent.as_double() > 0)
return is_odd_integral_number ? js_negative_infinity() : js_infinity();
else
return is_odd_integral_number ? Value(-0.0) : Value(0);
}
if (base.is_positive_zero())
return exponent.as_double() > 0 ? Value(0) : js_infinity();
if (base.is_negative_zero()) {
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
auto is_odd_integral_number = exponent.is_integral_number() && (static_cast<i32>(exponent.as_double()) % 2 != 0);
LibJS: Unify exponentiation logic for ** operator and Math.pow The JS behaviour of exponentiation on two number typed values is not a simple matter of forwarding to ::pow(double, double). So, this factors out the Math.pow logic to allow it to be shared with Value::exp.
2022-02-17 11:52:45 -08:00
if (exponent.as_double() > 0)
return is_odd_integral_number ? Value(-0.0) : Value(0);
else
return is_odd_integral_number ? js_negative_infinity() : js_infinity();
}
VERIFY(base.is_finite_number() && !base.is_positive_zero() && !base.is_negative_zero());
if (exponent.is_positive_infinity()) {
auto absolute_base = fabs(base.as_double());
if (absolute_base > 1)
return js_infinity();
else if (absolute_base == 1)
return js_nan();
else if (absolute_base < 1)
return Value(0);
}
if (exponent.is_negative_infinity()) {
auto absolute_base = fabs(base.as_double());
if (absolute_base > 1)
return Value(0);
else if (absolute_base == 1)
return js_nan();
else if (absolute_base < 1)
return js_infinity();
}
VERIFY(exponent.is_finite_number() && !exponent.is_positive_zero() && !exponent.is_negative_zero());
if (base.as_double() < 0 && !exponent.is_integral_number())
return js_nan();
return Value(::pow(base.as_double(), exponent.as_double()));
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.6 Exponentiation Operator, https://tc39.es/ecma262/#sec-exp-operator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> exp(VM& vm, Value lhs, Value rhs)
LibJS: Implement exponentiation (** operator)
2020-04-05 13:40:00 +01:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_numeric = TRY(lhs.to_numeric(vm));
auto rhs_numeric = TRY(rhs.to_numeric(vm));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (both_number(lhs_numeric, rhs_numeric))
LibJS: Unify exponentiation logic for ** operator and Math.pow The JS behaviour of exponentiation on two number typed values is not a simple matter of forwarding to ::pow(double, double). So, this factors out the Math.pow logic to allow it to be shared with Value::exp.
2022-02-17 11:52:45 -08:00
return exp_double(lhs_numeric, rhs_numeric);
LibJS: Throw RangeError on BigInt exponentiation with negative exponent https://tc39.es/ecma262/#sec-numeric-types-bigint-exponentiate
2021-03-16 20:35:55 +01:00
if (both_bigint(lhs_numeric, rhs_numeric)) {
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
if (rhs_numeric.as_bigint().big_integer().is_negative())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<RangeError>(ErrorType::NegativeExponent);
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(js_bigint(vm, Crypto::NumberTheory::Power(lhs_numeric.as_bigint().big_integer(), rhs_numeric.as_bigint().big_integer())));
LibJS: Throw RangeError on BigInt exponentiation with negative exponent https://tc39.es/ecma262/#sec-numeric-types-bigint-exponentiate
2021-03-16 20:35:55 +01:00
}
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::BigIntBadOperatorOtherType, "exponentiation");
LibJS: Implement exponentiation (** operator)
2020-04-05 13:40:00 +01:00
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> in(VM& vm, Value lhs, Value rhs)
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
{
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
if (!rhs.is_object())
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return vm.throw_completion<TypeError>(ErrorType::InOperatorWithObject);
auto lhs_property_key = TRY(lhs.to_property_key(vm));
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(TRY(rhs.as_object().has_property(lhs_property_key)));
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 13.10.2 InstanceofOperator ( V, target ), https://tc39.es/ecma262/#sec-instanceofoperator
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> instance_of(VM& vm, Value lhs, Value rhs)
LibJS: Forgot to move add/sub/typed_eq to Value.cpp
2020-03-11 12:16:26 +01:00
{
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
if (!rhs.is_object())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::NotAnObject, rhs.to_string_without_side_effects());
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto has_instance_method = TRY(rhs.get_method(vm, *vm.well_known_symbol_has_instance()));
LibJS: Use Value::get_method() a bunch
2021-03-02 18:06:28 +01:00
if (has_instance_method) {
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 19:24:32 +01:00
auto has_instance_result = TRY(call(vm, *has_instance_method, rhs, lhs));
LibJS: Fix crashing exception in Value::ordinary_has_instance() Two issues: - throw_exception() with ErrorType::InstanceOfOperatorBadPrototype would receive rhs_prototype.to_string_without_side_effects(), which would ASSERT_NOT_REACHED() as to_string_without_side_effects() must not be called on an empty value. It should (and now does) receive the RHS value instead as the message is "'prototype' property of {} is not an object". - Value::instance_of() was missing an exception check after calling has_instance_method, to_boolean() on an empty value result would crash as well. Fixes #3930.
2020-11-03 17:54:57 +00:00
return Value(has_instance_result.to_boolean());
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
}
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
if (!rhs.is_function())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::NotAFunction, rhs.to_string_without_side_effects());
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return TRY(ordinary_has_instance(vm, lhs, rhs));
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
}
LibJS: Update spec numbers for Operations on Objects AOs The error cause proposal was merged, so some spec numbers were bumped.
2021-12-21 08:27:04 -05:00
// 7.3.22 OrdinaryHasInstance ( C, O ), https://tc39.es/ecma262/#sec-ordinaryhasinstance
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> ordinary_has_instance(VM& vm, Value lhs, Value rhs)
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
{
if (!rhs.is_function())
return Value(false);
auto& rhs_function = rhs.as_function();
LibJS: Remove hand-rolled Object is_foo() helpers in favor of RTTI
2021-01-01 17:46:39 +01:00
if (is<BoundFunction>(rhs_function)) {
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
auto& bound_target = static_cast<BoundFunction const&>(rhs_function);
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return instance_of(vm, lhs, Value(&bound_target.bound_target_function()));
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
}
if (!lhs.is_object())
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return Value(false);
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
Object* lhs_object = &lhs.as_object();
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
auto rhs_prototype = TRY(rhs_function.get(vm.names.prototype));
if (!rhs_prototype.is_object())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::InstanceOfOperatorBadPrototype, rhs.to_string_without_side_effects());
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
while (true) {
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
lhs_object = TRY(lhs_object->internal_get_prototype_of());
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
if (!lhs_object)
return Value(false);
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
if (same_value(rhs_prototype, lhs_object))
LibJS: Implement spec-complient instance_of operation
2020-07-11 15:27:28 -07:00
return Value(true);
}
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.10 SameValue ( x, y ), https://tc39.es/ecma262/#sec-samevalue
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
bool same_value(Value lhs, Value rhs)
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
{
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
if (!same_type_for_equality(lhs, rhs))
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return false;
if (lhs.is_number()) {
if (lhs.is_nan() && rhs.is_nan())
return true;
if (lhs.is_positive_zero() && rhs.is_negative_zero())
return false;
if (lhs.is_negative_zero() && rhs.is_positive_zero())
return false;
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
return lhs.as_double() == rhs.as_double();
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs.is_bigint()) {
auto lhs_big_integer = lhs.as_bigint().big_integer();
auto rhs_big_integer = rhs.as_bigint().big_integer();
if (lhs_big_integer == BIGINT_ZERO && rhs_big_integer == BIGINT_ZERO && lhs_big_integer.is_negative() != rhs_big_integer.is_negative())
return false;
return lhs_big_integer == rhs_big_integer;
}
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
return same_value_non_numeric(lhs, rhs);
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.11 SameValueZero ( x, y ), https://tc39.es/ecma262/#sec-samevaluezero
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
bool same_value_zero(Value lhs, Value rhs)
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
{
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
if (!same_type_for_equality(lhs, rhs))
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return false;
if (lhs.is_number()) {
if (lhs.is_nan() && rhs.is_nan())
return true;
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
return lhs.as_double() == rhs.as_double();
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs.is_bigint())
return lhs.as_bigint().big_integer() == rhs.as_bigint().big_integer();
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
return same_value_non_numeric(lhs, rhs);
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.12 SameValueNonNumeric ( x, y ), https://tc39.es/ecma262/#sec-samevaluenonnumeric
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
bool same_value_non_numeric(Value lhs, Value rhs)
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!lhs.is_number() && !lhs.is_bigint());
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
VERIFY(same_type_for_equality(lhs, rhs));
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
if (lhs.is_string())
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return lhs.as_string().string() == rhs.as_string().string();
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
return lhs.m_value.encoded == rhs.m_value.encoded;
LibJS: Forgot to move add/sub/typed_eq to Value.cpp
2020-03-11 12:16:26 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.15 IsStrictlyEqual ( x, y ), https://tc39.es/ecma262/#sec-isstrictlyequal
LibJS: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
bool is_strictly_equal(Value lhs, Value rhs)
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
{
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
if (!same_type_for_equality(lhs, rhs))
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return false;
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
if (lhs.is_number()) {
if (lhs.is_nan() || rhs.is_nan())
return false;
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
if (lhs.as_double() == rhs.as_double())
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return true;
return false;
}
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs.is_bigint())
return lhs.as_bigint().big_integer() == rhs.as_bigint().big_integer();
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
return same_value_non_numeric(lhs, rhs);
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
}
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.14 IsLooselyEqual ( x, y ), https://tc39.es/ecma262/#sec-islooselyequal
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<bool> is_loosely_equal(VM& vm, Value lhs, Value rhs)
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
{
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// 1. If Type(x) is the same as Type(y), then
if (same_type_for_equality(lhs, rhs)) {
// a. Return IsStrictlyEqual(x, y).
LibJS: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
return is_strictly_equal(lhs, rhs);
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
}
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// 2. If x is null and y is undefined, return true.
// 3. If x is undefined and y is null, return true.
LibJS: Add Value::is_nullish()
2020-10-02 16:00:15 +02:00
if (lhs.is_nullish() && rhs.is_nullish())
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return true;
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// 4. NOTE: This step is replaced in section B.3.6.2.
// B.3.6.2 Changes to IsLooselyEqual, https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot-aec
LibJS: Update comments for Annex B changes to IsLooselyEqual This is an editorial change in the ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/da3d674
2022-05-03 21:25:02 +02:00
// 4. Perform the following steps:
// a. If Type(x) is Object and x has an [[IsHTMLDDA]] internal slot and y is either null or undefined, return true.
LibJS: Implement support for the [[IsHTMLDDA]] internal slot Best regards from Annex B and document.all :^)
2021-06-20 17:08:29 +01:00
if (lhs.is_object() && lhs.as_object().is_htmldda() && rhs.is_nullish())
return true;
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
LibJS: Update comments for Annex B changes to IsLooselyEqual This is an editorial change in the ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/da3d674
2022-05-03 21:25:02 +02:00
// b. If x is either null or undefined and Type(y) is Object and y has an [[IsHTMLDDA]] internal slot, return true.
LibJS: Implement support for the [[IsHTMLDDA]] internal slot Best regards from Annex B and document.all :^)
2021-06-20 17:08:29 +01:00
if (lhs.is_nullish() && rhs.is_object() && rhs.as_object().is_htmldda())
return true;
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// == End of B.3.6.2 ==
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 5. If Type(x) is Number and Type(y) is String, return ! IsLooselyEqual(x, ! ToNumber(y)).
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
if (lhs.is_number() && rhs.is_string())
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return is_loosely_equal(vm, lhs, MUST(rhs.to_number(vm)));
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 6. If Type(x) is String and Type(y) is Number, return ! IsLooselyEqual(! ToNumber(x), y).
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
if (lhs.is_string() && rhs.is_number())
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return is_loosely_equal(vm, MUST(lhs.to_number(vm)), rhs);
LibJS: Implement 'in' operator
2020-04-23 16:06:01 +01:00
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// 7. If Type(x) is BigInt and Type(y) is String, then
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs.is_bigint() && rhs.is_string()) {
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// a. Let n be StringToBigInt(y).
LibJS: Make string_to_bigint() a standalone function This now matches the newly added string_to_number().
2022-08-30 10:29:13 +01:00
auto bigint = string_to_bigint(vm, rhs.as_string().string());
LibJS: Implement BigInt loose-equality according to the spec
2022-01-31 10:24:12 -05:00
// b. If n is undefined, return false.
if (!bigint.has_value())
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return false;
LibJS: Implement BigInt loose-equality according to the spec
2022-01-31 10:24:12 -05:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// c. Return ! IsLooselyEqual(x, n).
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return is_loosely_equal(vm, lhs, *bigint);
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 8. If Type(x) is String and Type(y) is BigInt, return ! IsLooselyEqual(y, x).
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs.is_string() && rhs.is_bigint())
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return is_loosely_equal(vm, rhs, lhs);
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 9. If Type(x) is Boolean, return ! IsLooselyEqual(! ToNumber(x), y).
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
if (lhs.is_boolean())
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return is_loosely_equal(vm, MUST(lhs.to_number(vm)), rhs);
LibJS: Implement 'in' operator
2020-04-23 16:06:01 +01:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 10. If Type(y) is Boolean, return ! IsLooselyEqual(x, ! ToNumber(y)).
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
if (rhs.is_boolean())
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
return is_loosely_equal(vm, lhs, MUST(rhs.to_number(vm)));
LibJS: Implement the "instanceof" operator This operator walks the prototype chain of the RHS value and looks for a "prototype" property with the same value as the prototype of the LHS. This is pretty cool. :^)
2020-03-28 16:56:54 +01:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 11. If Type(x) is either String, Number, BigInt, or Symbol and Type(y) is Object, return ! IsLooselyEqual(x, ? ToPrimitive(y)).
LibJS: Support @@toPrimitive in ToPrimitive abstract operation Fixes #3961.
2021-03-02 19:22:36 +01:00
if ((lhs.is_string() || lhs.is_number() || lhs.is_bigint() || lhs.is_symbol()) && rhs.is_object()) {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto rhs_primitive = TRY(rhs.to_primitive(vm));
return is_loosely_equal(vm, lhs, rhs_primitive);
LibJS: Support @@toPrimitive in ToPrimitive abstract operation Fixes #3961.
2021-03-02 19:22:36 +01:00
}
LibJS: Implement the "instanceof" operator This operator walks the prototype chain of the RHS value and looks for a "prototype" property with the same value as the prototype of the LHS. This is pretty cool. :^)
2020-03-28 16:56:54 +01:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 12. If Type(x) is Object and Type(y) is either String, Number, BigInt, or Symbol, return ! IsLooselyEqual(? ToPrimitive(x), y).
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
if (lhs.is_object() && (rhs.is_string() || rhs.is_number() || rhs.is_bigint() || rhs.is_symbol())) {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto lhs_primitive = TRY(lhs.to_primitive(vm));
return is_loosely_equal(vm, lhs_primitive, rhs);
LibJS: Support @@toPrimitive in ToPrimitive abstract operation Fixes #3961.
2021-03-02 19:22:36 +01:00
}
LibJS: Implement the "instanceof" operator This operator walks the prototype chain of the RHS value and looks for a "prototype" property with the same value as the prototype of the LHS. This is pretty cool. :^)
2020-03-28 16:56:54 +01:00
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// 13. If Type(x) is BigInt and Type(y) is Number, or if Type(x) is Number and Type(y) is BigInt, then
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if ((lhs.is_bigint() && rhs.is_number()) || (lhs.is_number() && rhs.is_bigint())) {
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// a. If x or y are any of NaN, +∞𝔽, or -∞𝔽, return false.
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (lhs.is_nan() || lhs.is_infinity() || rhs.is_nan() || rhs.is_infinity())
return false;
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// b. If ℝ(x) = ℝ(y), return true; otherwise return false.
LibJS: Rename Value::{is_integer => is_integral_number} The implementation matches the specification, so lets match the name as well. :^)
2021-06-16 13:17:06 +03:00
if ((lhs.is_number() && !lhs.is_integral_number()) || (rhs.is_number() && !rhs.is_integral_number()))
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return false;
LibJS: Use the new BigInt compare_to_double algorithm :^) Although this is much more complicated it does not seem to impact performance that much even when looking only at values in which the previous casting to i32 was correct.
2022-08-19 23:51:32 +02:00
VERIFY(!lhs.is_nan() && !rhs.is_nan());
auto& number_side = lhs.is_number() ? lhs : rhs;
auto& bigint_side = lhs.is_number() ? rhs : lhs;
LibCrypto: Add a way to compare UnsignedBigInteger with double This patch also make SignedBigInteger::compare_to_double make use of the new function.
2022-10-23 16:46:35 +01:00
return bigint_side.as_bigint().big_integer().compare_to_double(number_side.as_double()) == Crypto::UnsignedBigInteger::CompareResult::DoubleEqualsBigInt;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Fix typo in LHS Object and RHS BigInt loosely equals check Step 12 was using `lhs.is_bigint()` instead of `rhs.is_bigint()`, meaning you got: ```js 1n == Object(1n); // true Object(1n) == 1n; // false ``` This also adds spec comments to is_loosely_equal.
2021-10-15 01:47:54 +01:00
// 14. Return false.
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
return false;
LibJS: Simplify LogStream::operator<<(JS::Value) and move to .cpp file
2020-03-07 21:43:10 +01:00
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 7.2.13 IsLessThan ( x, y, LeftFirst ), https://tc39.es/ecma262/#sec-islessthan
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<TriState> is_less_than(VM& vm, Value lhs, Value rhs, bool left_first)
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
{
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
Value x_primitive;
Value y_primitive;
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
if (left_first) {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
x_primitive = TRY(lhs.to_primitive(vm, Value::PreferredType::Number));
y_primitive = TRY(rhs.to_primitive(vm, Value::PreferredType::Number));
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
} else {
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
y_primitive = TRY(lhs.to_primitive(vm, Value::PreferredType::Number));
x_primitive = TRY(rhs.to_primitive(vm, Value::PreferredType::Number));
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
}
if (x_primitive.is_string() && y_primitive.is_string()) {
auto x_string = x_primitive.as_string().string();
auto y_string = y_primitive.as_string().string();
LibJS: Use Utf8View for string prefix checks This commit replaces the usage of String::starts_with with Utf8View::starts_with, which first decodes the utf8 encoded string, and as such can take things like overlong encoded sequences into account (which could otherwise cause the prefix check to be inconsistent with the following code points check).
2021-03-21 22:33:06 +02:00
Utf8View x_code_points { x_string };
Utf8View y_code_points { y_string };
if (x_code_points.starts_with(y_code_points))
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
return TriState::False;
LibJS: Use Utf8View for string prefix checks This commit replaces the usage of String::starts_with with Utf8View::starts_with, which first decodes the utf8 encoded string, and as such can take things like overlong encoded sequences into account (which could otherwise cause the prefix check to be inconsistent with the following code points check).
2021-03-21 22:33:06 +02:00
if (y_code_points.starts_with(x_code_points))
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
return TriState::True;
Unicode: Try s/codepoint/code_point/g again This time, without trailing 's'. Ran: git grep -l 'codepoint' | xargs sed -ie 's/codepoint/code_point/g
2020-08-05 16:31:20 -04:00
for (auto k = x_code_points.begin(), l = y_code_points.begin();
k != x_code_points.end() && l != y_code_points.end();
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
++k, ++l) {
if (*k != *l) {
if (*k < *l) {
return TriState::True;
} else {
return TriState::False;
}
}
}
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (x_primitive.is_bigint() && y_primitive.is_string()) {
LibJS: Make string_to_bigint() a standalone function This now matches the newly added string_to_number().
2022-08-30 10:29:13 +01:00
auto y_bigint = string_to_bigint(vm, y_primitive.as_string().string());
LibJS: Implement BigInt IsLessThan according to the spec
2022-01-31 10:59:53 -05:00
if (!y_bigint.has_value())
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return TriState::Unknown;
LibJS: Implement BigInt IsLessThan according to the spec
2022-01-31 10:59:53 -05:00
if (x_primitive.as_bigint().big_integer() < (*y_bigint)->big_integer())
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return TriState::True;
LibJS: Implement BigInt IsLessThan according to the spec
2022-01-31 10:59:53 -05:00
return TriState::False;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (x_primitive.is_string() && y_primitive.is_bigint()) {
LibJS: Make string_to_bigint() a standalone function This now matches the newly added string_to_number().
2022-08-30 10:29:13 +01:00
auto x_bigint = string_to_bigint(vm, x_primitive.as_string().string());
LibJS: Implement BigInt IsLessThan according to the spec
2022-01-31 10:59:53 -05:00
if (!x_bigint.has_value())
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return TriState::Unknown;
LibJS: Implement BigInt IsLessThan according to the spec
2022-01-31 10:59:53 -05:00
if ((*x_bigint)->big_integer() < y_primitive.as_bigint().big_integer())
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
return TriState::True;
LibJS: Implement BigInt IsLessThan according to the spec
2022-01-31 10:59:53 -05:00
return TriState::False;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto x_numeric = TRY(x_primitive.to_numeric(vm));
auto y_numeric = TRY(y_primitive.to_numeric(vm));
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
if (x_numeric.is_nan() || y_numeric.is_nan())
return TriState::Unknown;
if (x_numeric.is_positive_infinity() || y_numeric.is_negative_infinity())
return TriState::False;
if (x_numeric.is_negative_infinity() || y_numeric.is_positive_infinity())
return TriState::True;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (x_numeric.is_number() && y_numeric.is_number()) {
if (x_numeric.as_double() < y_numeric.as_double())
return TriState::True;
else
return TriState::False;
}
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (x_numeric.is_bigint() && y_numeric.is_bigint()) {
if (x_numeric.as_bigint().big_integer() < y_numeric.as_bigint().big_integer())
return TriState::True;
else
return TriState::False;
}
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY((x_numeric.is_number() && y_numeric.is_bigint()) || (x_numeric.is_bigint() && y_numeric.is_number()));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
bool x_lower_than_y;
LibJS: Use the new BigInt compare_to_double algorithm :^) Although this is much more complicated it does not seem to impact performance that much even when looking only at values in which the previous casting to i32 was correct.
2022-08-19 23:51:32 +02:00
VERIFY(!x_numeric.is_nan() && !y_numeric.is_nan());
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (x_numeric.is_number()) {
LibJS: Use the new BigInt compare_to_double algorithm :^) Although this is much more complicated it does not seem to impact performance that much even when looking only at values in which the previous casting to i32 was correct.
2022-08-19 23:51:32 +02:00
x_lower_than_y = y_numeric.as_bigint().big_integer().compare_to_double(x_numeric.as_double())
LibCrypto: Add a way to compare UnsignedBigInteger with double This patch also make SignedBigInteger::compare_to_double make use of the new function.
2022-10-23 16:46:35 +01:00
== Crypto::UnsignedBigInteger::CompareResult::DoubleLessThanBigInt;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
} else {
LibJS: Use the new BigInt compare_to_double algorithm :^) Although this is much more complicated it does not seem to impact performance that much even when looking only at values in which the previous casting to i32 was correct.
2022-08-19 23:51:32 +02:00
x_lower_than_y = x_numeric.as_bigint().big_integer().compare_to_double(y_numeric.as_double())
LibCrypto: Add a way to compare UnsignedBigInteger with double This patch also make SignedBigInteger::compare_to_double make use of the new function.
2022-10-23 16:46:35 +01:00
== Crypto::UnsignedBigInteger::CompareResult::DoubleGreaterThanBigInt;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
if (x_lower_than_y)
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
return TriState::True;
else
return TriState::False;
}
LibJS: Update spec numbers for Operations on Objects AOs The error cause proposal was merged, so some spec numbers were bumped.
2021-12-21 08:27:04 -05:00
// 7.3.21 Invoke ( V, P [ , argumentsList ] ), https://tc39.es/ecma262/#sec-invoke
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
ThrowCompletionOr<Value> Value::invoke_internal(VM& vm, PropertyKey const& property_key, Optional<MarkedVector<Value>> arguments)
LibJS: Move Object::invoke to Value::invoke and fix it for primitives 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.
2021-08-09 16:45:43 +02:00
{
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
auto property = TRY(get(vm, property_key));
LibJS: Convert Value::invoke and VM::call to ThrowCompletionOr
2021-09-23 20:56:28 +03:00
if (!property.is_function())
LibJS: Remove GlobalObject from VM::throw_completion() This is a continuation of the previous five commits. A first big step into the direction of no longer having to pass a realm (or currently, a global object) trough layers upon layers of AOs! Unlike the create() APIs we can safely assume that this is only ever called when a running execution context and therefore current realm exists. If not, you can always manually allocate the Error and put it in a Completion :^) In the spec, throw exceptions implicitly use the current realm's intrinsics as well: https://tc39.es/ecma262/#sec-throw-an-exception
2022-08-16 20:33:17 +01:00
return vm.throw_completion<TypeError>(ErrorType::NotAFunction, property.to_string_without_side_effects());
LibJS: Move Object::invoke to Value::invoke and fix it for primitives 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.
2021-08-09 16:45:43 +02:00
LibJS: Replace GlobalObject with VM in common AOs [Part 18/19]
2022-08-21 19:24:32 +01:00
return call(vm, property.as_function(), *this, move(arguments));
LibJS: Move Object::invoke to Value::invoke and fix it for primitives 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.
2021-08-09 16:45:43 +02:00
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Reference in a new issue Copy permalink