It's a little awkward that one caller of this is passing through an
Optional<String> and another an Optional<DeprecatedString>, but that
should be fixed some point in the future with further DeprecatedString
porting.
No IDL file pulls in these requiring DeprecatedString support, so we
are now able to remove these functions! :^)
Also leave a FIXME while we are at it, as ideally this function would
take an Optional<FlyString> - but the IDL generator does not currently
support this.
These were DeprecatedFlyStrings, but had no reason to be. We were not
making use of the O(1) lookup, so instead of porting it over to a
FlyString, just make it a StringView.
This is the API for NamedNodeMap which we are wanting to eventually use
instead of taking a StringView. Currently we just end up deferring to
the StringView versions of these functions, but at some stage in the
future, this will allow us to have O(1) comparison when making attribute
lookups.
In the meantime, the advantage of this API is that it makes it much less
awkward to use than the StringView variant when you have an
Optional<FlyString> namespace to pass through.
The original value 15 was too little: it made our
`weighted_boolean_fair_false` test fail every now and then.
This is because a fair coin (P(false) = 0.5) will hit the same value 15
times in a row with a probability (1/2)^15: around once in a 32k tries.
With the bumped up value, this is now once in 1 billion tries. Should
lower the test flakiness enough (if our random number generator is
truly uniform), while 30 tries is still an OK amount of computation for
randomized tests to do, compared to 15.
Now that x86-specific Assembler will be compiled on every architecture
we can't rely on void* being the right width.
It also fixes compilation on targets which have void*
be different length from u64 (WASM in particular).
This is in preparation for making LibJIT support multiple architectures.
Assembler will now be typedefed to the specific assembler
for a particular architecture.
Additionally, there's now JIT_ARCH_SUPPORTED which is defined on
architectures which LibJIT supports.
This makes JS::JIT::Compiler less architecture-specific
and unifies aligning the stack into a single operation,
where previously we were doing it separately for preserved registers
and for stack arguments.
* Compare array size to 3 and 4, not 4 and 5
* Fix literal typo in error message
Fixes crash processing 0000906.pdf from 0000.zip from the pdf/a dataset.
Representing a text run panting command as a vector of glyphs, rather
than as a string simplifies collecting of unique glyphs which is a
prerequisite for `prepare_glyphs_texture()` call.
Text painting operates in two steps:
1. Preparation of a texture that contains all the glyphs required for
text painting, along with metadata that describes the locations of
those glyphs within texture beforehand.
2. Blitting glyphs from the prepared texture onto corresponding glyph
quads.
Users of LibAccelGfx will need to call `prepare_glyphs_texture()`,
passing a set of all unique (font, code_paint) pairs, before painting
any text.
This change separates a part of the `draw_text_run()` function, which
is responsible for calculating the positions for glyphs that need to be
painted, into a separate function called `get_glyph_run()`.
It is a part of the preparation for text run painting using OpenGL,
where we can't immediately blit glyph bitmaps but instead need to
prepare a sequence of quads for them in advance.
Previously, `URLParser` was constructing a new String for every
character of the URL's username and password. This change improves
performance by eliminating those unnecessary String allocations.
A URL with a 100,000 character password can now be parsed in ~30ms vs
~8 seconds previously on my machine.
This warning warns about variable-length arrays being a non-standard
extension to the C++ language. We still have a few instances of VLAs, so
let's disable the warning for now.
This does not interfere with `-Wvla`, which we use to completely forbid
this (potentially dangerous) feature in the Kernel and LibCrypto.
Since 2023-09-08, Clang trunk has had a bug which causes a segfault when
evaluating certain `requires` expressions inside templated lambdas.
There isn't an imminent fix on the horizon, so let's work around the
issue by specifying the type of the offending lambda arguments
explicitly.
See https://github.com/llvm/llvm-project/issues/67260
Using ErrorType::ReferencePrimitiveSetProperty the errors for primitives
now look like "Cannot set property 'foo' of number '123'".
The strict-mode-errors test has been adjusted and re-enabled.
In case of {get func() {}, set func() {}} we were wrongly setting the
function name to 'func' and then later trying to replace an empty name
with 'get func'/'set func' which failed.
Instead, set the name to 'get func'/'set func' right away.
The code in put_by_property_key is kept, for when that is called
by put_by_value.
