This reduces the number of tasks to schedule, and the complexity of the
build system integrations for the BindingsGenerator. As a bonus, we move
the "only write if changed" feature into the generator to reduce the
build system load on generated files for this generator.
Rather than splitting the Iterator type and its AOs into two files,
let's combine them into one file to match every other JS runtime object
that we have.
This is an editorial change in the ECMA-262 spec. See:
956e5af
This splits the GetIterator AO into two AOs, to remove some recursion
and to (soon) remove optional parameters.
This commit makes it possible to let properties accept easing functions
as values, which will be used in a later commit to implement
animation-timing-function.
The main missing features are rootMargin, proper nested browsing
context support and content clip/clip-path support.
This makes images appear on some sites, such as YouTube and
howstuffworks.com.
Generated iterator prototypes already have the IteratorPrototype as
their prototype, but we were incorrectly hijacking them and rerouting
to ObjectPrototype.
Regressed in cfe663435e.
Previously this was compiled to require an object despite the IDL file
specifying 'optional'.
This commit makes IDLGenerator respect this modifier, and fixes the only
affected instance.
It's not safe to allocate from the GC heap while in the constructor of a
GC heap cell. (Because if this ends up triggering a collection, we may
end up trying to call through an uninitialized vtable).
This was already done safely in the initialize() virtual in much of
LibJS and LibWeb. This patch moves the logic for prototypes, mixins,
and CSSStyleDeclaration as well.
Fixes a long-standing GC crash that was pretty easy to reproduce by
refreshing https://vercel.com/
That pattern seems to show up a lot in code written by people that
aren't intimately familiar with the lifetime model of Error and Strings.
This commit makes the compiler detect it and present a more helpful
diagnostic than "garbage string at runtime".
Some of these are allocated upon initialization of the intrinsics, and
some lazily, but in neither case the getters actually return a nullptr.
This saves us a whole bunch of pointer dereferences (as NonnullGCPtr has
an `operator T&()`), and also has the interesting side effect of forcing
us to explicitly use the FunctionObject& overload of call(), as passing
a NonnullGCPtr is ambigous - it could implicitly be turned into a Value
_or_ a FunctionObject& (so we have to dereference manually).
