Listing all the registers will lead to the inability to allocate enough
space in one basic block (as there can be an arbitrary number of
registers used), instead switch to specifying the range of registers
used and save a lot of space in the process.
This follows how the regular AST interpreter creates arrays, as using
Array::create_from uses create_data_property_or_throw, which will crash
when it encounters an empty value. We require empty values to represent
array holes.
This will leave any lexical/variable environments on the way to the
closest unwind context boundary.
This will not leave the closest unwind context, as we still need the
unwind context to perform the Throw instruction correctly.
When we reach a block terminating instruction (e.g. Break, Throw),
we cannot generate anymore instructions after it. This would not allow
us to leave any lexical/variable environments.
This uses the mechanism introduced in ba9c49 to unwind environments
when we encounter these instructions.
For example, a try/catch block with no finally. The try block and catch
block do not need to unwind to a finally block, so the unwind context
is no longer needed when we jump to the catch block.
If we threw an exception in a catch block of a try/catch, there will be
no handler or finalizer and the unit would continue on as if nothing
happened.
This would subsequently crash with the `m_saved_exception.is_null()`
assertion failure when we next call a non-native function.
Previously we would only end these scopes if the block was not
terminated. If the block was generated, we would not end the scope
and would generate other bytecode with these scopes still open.
These functions do not generate any code, so they can be used even if
the current block is terminated. The enter and end scope functions are
only used to track where to unwind to when break/continue are used.
The steps for creating a DeclarativeEnvironment for each iteration of a
for-loop can be done equivalently to the spec without following the spec
directly. For each binding creating in the loop's init expression, we:
1. Create a new binding in the new environment.
2. Grab the current value of the binding in the old environment.
3. Set the value in the new environment to the old value.
This can be replaced by initializing the bindings vector in the new
environment directly with the bindings in the old environment (but only
copying the bindings of the init statement).
With #12480, Breadcrumbbar's on_focus_change() uses
on_click(). In SpaceAnalyzer, double clicking triggers the
TreeWidgetMap's on_path_change(), which triggers Breadcrumbbar's
on_focus_change(), which also triggers the TreeWidgetMap's
on_path_change() again. This resulted in use-after-free of
Breadcrumbbar, thus resulted in the crash. Not updating the
TreeWidgetMap's viewpoint recursively solves the issue.
Ports / other userland often needs such an implementation to function.
Lets expose `AK::timing_safe_compare` under the same name used used in
OpenBSD / FreeBSD / Solaris and other projects.
This is not strictly required, as we are comparing hashes, not the
password it self. However given this is generic code that could be
used anywhere in the system, it seems prudent to be cautious and
make sure we don't inadvertently leak any information about the hash
via timing attacks in future usages of `LibCore::Account`.
Reported-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
This makes code readable in Hack Studio.
This commit also replaces the 'highlight' window colour
with one that matches theme (the previous was the default).
PBM, PGM, and PPM image loaders are mostly common. The only difference
is how the data is read and the associated magic numbers. The magic
numbers are already made common using the loading contexts. Now make
the implementations common via a class template which accepts the
context to disambiguate.
Much of the code in PBM, PGM, and PPM image loaders is common. The
contexts are nearly identical. Instead of writing multiple contexts,
write 1 with a template argument to pass in the details of the given
format.
Since we want to store an initial value for every CSS::PropertyID,
it's pretty silly to use a HashMap when we can use an Array.
This takes the function from ~2.8% when mousing around on GitHub all the
way down to ~0.6%. :^)
Previously we were making a copy of the full set of custom properties
that applied to a DOM element. This was very costly and dominated the
profile when mousing around on GitHub.
Note that this may break custom properties on pseudo elements a little
bit, and that's something we'll have to look into.
Computing the pseudo element of a CSS::Selector was very hot when
mousing around on GitHub in Browser. A profile had it at ~10%.
After these changes, it's totally gone from the profile. :^)
