Else, outline items that have newlines in them end up with a weird
vertical offset.
(This does affect the outline item's tooltip, which shows the whole
title. But not having a newline there seems alright, arguably
preferable.)
The title of an OutlineItem is already in UTF-8.
This is currently done in LibPDF's Parser::parse_string(). I think
that's not quite the right place (it shouldn't be done for all strings)
and not done quite right (text strings should convert from
PDFDocEncoding to UTF-8 unless prefixed by an UTF-8 BOM), but even if
that changes, I think we'll keep OutlineItem.title in UTF-8.
Implemented by adding the extra 3-value syntax as its own case and only
running it when parsing background-position. I'm sure it could be
implemented in a smarter way but this is still a bunch less code than
before. :^)
This means `object-position` will no longer incorrectly accept the
3-value background-position syntax.
Remove the now-ambiguous and unused `position` enum while we're at it.
(This enum only existed as a hack.)
With this change, we now have ~1200 CellAllocators across both LibJS and
LibWeb in a normal WebContent instance.
This gives us a minimum heap size of 4.7 MiB in the scenario where we
only have one cell allocated per type. Of course, in practice there will
be many more of each type, so the effective overhead is quite a bit
smaller than that in practice.
I left a few types unconverted to this mechanism because I got tired of
doing this. :^)
Whenever the tests produce a `test-dumps` directory, publish the files
in it as an artifact. This lets us peek at the screenshots and see
what's mismatched, instead of just having to guess.
The current implementation fails if a file in the archive is not valid
UTF-8. The CLDR 44.0.1 package unfortunately contains such files (it
errantly has .DS_Store files).
If a unit tests defines a `deps` array, the unit test template would
have tried to overwrite it (and it is actually an error to overwrite
a non-empty list with another non-empty list).
FP contraction is a standard-conforming behavior which allows the
compiler to calculate intermediate results of expressions containing
floating point numbers with a greater precision than the expression type
allows. And in theory, it enables additional optimizations, such as
replacing `a * b + c` with fma(a, b, c).
Unfortunately, it is extremely hard to predict when the contraction will
happen. For example, Clang 17 on x86_64 with the default options will
use FMA only for constant-folded non-constexpr expressions. So, in
practice, FP contraction leads to hard-to-find bugs and inconsistencies
between executables compiled with different toolchains or for different
OSes. And we had two instances of this happening last week.
Since we did not ever used -mfma on x86_64, this patch can only possibly
regress performance on Apple ARM devices, where FMA is enabled by
default. However, this regression will likely be negligible since the
difference would be one additional add instruction, which would be then
likely executed in parallel with something else.
With these changes it is now possible to create OpenGL context on macOS
and run GPU-painter. For now only QT client has a CLI param that turns
it on though.
This is a bit spammy now that we are performing some overload resolution
at build time. The fallback to an interface has generally worked fine on
the types it warns about (BufferSource, Module, etc.) so let's not warn
about it for every build.
Previously, a DNS packet containing an invalid name would be returned
with an empty name. With this change, an error is returned if any error
is encountered during parsing.
Aside from the obvious performance benefits, this will allow us to
properly handle dictionary types. (whose dictionary-ness is only known
at build-time)
Much of the rest of the overload resolution algorithm steps can (and
should) be evaluated at build-time as well, but this is a good first
step.
* Count files that are password-protected
* Use `pdf --json` to groups by missing feature and then by file
instead of by file first, feature second
* Count files that render with issues
* Print number of files without issues last
* Always print all crash stacks
Fix the recursive directory bug in CLion Nova EAP's CMake version in a
way that doesn't also break `./Meta/serenity.sh run lagom ladybird`.
This brings the Lagom minimum required closer to the Serenity minimum
required. Which is still fine, because the serenity.sh script knows how
to build CMake from source if a developer's local copy is too old.
Ran into this with the new EAP for CLion Nova. When using Ladybird as
source directory, we would recursively look in Ladybird --> Lagom -->
Ladybird when exporting components. This seems to be because
ENABLE_LAGOM_LADYBIRD is set to ON by Ladybird's CMakeLists and
something about their build, when invoked from their IDE, has buggy
behavior around the SUBDIRECTORIES directory property.
When wrapping dictionary members, generate_wrap_statement was called
with the pattern "auto {} = ...", where "..." was determined based on
the variable's type. However, in generate_wrap_statement, if a type is
nullable it generates an if statement, so this would end up generating
something along the lines of
if (!retval.member.has_value()) {
auto wrapped_member0_value = JS::js_null();
} else {
auto wrapped_member0_value = JS::Value(...);
}
...which makes the declaration inaccessible. It now generates the same
code, but the "auto" declaration (now an explicit JS::Value declaration)
is outside of the if-statement.
This commit replaces the 5 fuzzers that previously tested LibTextCodec
with a single fuzzer. We now rely on the fuzzer to generate the
encoding and separate it from the encoded data with a magic separator.
This increases the overall coverage of LibTextCodec and eliminates the
possibility of the same error being generated by multiple fuzzers.
When building fuzzers for Oss-Fuzz using `BuildFuzzers.sh --oss-fuzz`,
fuzzer dictionary files are now copied to the `$OUT` directory. This
allows them to be used automatically by the corresponding fuzzer.
LibCore currently cannot depend on LibTimeZone directly. All build-time
code generators depend on LibCore, so there'd be a circular dependency:
LibCore -> LibTimeZone -> GenerateTZData -> LibCore.
So to support parsing time zone names and applying their offsets, add a
couple of weakly-defined helper functions. These work similar to the way
AK::String declares some methods that LibUnicode defines. Any user who
wants to parse time zone names (from outside of LibCore itself) can link
against LibTimeZone to receive full support.
