This change will make it easier to disable screenshot comparison tests
on a specific platform or have per-platform expectations.
Additionally, it's nice to be able to tell if a ref-test uses a
screenshot as an expectation by looking at the test path.
The EntryType has three possible values: Fetching, Failed or
ModuleScript. It is possible that we transition from Fetching to Failed
as in #13.1. Change the assertion to include the failed scenario.
Fixes: https://github.com/LadybirdBrowser/ladybird/issues/661
GCC 14 emits a warning when an always succeeding `dynamic_cast`'s return
value is compared to NULL inside the `AK::is<T>(U)` template when `T` ==
`U`.
While warning on tautological `is` calls seems useful, it's a bit
awkward when it comes from a function template where the cast may fail
in some instantiation. There is a GCC bug open for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115664
Work around the warning by performing the algorithm on the base type
(`EventTarget`), with a wrapper that casts it to the more specialized
input type.
Utf16View currently assumes host endianness. Add support for specifying
either big or little endianness (which we mostly just pipe through to
simdutf). This will allow using simdutf facilities with LibTextCodec.
Override the vcpkg/scripts/detect_compiler behavior of always pulling
$CC and $CXX at the time that vcpkg install is determined to need called
by forcing $ENV{CXX} and $ENV{CC} to our CMake-determined compiler.
This prevents strange behavior such as running the following:
./Meta/ladybird.sh run
make changes...
ninja -C Build/ladybird
Where the second build step would be run without CC or CXX set in the
environment, causing a total cache miss from vcpkg and a full rebuild.
It also helps prevent full rebuilds when an IDE passes a slightly
different compiler to the build step than ladybird.sh.
The one behavior difference is that we will now actually fail on invalid
code units with Utf16View::to_utf8(AllowInvalidCodeUnits::No). It was
arguably a bug that this wasn't already the case.
AK will depend on some vcpkg dependencies, so the Lagom tools build will
need to know how to use vcpkg. We can do this by sym-linking vcpkg.json
to Meta/Lagom (as vcpkg.json has to be in the CMake source directory).
We also need a CMakePresets.json in the source directory, which can just
include the root file. The root CMakePresets then needs to define paths
relative to ${fileDir} rather than ${sourceDir}.
