There are a lot of native C++ functions that will be used by both the
bytecode interpreter and jitted code. Let's put them in their own file
instead of having them in Interpreter.cpp.
This necessitated making the JIT::Compiler aware of the current
Bytecode::Executable, since that's where all the string literals are
held, but that seems like a good thing.
These push a "valid" unwind context on the stack and check_exception()
now knows how to jump to the (catch) handler if present.
(finally) finalizers will require some more work, but with this change,
we now have basic support for try...catch. :^)
We now establish a stack of "unwind contexts" similar to what the
bytecode interpreter does, but here, it's a stack of structs with
addresses to the catch and finally blocks.
Unwind contexts also have a "valid" flag, and the root unwind context
(always present, pushed on JIT code entry) has valid=false, which we
interpret in check_exception() as "return and let our caller deal with
the exception".
Anything in Compiler that may generate an exception should now also
call check_exception() ASAP to emit the code for handling this.
Nothing in PDF 1.7 spec 8.2.1 Destinations mentions the page being
`null`, but it happens in 0000372.pdf (for the root outline element)
and in 0000776.pdf (for every outline element, which looks like a
bug in the generator maybe) of 0000.zip from the pdfa dataset.
This patch brings a service to handle image decompression. With it comes
security enhancement due to the process boundary. Indeed, consequences
of a potential attack is reduced as only the decoder will crash without
perturbing the WebContent process.
It also allows us to display pages containing images that we claim to
support but still make us crash, like for not-finished-yet decoders.
As an example, we can now load https://jpegxl.info/jxl-art.html without
crashing the WebContent process.
This library offers tools to communicate with an ImageDecoder server
through IPC. There is currently no such executable for Lagom but that
shouldn't take long :^)
Changing `try_compute_width()` to return width and margins, instead of
mutating them in the box's state makes it works in cases when box has
min-width or max-width and this function needs to be called multiple
times.
Fixes https://github.com/SerenityOS/serenity/issues/21598
Tests defined like
RANDOMIZED_TEST_CASE(test_name)
{
GEN(dice, Gen::unsigned_int(1,6));
EXPECT(dice >= 1 && dice <= 6);
}
will be run many times (100x by default, can be overriden with
MAX_GENERATED_VALUES_PER_TEST), each time generating different random
values, and if any of the test runs fails, we'll shrink the generated
values and report the final minimal ones to the user.
ShrinkCommands are recipes for how a RandomRun should be shrunk. They
are not related to a specific RandomRun, although we'll take the length
of a specific RandomRun into account when generating the ShrinkCommands.
ShrinkCommands will later be interpreted by the shrink_with_command()
function.
Generators are callable as-is:
u32 my_int = Gen::unsigned_int(); // -> 1, 5, 8, 3, 2
But there is little visibility in the test fail message into what went
wrong. Showing what values were generated helps a lot, and that's what
this macro does:
GEN(my_int, Gen::unsigned_int());
expands into the above declaration and (crucially) a conditional
warnln() call looking like "my_int = {}". It will only run if error
reporting is enabled (see Test::can_report()), so it will only give the
final shrunk value instead of spamming the output with each generated
value.
REJECT and ASSUME are useful for filtering out unwanted generated
values. While this is not ideal, it is ocassionally useful and so we
include it for convenience.
The main loop of RANDOMIZED_TEST_CASE runs the test case 100 times, each
time trying to generate a different set of values. Inside that loop, if
it sees a REJECT (ASSUME is implemented in terms of REJECT), it retries
up to 15 times before giving up (perhaps it's impossible or just very
improbable to generate a value that will survive REJECT or ASSUME).
REJECT("Reason for rejecting") will just outright fail, while
ASSUME(bool) is more of an equivalent of a .filter() method from
functional languages.
This will be very useful as we add the randomized test cases and their
two loops ("generate+test many times" and "shrink once failure is
found"), because without this failure reporting we'd get many FAIL error
messages while still searching for the minimal one.
So, inside randomized test cases we want to only turn the error
reporting on for one last time after all the generating and shrinking.
These functions all plug into RandomnessSource and produce random values
of various types. They are to be used either inside other generator
definitions or inside the GEN(...) macro when used in tests.
