| Age | Commit message (Collapse) | Author |
|---|
|
Also add spec step comments to it while we're here.
|
|
|
|
|
|
This makes ECMAScriptFunctionObject calls in the bytecode interpreter
work again (regressed in #10402).
|
|
The implementation of transform_bytecode_repetition_min_max expects at
least min=1, so let's also optimise on our way out of a bug where
'x{0,}' would cause a crash.
|
|
|
|
Now that only ECMAScriptFunctionObject uses this, we can remove the
FunctionObject::new_function_environment() pure virtual method and just
implement it as a standalone AO with an ECMAScriptFunctionObject
parameter, next to the other NewFooEnvironment AOs.
|
|
Now that it only needs to deal with ECMAScriptFunctionObject via
internal_call() / internal_construct(), we can:
- Remove the generic FunctionObject parameter
- Move it from the VM to ECMAScriptFunctionObject
- Make it private
|
|
Now that it only needs to deal with ECMAScriptFunctionObject via
internal_call() / internal_construct(), we can:
- Remove the generic FunctionObject parameter
- Move it from the VM to ECMAScriptFunctionObject
- Make it private
|
|
This patch implements:
- Spec compliant [[Call]] and [[Construct]] internal slots, as virtual
FunctionObject::internal_{call,construct}(). These effectively replace
the old virtual FunctionObject::{call,construct}(), but with several
advantages:
- Clear and consistent naming, following the object internal methods
- Use of completions
- internal_construct() returns an Object, and not Value! This has been
a source of confusion for a long time, since in the spec there's
always an Object returned but the Value return type in LibJS meant
that this could not be fully trusted and something could screw you
over.
- Arguments are passed explicitly in form of a MarkedValueList,
allowing manipulation (BoundFunction). We still put them on the
execution context as a lot of code depends on it (VM::arguments()),
but not from the Call() / Construct() AOs anymore, which now allows
for bypassing them and invoking [[Call]] / [[Construct]] directly.
Nothing but Call() / Construct() themselves do that at the moment,
but future additions to ECMA262 or already existing web specs might.
- Spec compliant, standalone Call() and Construct() AOs: currently the
closest we have is VM::{call,construct}(), but those try to cater to
all the different function object subclasses at once, resulting in a
horrible mess and calling AOs with functions they should never be
called with; most prominently PrepareForOrdinaryCall and
OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject.
As a result this also contains an implicit optimization: we no longer
need to create a new function environment for NativeFunctions - which,
worth mentioning, is what started this whole crusade in the first place
:^)
|
|
These would crash starting with the next commit otherwise, calling a
function always requires the running execution context to exist.
|
|
A BoundFunction only implements [[Construct]] (has_constructor() in
LibJS) if its bound target function does.
|
|
This is commonly used in the spec.
|
|
|
|
|
|
This should be used instead of ArrayBuffer::create() in most places, as
it uses OrdinaryCreateFromConstructor to allow for a custom prototype.
The data block (ByteBuffer) is allocated separately and attached
afterwards, if we didn't fail due to OOM.
|
|
|
|
|
|
This new utility queries a block device for its size via the newly
introduced ioctl STORAGE_DEVICE_GET_SIZE request.
|
|
This ioctl request makes it possible to get the size of a storage device
that has not yet been mounted.
|
|
Before this patch the markdown lists would have two space inbetween each
item. This patch removes one of these newlines for a nicer render.
|
|
Most switch statements don't have any lexically scoped declarations,
so let's avoid allocating an environment in the common case where we
don't have to.
|
|
|
|
|
|
|
|
We now evaluate the conditions of `@media` rules at the same point in
the HTML event loop as evaluation of `MediaQueryList`s. This is not
strictly to spec, but since the spec doesn't actually say when to do
this, it seems to make the most sense. In any case, it works! :^)
|
|
The main thing missing is that we don't serialize the supports clause,
but for actually using a `@supports (something: cool) {}` rule in CSS,
it works!
|
|
The logic is handled by `CSSGroupingRule` and `CSSConditionRule`, so
`CSSMediaRule` only has to report if its condition matches.
Right now, that condition is always false because we do not evaluate the
media query.
|
|
CSSStyleSheet is no longer the only class that contains a list of rules,
so this will save duplicating the logic in multiple places.
|
|
Websites being able to query whether we support a given CSS feature
should prevent them from loading unnecessary polyfills for things we
already support! Or at least, that's the nice theory. :^)
|
|
... according to
https://www.w3.org/TR/css-conditional-3/#typedef-supports-condition
This works very similarly to `@media`, but is different enough to
require its own parsing. (Though, the draft of Conditional-4 currently
mentions combining the two into a `@when` rule.)
Made some small changes to parsing code to make this work. Notably,
making `consume_a_declaration()` fail gracefully instead of
`VERIFY()`ing.
|
|
The name is a little awkward, but this corresponds to the condition of a
`@supports` rule or the `CSS.supports("")` function.
A supports query only gets evaluated once, since its condition cannot
change during runtime. (We either support something or we don't, and the
spec specifically mentions that user preferences that disable features
do not affect the result here.) We keep a representation of it around
though, so that it can be serialized if needed. This is a little awkward
since we hold onto a `StyleDeclarationRule` which should be an internal
Parser class. This means making some Parser functions more public.
Potentially we could evaluate the Supports inside the Parser, and have
it only store a String representation of itself. But this works for now.
:^)
|
|
This version takes a property name and value as separate parameters.
|
|
This is the `CSS` namespace defined in IDL here:
https://www.w3.org/TR/cssom-1/#namespacedef-css , not to be confused
with our `Web::CSS` namespace. Words are hard.
`CSS.escape()` lets you escape identifiers that can then be used to
create a CSS string.
I've also stubbed out the `CSS.supports()` function.
|
|
This matches the class hierarchy of the CSS Geometry Interfaces Module.
|
|
WeakContainers need to look at the Cell::State bits to know if their
weak pointees got swept by garbage collection. So we must do this before
potentially freeing one or more HeapBlocks by notifying the allocator
that a block became empty.
|
|
This commit partially reverts "LibJS: Make accessing the current
function's arguments cheaper".
While the change passed all the currently passing test262 tests, it
seems to have _some_ flaw that silently breaks with some real-world
websites.
As the speedup with negligible at best, let's just revert it until we
can implement it more correctly.
|
|
By spec, calling an ECMAScript function object in non-strict mode should
always create a new top-level declarative environment, even if there are
no lexically scoped bindings (let/const) that belong in it. This is
used for scope disambiguation in direct eval() calls.
However, if there are no direct eval() calls within the function, and no
lexically scoped bindings, we can simply not allocate the extra
environment and save ourselves the trouble.
|
|
We now propagate this flag to FunctionDeclaration, and then also into
ECMAScriptFunctionObject.
This will be used to disable optimizations that aren't safe in the
presence of direct eval().
|
|
Instead of going through an environment record, make arguments of the
currently executing function generate references via the argument index,
which can later be resolved directly through the ExecutionContext.
|
|
|
|
The accessed field is mutable, so there's no need for this const_cast.
|
|
|
|
|
|
The dynamic resizing of this hash table was showing up in profiles.
Since we have an idea of how big it will get, use ensure_capacity().
|
|
|
|
The recursive style update function was written a bit strangely and
would only mark descendants of the style update root as not needing a
style update.
With this patch, all nodes in the subtree now have clean style after a
style update finishes.
|
|
Layout depends on style (and not the other way around), so if the
document has dirty style when we enter update_layout(), make sure we
call update_style() before proceeding with the layout work.
This has the pleasant effect of coalescing some redundant layouts.
|
|
|
|
Let's accept keeping up to 8 MiB of HeapBlock memory cached. This allows
the GC allocator to reuse memory instead of asking the kernel for more.
|
