test-js crashes with a segmentation fault when running on macOS on Arm.
Increasing the margin in the test in did_reach_stack_space_limit() to
32 * KiB makes the tests pass. To simplify the code, this is applied
independently of platform, and the previous test for use of an address
sanitizer is removed.
That's an old yak :^)
No, past me, AST nodes do not need to learn to stringify themselves.
This is now massively simplified by using the [[SourceText]] internal
slot.
Also updates a bunch of tests that are incorrect due to the old
implementation not being spec compliant, and add plenty more.
Similar to the bitwise_and change, but we have to be careful to
sign-extend two's complement numbers only up to the highest set bit
in the positive number.
Bitwise and is defined in terms of two's complement, so some converting
needs to happen for SignedBigInteger's sign/magnitude representation to
work out.
UnsignedBigInteger::bitwise_not() is repurposed to convert all
high-order zero bits to ones up to a limit, for the two's complement
conversion to work.
Fixes test262/test/language/expressions/bitwise-and/bigint.js.
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()).
Performance of string concatenation regressed in a57e2f9. That commit
iterates over the LHS string to find the last code unit, to check if it
is a high surrogate. Instead, first look at the 3rd-to-last byte in the
UTF-8 encoded string to check if it is a 3-byte code point; then decode
just those bytes to check if we have a high surrogate. Similarly, check
the first 3 bytes of the RHS string to check if we have a low surrogate.
In the following use case:
"\ud834" + "\udf06"
We were previously combining these as two individual code points. When
concatenating strings, we must take care to combine the high surrogate
from the left-hand side with the low surrogate from the right-hand side.
This was already implemented and duplicated across the
String.prototype.trim{, Start, End} methods, so this simply extracts it
into a separate method that can also be used by other users.
The spec says:
27.5.1.1 Generator.prototype.constructor
https://tc39.es/ecma262/#sec-generator.prototype.constructor
The initial value of Generator.prototype.constructor is
%GeneratorFunction.prototype%.
But we had it set to %GeneratorFunction% (the GeneratorFunction
constructor).
Given we usually call objects Foo{Object,Constructor,Prototype} or
Foo{,Constructor,Prototype}, this name was an odd choice.
The new one matches the spec better, which calls it the "Generator
Prototype Object", so we simply omit the Object suffix as usual as it's
implied.
The three major changes are:
- Parsing parameters, the function body, and then the full assembled
function source all separately. This is required by the spec, as
function parameters and body must be valid each on their own, which
cannot be guaranteed if we only ever parse the full function.
- Returning an ECMAScriptFunctionObject instead of a FunctionExpression
that needs to be evaluated separately. This vastly simplifies the
{Async,AsyncGenerator,Generator,}Function constructor implementations.
Drop '_node' from the function name accordingly.
- The prototype is now determined via GetPrototypeFromConstructor and
passed to OrdinaryFunctionCreate.
This should have been the default as it roughly represents the
OrdinaryFunctionCreate AO.
For now, keep two overloads and continue to guess the required prototype
from the function kind in most cases. The prototype needs to be passed
in explicitly when it may be derived from user code, such as in the
CreateDynamicFunction AO.
The parentheses are dealt with outside this function, so we shouldn't
use the (non)existence of one as the condition for consuming another
comma and then parameter. Just check for a comma instead. This becomes
relevant when parsing standalone function parameters as per the spec in
the CreateDynamicFunction AO.
The curly braces are not part of the FunctionBody production. This
becomes relevant when parsing a standalone function body as per the spec
in the CreateDynamicFunction AO.
Implementing years_to_days_since_epoch without a loop will be tricky.
The TimeFromYear AO gives a good enough approximation for MakeDay until
we figure that out.
