The big changes are:
- Allow strings as Module{Export, Import}Name
- Properly track declarations in default export statements
However, the spec is a little strange in that it allows function and
class declarations without a name in default export statements.
This is quite hard to fully implement without rewriting more of the
parser so for now this behavior is emulated by faking things with
function and class expressions. See the comments in
parse_export_statement for details on the hacks and where it goes wrong.
This also refactors interpreter creation to follow
InitializeHostDefinedRealm, but I couldn't fit it in the title :^)
This allows us to follow the spec much more closely rather than being
completely ad-hoc with just the parse node instead of having all the
surrounding data such as the realm of the parse node.
The interpreter creation refactor creates the global execution context
once and doesn't take it off the stack. This allows LibWeb to take the
global execution context and manually handle it, following the HTML
spec. The HTML spec calls this the "realm execution context" of the
environment settings object.
It also allows us to specify the globalThis type, as it can be
different from the global object type. For example, on the web, Window
global objects use a WindowProxy global this value to enforce the same
origin policy on operations like [[GetOwnProperty]].
Finally, it allows us to directly call Program::execute in perform_eval
and perform_shadow_realm_eval as this moves
global_declaration_instantiation into Interpreter::run
(ScriptEvaluation) as per the spec.
Note that this doesn't evalulate Source Text Modules yet or refactor
the bytecode interpreter, that's work for future us :^)
This patch was originally build by Luke for the environment settings
object change but was also needed for modules. So I (davidot) have
modified it with the new completion changes and setup for that.
Co-authored-by: davidot <davidot@serenityos.org>
Mostly slapping "timeZone: UTC" on DateTimeFormat tests (we have other
tests for specific time zones). Also pick dates that are not on DST
boundaries in some time zones where that matters.
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.
