Even though calling delete on a super property will ultimately throw a
ReferenceError, we must return the allocated register for the result of
the delete operation (which would normally be a boolean). If the delete
operation is used in a return statement, the bytecode generator for the
return statement must be able to assume the statement had some output.
In order for public/private key serialization to work correctly we must
store the size of the key because P-521 cannot be stored as full words
inside `UnsignedBigInteger` and therefore is exported as the wrong
length (68 instead of 66).
This makes it also possible to refactor some methods and cleanup
constants scattered around.
Gets almost all import/export tests, expect the JWK ones that calculate
the public key on export. The `SECPxxxr1` implementation currently fails
to do calculations for P-521.
Define SECP521r1 with its constants. Since the parameters cannot be
represented as full bytes, a slight modification has been added to the
byte size.
The current implementation of SECPxxxr1 does not work with this curve.
Tests with different combinations of missing width, height
and viewBox.
All tests confirmed to work on Ladybird:
- exactly the same as Chromium (131.0.6778.85)
- almost the same as Firefox (129.0.2)
- only difference: standalone-w.svg: same size, different alignment
For example, for the following `includes` line in a test262 file:
includes: [sm/non262-TypedArray-shell.js, sm/non262.js]
We currently parse and execute each file in this list as its own script,
in the order they appear in the list.
Tests have recently been imported test262 from SpiderMonkey which fail
with this behavior. In the above example, if the first script references
some function from the second script, we will currently fail to execute
that harness file.
This patch changes our behavior to concatenate all harness files into a
single script, which satisfies the behavior required by these new tests.
This is how test262.fyi and other test262 runners already behave.
Make use of TRY semantics a bit more. And we don't need to store harness
files as a ByteString - we can store the contents as the ByteBuffer that
we receive from reading the file.
