These cases were found with GCC's `-Wsuggest-final-{types,methods}`
warnings, which catch calls that could have been devirtualized had we
declared the functions `final` in the source.
To reproduce, Link Time Optimization needs to be enabled. The easiest
way to achieve this is to set the `CMAKE_INTERPROCEDURAL_OPTIMIZATION`
cache variable to `ON`. The `.incbin` directive in LibCompress' Brotli
decompressor might needs to be changed to an absolute path for this to
work.
This commit also removes a pair of unused virtual functions.
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
This utility is actually a symlink to the gunzip utility.
The gunzip utility is modified to enable writing to stdout when running
through the zcat symlink, to emulate the same behavior on other OSes.
In addition to that, the gunzip utility is now required on a default
installation as it could be a vital utility under some conditions (for
example, downloading source code in a tar.gz file).
These variants make the choice to terminate the process a compile-time
decision rather than a runtime-configurable setting through
`UBSAN_OPTIONS`. As the compiler can treat any code following these
UBSan handler calls as dead code, it allows for significant
optimizations, such as removing redundant UBSan checks and not needing
to worry about saving volatile registers before calling these.
Generation of this kind of instrumentation can be enabled with
`-fsanitize=undefined -fno-sanitize-recover=undefined`. Build system
support will come in a separate PR.
There is no sensible recovery possible from non-void functions that
fail to return a value, or from `__builtin_unreachable()` being reached,
all bets are off once they happened. This is why LLVM's libsanitizer
treats these as always fatal, even if all other UBSan checks are made
recoverable with `-fsanitize-recover`. The codegen already assumes that
these handlers will not return.
Before, navigator.platform would always report the platform as "Serenity
OS", regardless of whether or not that was true. It also did not include
the architecture, which Firefox and Chrome both do. Now, it can report
either "Linux x86_64" or "SerenityOS AArch64".
There's the "font_type" property which currently only handles
fixed-width yes/no, so until we get a proper font type enum and
associated enum property, this is better to use from GML instead of a
special case in the GML compiler.
This encoder can handle all integer formats and sample rates, though
only two channels well. It uses fixed LPC and performs a
close-to-optimal parameter search on the LPC order and residual Rice
parameter, leading to decent compression already.
This interface is very simple for the time being and can be used to
provide encoding functionality in a generalized way. Initialization and
parameter setting are intentionally not abstracted for now, since this
is usually very format-specific. We just need a general interface for
writing samples and errorable finalization.
Just like with input buffered streams, we don't currently have a use
case for output buffered streams which aren't seekable, since the main
application are files.
This allows to compare CSSPixels with AvailableSize without converting
it to CSSPixels, which might leak saturated (infinite) values into
layout calculations.
More error propagation is still needed, we really want the parser to
just crash early when it encounters unexpected input, instead of trying
to carry on like nothing happened.
I think ErrorOr<unsigned> is *much* better than returning (unsigned)-1
to indicate an error ;)
We're now sniffing the incoming data to verify the server has sent a
full response, instead of passing partial data to our IMAP parser.
Our parser really can't handle partial input very well, so for the time
being, this heuristic does a much better job of verifying we have full
response before parsing.
It doesn't yet handle unprompted untagged reponses, nor the
"continuation request" responses that start with a `+`, but we don't
fully support those yet.
I couldn't run the parser in a debugger like I normally would, so I
added printouts to understand where the parser is failing.
More could be added, but these are enough to get a good idea of what
the parser is doing. It's very spammy, though, so enable it by flicking
the IMAP_PARSER_DEBUG switch :^)
