Before usage of GetGlobal was prevented whenever eval() is present in
the scope chain.
With this change GetGlobal is emitted for `g` in the following program:
```js
function screw_everything_up() {
eval("");
}
var g;
g;
```
It makes Octane/mandreel.js benchmark run 2x faster :)
Normally, we want to avoid accidentally using such atomics, since
they're much slower. In this case however, we're just implementing
another atomics API, it is then up to the JavaScript code to avoid
using the slow atomics.
We currently cannot parse the output of `toString` and `toUTCString`.
While the spec does not require such support, test262 expects it, and
all major engines support it.
https://cldr.unicode.org/index/downloads/cldr-44
Notable changes that affect us include:
* The Islamic Calendar is now localized as the Hijri Calender (in en-US)
but has not been updated for all locales. So this patch updates tests
where possible and removes a few test cases that currently cannot be
localized.
* The und locale has received more likely subtag data (the und locale is
basically a pseudo-locale meaning "undetermined").
* The exponential symbol in the Arabic number system was changed from
U+0627 to U+0623.
Now that x86-specific Assembler will be compiled on every architecture
we can't rely on void* being the right width.
It also fixes compilation on targets which have void*
be different length from u64 (WASM in particular).
This is in preparation for making LibJIT support multiple architectures.
Assembler will now be typedefed to the specific assembler
for a particular architecture.
Additionally, there's now JIT_ARCH_SUPPORTED which is defined on
architectures which LibJIT supports.
This makes JS::JIT::Compiler less architecture-specific
and unifies aligning the stack into a single operation,
where previously we were doing it separately for preserved registers
and for stack arguments.
Since 2023-09-08, Clang trunk has had a bug which causes a segfault when
evaluating certain `requires` expressions inside templated lambdas.
There isn't an imminent fix on the horizon, so let's work around the
issue by specifying the type of the offending lambda arguments
explicitly.
See https://github.com/llvm/llvm-project/issues/67260
Using ErrorType::ReferencePrimitiveSetProperty the errors for primitives
now look like "Cannot set property 'foo' of number '123'".
The strict-mode-errors test has been adjusted and re-enabled.
In case of {get func() {}, set func() {}} we were wrongly setting the
function name to 'func' and then later trying to replace an empty name
with 'get func'/'set func' which failed.
Instead, set the name to 'get func'/'set func' right away.
The code in put_by_property_key is kept, for when that is called
by put_by_value.
This kills 2 birds with one stone:
1. It makes sure generated check_exception() calls in the finalizer
don't mis-read the pending exception as caused by their matching
operation.
2. It implicitly ensures that terminated finally blocks (by a return
statement) overwrite any pending exceptions, since they will never
execute the ContinuePendingUnwind operation that restores the
stashed exception.
This additional logic is required in the JIT (as opposed to the
interpreter), since the JIT uses the exception register to store and
check the possibly-exceptional results from each individual operation,
while the interpreter only modifies it when an operation has thrown an
exception.
This reverts commit 0daebef727.
Finally blocks do not unconditionally swallow pending exceptions.
This resolves#21759 and fixes the 2 remaining failing test-js tests.
If Interpreter::run_and_return_frame is called with a specific entry
point we now map that to a native instruction address, which the JIT
code jumps to after the function prologue.
We were trying to stringify the stack trace without the last element,
leading to a loop bound of (size_t)(0 - 1) and accessing m_traceback[0]
out-of-bounds.
Instead, just return an empty string in that case.
Fixes#21747
The previous implementation was calling `backtrace()` for every
function call, which is quite slow.
Instead, this implementation provides VM::stack_trace() which unwinds
the native stack, maps it through NativeExecutable::get_source_range
and combines it with source ranges from interpreted call frames.
Previously these handlers duplicated code and used formats that
were different from the one Error.prototype.stack uses.
Now they use the same Error::stack_string function, which accepts
a new parameter for compacting stack traces with repeating frames.
