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 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.
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 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.
Unlike the spec we chose BigInt for the input and output types here as
it was being used with ℝ(ns), ns being of type BigInt, in one place and
a conversion to double would not be safe.
Since in many places we'll have double input values, let's add a double
overload of this function to avoid awkward conversions and expensive
allocations.
This patch introduces the "environment coordinate" concept, which
encodes the distance from a variable access to the binding it ends up
resolving to.
EnvironmentCoordinate has two fields:
- hops: The number of hops up the lexical environment chain we have
to make before getting to the resolved binding.
- index: The index of the resolved binding within its declarative
environment record.
Whenever a variable lookup resolves somewhere inside a declarative
environment, we now cache the coordinates and reuse them in subsequent
lookups. This is achieved via a coordinate cache in JS::Identifier.
Note that non-strict direct eval() breaks this optimization and so it
will not be performed if the resolved environment has been permanently
screwed by eval().
This makes variable access *significantly* faster. :^)
Since non-strict direct eval() can insert new bindings into a
surrounding var scope, we cannot safely cache some assumptions about
environment chain layout after eval() has taken place.
Since eval() is rare, let's do what other engines do and simply
deoptimize in its presence. This patch adds a new "permanently screwed"
flag to JS::Environment that will be set on the entire variable
environment chain upon non-strict direct eval().
'static' for a function means that the symbol shall not be made public
for the result of the current compilation unit. This does not make sense
in a header, especially not if it's a large function that is used in
more than one place and not that performance-sensitive.
Previously: Length (and all nearly all of its inline method
definitions) depended on the definition of class CalculatedStyleValue.
Meanwhile, CalculatedStyleValue (and nearly all of its namespaced
structs) depended on the definition of class Length.
Thus, a compilation unit that (for example) only contains
#include <Userland/Libraries/LibWeb/CSS/Length.h>
would fail to compile.
This patch resolves this issue by pushing the inline definition of
various Web::CSS::Length methods into a different file.
Previously: CSSImportRule::loaded_style_sheet() (and others) depend on
the definition of class CSSStyleSheet. Meanwhile,
CSSStyleSheet::template for_each_effective_style_rule (and others)
depend on the definition of class CSSImportRule.
This hasn't caused any problems so far because CSSStyleSheet.h happened
to be always included after CSSImportRule.h (in part due to alphabetical
ordering).
However, a compilation unit that (for example) only contains
#include <Userland/Libraries/LibWeb/CSSImportRule.h>
would fail to compile.
This patch resolves this issue by pushing the inline definition of
Web::CSS::CSSStyleSheet::for_each_effective_style_rule and
for_first_not_loaded_import_rule into a different file, and adding the
missing headers.
Previously, class SQL::Key
depends on def class SQL::IndexDef (because inline def index())
depends on def class SQL::KeyPartDef (inline def key_definition())
depends on def class SQL::ColumnDef (because base class)
depends on def class SQL::Relation (because base class)
depends on def class SQL::Key (because inline def hash()).
This hasn't caused any problems so far because Meta.h happened to be
always included after Key.h (in part due to alphabetical ordering).
However, a compilation that for example only contains
#include <Userland/Libraries/LibSQL/Key.h>
would fail to compile.
This patch resolves this issue by pushing the inline definition of
SQL::Relation::hash() into a different file. Yes, this might reduce
performance marginally, but this gets it to compile again.
In QtCreator (and under weird configurations with gcc), this used to
fail with the error messages like: "error: member of anonymous union
redeclares '___'".
This patch gives each member a unique name.
VM::resolve_binding() can now return a Reference that knows the exact
binding index if it's pointing into a DeclarativeEnvironment.
Reading/writing through the Reference will now use direct environment
access when possible.
This patch adds two DeclarativeEnvironment APIs:
- get_binding_value_direct()
- set_mutable_binding_direct()
These work identically to their non-direct-suffixed counterparts, but
take an index instead of a bound name. This will allow someone who has
a binding index to get/set that binding directly without any additional
hash lookups.
The previous storage for DeclarativeEnvironment looked like this:
HashMap<FlyString, Binding> m_bindings;
This patch changes that to:
HashMap<FlyString, size_t> m_names;
Vector<Binding> m_bindings;
The main goal here is to give each binding an index that can ultimately
be cached and used for optimized environment accesses.
Per the spec, only a BlockContainer" can have line boxes, so let's not
clutter up every Layout::Box with line boxes.
This also allows us to establish an invariant that BFC and IFC always
operate on a Layout::BlockContainer.
Note that if BlockContainer has all block-level children, its line boxes
are not used for anything. They are only used in the all inline-level
children scenario.
List item markers will never have children, so let's mark them as such,
which now allows our layout system to skip over their "insides" and
going straight to positioning instead.
