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
This was left behind when removing the AST interpreter, and the CI not
being around made it bitrot.
Co-Authored-By: Dan Klishch <danilklishch@gmail.com>
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.
This will be a foundational part of bootstrapping generators: this is
the way they'll get prerecorded values from / record random values into
RandomRuns. (Generators don't get in contact with RandomRuns
themselves, they just interact with the RandomnessSource.)
To be used later by generators and during shrinking.
The generators used in randomized tests will record the drawn random
bits into a RandomRun. This is a layer of indirection that will help us
automatically shrink any generated value without any user input. (Having
to provide manually defined shrinkers is a downside to many randomized /
property-based testing libraries like QuickCheck for Haskell.)
This will be used in the randomized tests a lot more than it is in the
unit tests / benchmarks; randomized tests will run the test function
multiple times, check the result and optionally start shrinking the
failing input. Generators will also be able to fail, resulting in some
of the new TestResult variants.
This is the only instance of `*OS's` in the repo that does not use `s`
after the apostrophe.
Generally, the saxon genitive for singular nouns is always written as
`'s` even if they end in `s`.
Currently finding a particular glyph with a given code point is
a bit tedious as it requires clicking on the glyph to update the
status bar and display the glyph's name and codepoint. A more
convenient way to know where we are in the Glyph Map is by seeing
a tooltip over the glyph where the mouse is currently hovering over.
This patch adds that support by setting the Widget tooltip with the
glyph found at the current position in GlyphMapWidget::mousemove_event.
