This used to generate a warning about using a deprecated copy-assign,
default-generated by the compiler, and deprecated because we hand-
implement the copy-constructor. This warning is correct, since the
default-generated copy-assign may or may not be as efficient as memcpy.
This patch gets rid of the warning, and has either no performance impact
or a slightly positive one. If this turns out to be wrong, we should
probably also fix the copy-constructor.
There are only 112 code points with special casing rules, so this array
is quite small (compared to the size 34,626 UnicodeData hash map that is
also storing this data). Removing all casing rules from UnicodeData will
happen in a subsequent commit.
Currently, all casing information (simple and special) are stored in a
compile-time array of size 34,626, then statically copied to a hash map
at runtime. In an effort to reduce the resulting memory usage, store the
simple casing rules in standalone compile-time arrays. The uppercase map
is size 1,450 and the lowercase map is size 1,433. Any code point not in
a map will implicitly have an identity mapping.
A types which have special functions declared with "= default can be
trivially copied. Besides being good practice, the compiler might be
able generate copy and initialize code in a more optimized way.
Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v832/
We can reduce the amount of padding the compiler adds in order to
ensure data alignment of member variables by ordering the types in
a struct by size in decending order.
Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v802/
We can reduce the amount of padding the compiler adds in order to
ensure data alignment of member variables by ordering the types in
a struct by size in decending order.
Found By PVS-Studio: https://pvs-studio.com/en/docs/warnings/v802/
When the member is initialized in the constructor body, but also has a
default constructor, you pay for default construction to just throw it
away. In this case a StringView is light weight to initialize, but we
might as well fix all cases we find.
Found by PVS-Studio: https://pvs-studio.com/en/docs/warnings/v818/
If we don't quit, the underlying socket won't get a chance to do much
other than nothing while we spin in read_while_data_available().
Fixes some possible RS spin (especially seen in Google's cookie consent
page).
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
:^)
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.
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.
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.
