Computing the table width algorithm bifurcates based on whether
table-root width is auto. We only adjust the used table width based on
cell percentage widths on the auto branch, thus the same check is needed
when we initialize cell widths.
This makes them trivially copyable, which is an assumption multiple
optimizations use when rebuilding the instruction stream.
This fixes most optimized crashes in the test262 suite.
See https://github.com/tc39/ecma262/commit/874ecf9
After this refactoring, we now correctly handle non-function /
non-undefined objects being passed multiple times: instead of skipping
assignment to promiseCapability altogether and failing with a
NotAFunction error in the end; on the second time the executor closure
is called, we return GetCapabilitiesExecutorCalledMultipleTimes.
This fixes the 7 `capability-executor-called-twice.js` test262 tests.
These recursive templates have a measurable impact on the compile speed
of Variant-heavy code like LibWeb. Using these builtins leads to a 2.5%
speedup for the measured compilation units.
Cell percentage widths are relative to table width, not containing
block width. If the table width is auto, there isn't a normative
specification, only a brief mention that the user agent should try to
meet it.
As a starting point, we increase the width of the table such that it's
sufficient to cover min-width of cells with a percentage width. This
matches the behavior of other browsers, at least for simple cases.
We do this by moving the `LoadImmediate undefined` instruction to a
separate basic block which jumps to the case's block unconditionally.
We enter a case initially using this wrapper, but when falling through,
we directly jump to the next case's block.
oss-fuzz ships a pre-release commit of clang-15 for all of their build
bots. Until they update to a release of clang-15 that includes the fix
for this bug, or a later release, we need to keep the workaround in
place.
This adds support for exporting class expressions, which was previously
TODO'd.
We now correctly set the binding name of exports to `"*default*"` if
they are unnamed. I'm not sure what the difference between the
`InitializationMode` kinds is, but using `Initialize` fixes a bunch of
tests.
Note that some export tests (e.g. `eval-export-dflt-expr-cls-named.js`)
still fail, as we don't set the "name" property of exported classes
correctly.
176 new passes on test262
Instead of using ifdefs to use the correct platform-specific methods, we
can just use the same pattern we use for the microseconds_delay function
which has specific implementations for each Arch CPU subdirectory.
When linking a kernel image, the actual correct and platform-specific
power-state changing methods will be called in Firmware/PowerState.cpp
file.
The immutability of the string is not relevant here, since the string
we're given was allocated in the IPC serialization layer and will be
destroyed shortly afterwards. Additionally, noone relies on
DeprecatedString-specific functionality. This will make it easier to
convert the IPC layer itself to String later on.
This removes a lot of duplicated stream creation code from the plugins,
and also simplifies the way that the appropriate plugin is found. This
mirrors the ImageDecoderPlugin design and necessitates new sniffing
methods on the loaders.
While this would be useful in the future for implementing a multi-tiered
optimization strategy, currently a binary on/off is enough for us. This
removes the confusingly on-by-default `OptimizationLevel::None` option
which made the optimization pipeline a no-op even if
`Bytecode::Interpreter::set_optimizations_enabled` had been called.
Fixes#15982
Since https://reviews.llvm.org/D131441, libc++ must be included before
LibC. As clang includes libc++ as one of the system includes, LibC
must be included after those, and the only correct way to do that is
to install LibC's headers into the sysroot.
Targets that don't link with LibC yet require its headers for one
reason or another must add install_libc_headers as a dependency to
ensure that the correct headers have been (re)installed into the
sysroot.
LibC/stddef.h has been dropped since the built-in stddef.h receives
a higher include priority.
In addition, string.h and wchar.h must
define __CORRECT_ISO_CPP_STRING_H_PROTO and
_LIBCPP_WCHAR_H_HAS_CONST_OVERLOADS respectively in order to tell
libc++ to not try to define methods implemented by LibC.
Once LibC is installed to the sysroot and its conflicts with libc++
are resolved, including LibC headers in such a way will cause errors
with a modern LLVM-based toolchain.
This is needed to avoid including LibC headers in Lagom builds.
Unfortunately, we cannot rely on the build machine to provide a
fully POSIX-compatible ELF header for Lagom builds, so we have to
use our own.
libc++ disallows including LibC's complex.h in C++ mode. This means that
a C++ file cannot expect LibC's complex.h to be included, and thus
cannot use c-prefixed complex number functions. As a result,
complex.cpp is broken when libc++ has a higher include priority
than LibC.
A check for __cplusplus has been added to complex.h to warn users of
toolchains that don't use libc++.
If an exception is thrown by FunctionDeclarationInstantiation for an
async or async-generator function, we still need to return a promise.
We can't just throw the exception.
81 new passes on test262. :^)
