We have close to zero usages of the C string functions in our codebase
(including the "safe" alternatives), so the deprecation warnings are
unlikely to have an actual effect on preventing large-scale use of the
"unsafe" functions.
Meanwhile, the deprecation warnings are causing issues for ports that
are compiled using -Werror by default, and are generally a large source
for logspam when compiling.
I accidentally skipped this part of the spec in the QOI decoder:
> The alpha value remains unchanged from the previous pixel.
This led to incorrect rendering of some images with transparency,
visible in form of a horizontal line of non-transparent pixels (that
shouldn't exist), e.g. for the following chunk sequence:
- QOI_OP_RGBA with alpha = 0
- QOI_OP_RGB
- QOI_OP_RUN
The QOI_OP_RGB should 'inherit' the alpha value of the previous
QOI_OP_RGBA chunk, instead of always setting it to 255.
I'm unsure why the encoder added the QOI_OP_RGB chunk to the specific
image where the bug was noticed in the first place - they effectively
both had fully transparent color values.
This wasn't quite following what the spec says for step 2:
"If index is −1, then remove the last element in the rows collection
from its parent, or do nothing if the rows collection is empty."
It was behaving like:
"If index is −1 and the rows collection is not empty, then remove the
last element in the rows collection from its parent."
Which is not the same, as it will fall into the "Otherwise" if
`index == -1` and the rows collection is empty and try and get the -2nd
element of the rows.
Found with Domato.
Step 1 of the spec is to capture the <script> element's node document
into a local variable.
When I originally implemented this, I thought this was not necessary.
However, I realised that the script that runs can adopt the current
script element into a different document, meaning step 5.4 and 6 then
operate on the incorrect document.
Covered by this WPT: 7b0ebaccc6/html/semantics/scripting-1/the-script-element/moving-between-documents-during-evaluation.html
Previously, we would use lossy strtod() conversion. This was bad,
especially since we switched from internally storing Calculator
state in a double to storing it in the KeypadValue class
some time ago. This commit adds a constructor for the KeypadValue
class that is not lossy by using strtoll(). It handles numbers
with and without decimal points as well as negative numbers
correctly.
In order to reduce our reliance on __builtin_{ffs, clz, ctz, popcount},
this commit removes all calls to these functions and replaces them with
the equivalent functions in AK/BuiltinWrappers.h.
...by flattening the underlying bytecode chunks first.
Also avoid calling DisjointChunks::size() inside a loop.
This is a very significant improvement in performance, making the
compilation of a large regex with lots of alternatives take only ~100ms
instead of many minutes (I ran out of patience waiting for it) :^)
The generated data for libunicodedata.so is quite large, and loading it
is a price paid by nearly every application by way of depending on
LibRegex. In order to defer this cost until an application actually uses
one of the surrounding APIs, dynamically load the generated symbols.
To be able to load the symbols dynamically, the generated methods must
have demangled names. Typically, this is accomplished with `extern "C"`
blocks. The clang toolchain complains about this here because the types
returned from the generators are strictly C++ types. So to demangle the
names, we use the asm() compiler directive to manually define a symbol
name; the caveat is that we *must* be sure the symbols are unique. As an
extra precaution, we prefix each symbol name with "unicode_". For more
details, see: https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html
This symbol loader used in this implementation provides the additional
benefit of removing many [[maybe_unused]] attributes from the LibUnicode
methods. Internally, if ENABLE_UNICODE_DATABASE_DOWNLOAD is OFF, the
loader is able to stub out the function pointers it returns.
Note that as of this commit, LibUnicode is still directly linked against
LibUnicodeData. This commit is just a first step towards removing that.
Loading libunicodedata.so will require dlopen(), which in turn requires
mmap(). The 'prot_exec' pledge is needed for this.
Further, the .so itself must be unveiled for reading. The "real" path is
unveiled (libunicodedata.so.serenity) as the symlink (libunicodedata.so)
itself cannot be unveiled.
Remove note about CMake Tools as version 1.9.0 has shipped and no longer
needed. Update details for files to latest versions and allow easier
copy and paste into an empty file.
This is a deprecated feature that is still in use in some older games,
most notably Grim Fandango in ScummVM makes heavy use of it.
Luckily, since you can only draw convex polygons, the end result is
exactly the same as when you would have used `glBegin(GL_TRIANGLE_FAN)`
- so we just reuse that code as-is.
