Previously it only deoptimized the parent scope if the current scope
contains direct eval, which is incorrect because code ran in direct
eval mode has access to the entire scope chain it was executed in.
The fix is to also propagate direct eval's presence if the current
scope is marked as being screwed by direct eval.
This fixes Google's botguard failing to complete on Google sign in, as
it tried to access local variables outside of a direct parent function
with eval, causing it throw "unhandled" exceptions. Unhandled is in
quotes because their bytecode VM _technically_ caught it, but it was
considered an unhandled exception. This was determined by removing get
optimizations and then adding debug output for every get operation.
Using this, I noticed that for these errors, it would access the
'message' and 'stack' properties. This is because their error handler
function noticed this was not a synthesised error, which is never
expected to happen. That was determined by using Chrome Devtools 'pause
on handled exception' feature, and noticing it never threw a '[var] is
not defined' exception, but only synthesized error objects which
contained a sentinel value to let it know it was synthesized.
I added debug output to eval to print out what was being eval'd because
it makes heavy use of eval. This revealed that the exceptions only came
from eval.
I then dumped every generated executable and noticed the variables it
was trying to access were generated as local variables in the top
scope. This led to checking what makes a variable considered local or
not, which then lead to this block of code in ~ScopePusher that
propagates eval presence only to the immediate parent scope. This
variable directly controls whether to create all variables properly
with variable environments and bindings or allow them to be stored as
local registers tied to that function's executable.
Since this now lets botguard run to completion, it no longer considers
us to be an insecure/potential bot browser when signing in, now
allowing us to be able to sign in to Google.
(cherry picked from commit 5f33383a7bf1b4277e15d4b21fbafcece9302614)
status = "okay" means the device is operational. We should ignore
devices that have a different status property value.
The BCM2835TimerDriver force disable hack can be removed, since that
timer is disabled in the Pi 4 devicetree.
But we have to introduce another hack that force enables the Pi 3 system
timer, as we otherwise wouldn't have any timer that we support for the
Pi 3.
Make the MemoryType used by mmap() configurable by
File::vmobject_and_memory_type_for_mmap overrides (previously called
vmobject_for_mmap).
All mmap()s were previously MemoryType::Normal.
If we're drawing a transform with a negative scale, we have to go
through the slow path since draw_scaled_bitmap() is unable to flip
images.
Fixes a regression from the 2nd commit in #24465.
Some assembly files were previously inconsistently formatted.
- Use 4 spaces for indentation
- Use `.L` as the local label prefix
- Remove trailing whitespace
We don't have any text relocations in the kernel anymore.
This linker argument was added in bd6dc5ccec as a temporary workaround.
Removing this argument won't cause text relocations to be reported for
aarch64 and riscv64, as we currently compile the kernel with `--no-pie`
on those architectures.
This pseudoinstruction causes text relocations, as it stores the target
address in literal pools inside .text.
The bss clearing code now also matches the RISC-V implementation.
This writes a bitmap that has pixels that are identical between
the two input images blended with 0.5 alpha against white, and
differing pixels are highlighted in red.
Use like so:
imgcmp --write-diff-image diff.webp image1.png image2.webp
