The fnmatch patch that was added in 6de6dff is reverted because it is
not clear why it is necessary, as discussed in #9206.
This also removes diffutils from the list of ports missing descriptions
as it no longer has any patches.
Three optimizations are applied:
1. If the list of vertices to clip is empty, return immediately after
clearing the output list.
2. Remember the previous vertex instead of recalculating whether it is
within the clip plane.
3. Instead of copying and swapping lists around, operate on the input
and output lists directly. This prevents a lot of `malloc`/`free`
traffic as a result of vector assignments.
This takes the clipping code CPU load from 3.9% down to 1.8% for
Quake 3 on my machine.
This keeps us from accidentally overwriting an already set region name,
for example when we are mapping a file (as, in this case, the file name
is already stored in the region).
The existing code looks innocently correct, implementing the following
step:
3. If IsCallable(func) is false, set func to the intrinsic function
%Object.prototype.toString%.
as
return ObjectPrototype::to_string(vm, global_object);
However, this misses the fact that the next step calls the function with
the previously ToObject()'d this value (`array`):
4. Return ? Call(func, array).
This doesn't happen in the current implementation, which will use the
unaltered this value from the Array.prototype.toString() call, and make
another, unequal object in %Object.prototype.toString%. Since both that
and Array.prototype.toString() do a Get() call on said object, this
behavior is observable (see newly added test).
Fix this by actually doing what the spec says and calling the fallback
function the regular way.
For inline-blocks and inline replaced elements, we previously fell into
a code path that tried to find a corresponding line box fragment to
invalidate. However, we don't need to do any of that, all we need to do
is get the absolute rect from our paintable, and invalidate that.
This makes CRC2D invalidations happen immediately instead of as a side
effect of some other invalidation.
Having all spec comments verbatim on their own line with no additions
made by us will make it easier to automate comparing said comments to
their current spec counterparts.
While adding spec comments to PerformEval, I noticed we were missing
multiple steps.
Namely, these were:
- Checking if the host will allow us to compile the string
(allowing LibWeb to perform CSP for eval)
- The parser's initial state depending on the environment around us
on direct eval:
- Allowing new.target via eval in functions
- Allowing super calls and super properties via eval in classes
- Disallowing the use of the arguments object in class field
initializers at eval's parse time
- Setting ScriptOrModule of eval's execution context
The spec allows us to apply the additional parsing steps in any order.
The method I have gone with is passing in a struct to the parser's
constructor, which overrides the parser's initial state to (dis)allow
the things stated above from the get-go.
We already had the CSSRule::Type enum, but the values were not aligned
with the CSSOM spec. This patch takes care of that, and then exposes
the type of a CSSRule to JavaScript via the "type" attribute.
