| Age | Commit message (Collapse) | Author |
|---|
|
|
|
More work on decoupling the general runtime from Interpreter. The goal
is becoming clearer. Interpreter should be one possible way to execute
code inside a VM. In the future we might have other ways :^)
|
|
This patch moves the exception state, call stack and scope stack from
Interpreter to VM. I'm doing this to help myself discover what the
split between Interpreter and VM should be, by shuffling things around
and seeing what falls where.
With these changes, we no longer have a persistent lexical environment
for the current global object on the Interpreter's call stack. Instead,
we push/pop that environment on Interpreter::run() enter/exit.
Since it should only be used to find the global "this", and not for
variable storage (that goes directly into the global object instead!),
I had to insert some short-circuiting when walking the environment
parent chain during variable lookup.
Note that this is a "stepping stone" commit, not a final design.
|
|
To make it a little clearer what this is for. (This is an RAII helper
class for adding and removing an Interpreter to a VM's list of the
currently active (executing code) Interpreters.)
|
|
Taking a big step towards a world of multiple global object, this patch
adds a new JS::VM object that houses the JS::Heap.
This means that the Heap moves out of Interpreter, and the same Heap
can now be used by multiple Interpreters, and can also outlive them.
The VM keeps a stack of Interpreter pointers. We push/pop on this
stack when entering/exiting execution with a given Interpreter.
This allows us to make this change without disturbing too much of
the existing code.
There is still a 1-to-1 relationship between Interpreter and the
global object. This will change in the future.
Ultimately, the goal here is to make Interpreter a transient object
that only needs to exist while you execute some code. Getting there
will take a lot more work though. :^)
Note that in LibWeb, the global JS::VM is called main_thread_vm(),
to distinguish it from future worker VM's.
|
|
This is pretty handy if the JS tests take a long time to run and you
wonder what they're doing. :^)
|
|
This is very slow, but very good at flushing out GC bugs. :^)
|
|
|
|
|
|
The fact that a `MarkedValueList` had to be created was just annoying,
so here's an alternative.
This patchset also removes some (now) unneeded MarkedValueList.h includes.
|
|
Closes #3240
|
|
LibJS doesn't store stacks for exception objects, so this
only amends test-common.js's __expect() with an optional
`details` function that can produce a more detailed error
message, and it lets test-js.cpp read and print that
error message. I added the optional details parameter to
a few matchers, most notably toBe() where it now prints
expected and actual value.
It'd be nice to have line numbers of failures, but that
seems hard to do with the current design, and this is already
much better than the current state.
|
|
|
|
This enables a nice warning in case a function becomes dead code. Also,
in the case of test-crypto.cpp, I took the liberty to add the prefix 'g_'
to the global event loop.
|
|
This was a nice feature the old run-tests.sh script had - let's add it
to test-js as well! :^)
|
|
|
|
|
|
|
|
|
|
|
|
This does not affect output when the "-t" flag is specified -- all files
will still be printed in that case.
|
|
This will help greatly with debugging!
|
|
|
|
|
|
Skipped tests count as a "pass" rather than a "fail" (i.e. a test suite
with a skipped test will pass), however it does display a message when
the test is printing.
This is intended for tests which _should_ work, but currently do not.
This should be preferred over "// FIXME" notes if possible.
|
|
The shell script is no longer necessary -- simply run "test-js" from
inside Serenity, or $SERENITY_ROOT/Build/Meta/Lagom/test-js from the
host.
|
|
This commit also exposes JSONObject's implementation of stringify to the
public, so that it can be used by test-js without having to go through
the interpreter's environment.
|
|
|
|
|
|
|
|
Now that test-common.js is quite a bit more complicated, we need tests
for test-common to make sure all of the matchers behave correctly
|
|
First test conversions! These look really good :)
|
|
This moves most of the work from run-tests.sh to test-js.cpp. This way,
we have a lot more control over how the test suite runs, as well as how
it outputs. This should result in some cool functionality!
This commit also refactors test-common.js to mimic the jest library.
This should allow tests to be much more expressive :)
|
