Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/VM.cpp

630 lines
23 KiB
C++
Raw Normal View History

LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
/*
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
Everywhere: Use linusg@serenityos.org for my copyright headers
2021-04-22 22:51:19 +02:00
* Copyright (c) 2020-2021, Linus Groh <linusg@serenityos.org>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
*/
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
#include <AK/Debug.h>
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
#include <AK/ScopeGuard.h>
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
#include <AK/StringBuilder.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
#include <LibJS/Interpreter.h>
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Implement a very hackish "arguments" object We now lazily create an "arguments" array inside functions when code tries to access it. This doesn't follow the spec at all but still covers a lot of the basic uses of arguments, i.e "arguments.length" and "arguments[n]"
2020-12-05 16:38:29 +01:00
#include <LibJS/Runtime/Array.h>
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
#include <LibJS/Runtime/Error.h>
LibJS: Add the FinalizationRegistry built-in object As well as the needed functionality in VM to enqueue and run cleanup jobs for the FinalizationRegistry instances.
2021-06-15 22:16:17 +03:00
#include <LibJS/Runtime/FinalizationRegistry.h>
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
#include <LibJS/Runtime/FunctionEnvironmentRecord.h>
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
#include <LibJS/Runtime/GlobalEnvironmentRecord.h>
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
#include <LibJS/Runtime/IteratorOperations.h>
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
#include <LibJS/Runtime/NativeFunction.h>
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
#include <LibJS/Runtime/OrdinaryFunctionObject.h>
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
#include <LibJS/Runtime/PromiseReaction.h>
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
#include <LibJS/Runtime/Reference.h>
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
#include <LibJS/Runtime/Symbol.h>
LibJS: Add TemporaryClearException helper class This is very similar to AK::TemporaryChange (and in fact replaces one use of it), but since we can't directly set VM's m_exception from outside of the VM, we need something more sophisticated. Sometimes we need to temporarily remove the stored exception for some other operation to succeed (e.g. anything that uses call(), as well as get_without_side_effects()) and later restore it - the boilerplate code required for this is annoying enough to justify a helper.
2021-04-24 17:56:16 +02:00
#include <LibJS/Runtime/TemporaryClearException.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
#include <LibJS/Runtime/VM.h>
namespace JS {
NonnullRefPtr<VM> VM::create()
{
AK: Rename adopt() to adopt_ref() This makes it more symmetrical with adopt_own() (which is used to create a NonnullOwnPtr from the result of a naked new.)
2021-04-23 16:46:57 +02:00
return adopt_ref(*new VM);
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
}
VM::VM()
: m_heap(*this)
{
LibJS: Let the VM cache an empty ("") PrimitiveString Empty string is extremely common and we can avoid a lot of heap churn by simply caching one in the VM. Primitive strings are immutable anyway so there is no observable behavior change outside of fewer collections.
2020-09-22 16:36:33 +02:00
m_empty_string = m_heap.allocate_without_global_object<PrimitiveString>(String::empty());
LibJS: Give VM a cache of single-ASCII-character PrimitiveString A large number of JS strings are a single ASCII character. This patch adds a 128-entry cache for those strings to the VM. The cost of the cache is 1536 byte of GC heap (all in same block) + 2304 bytes malloc. This avoids a lot of GC heap allocations, and packing all of these in the same heap block is nice for fragmentation as well.
2020-10-22 17:43:48 +02:00
for (size_t i = 0; i < 128; ++i) {
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
m_single_ascii_character_strings[i] = m_heap.allocate_without_global_object<PrimitiveString>(String::formatted("{:c}", i));
LibJS: Give VM a cache of single-ASCII-character PrimitiveString A large number of JS strings are a single ASCII character. This patch adds a 128-entry cache for those strings to the VM. The cost of the cache is 1536 byte of GC heap (all in same block) + 2304 bytes malloc. This avoids a lot of GC heap allocations, and packing all of these in the same heap block is nice for fragmentation as well.
2020-10-22 17:43:48 +02:00
}
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
#define __JS_ENUMERATE(SymbolName, snake_name) \
m_well_known_symbol_##snake_name = js_symbol(*this, "Symbol." #SymbolName, false);
JS_ENUMERATE_WELL_KNOWN_SYMBOLS
#undef __JS_ENUMERATE
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
}
VM::~VM()
{
}
Interpreter& VM::interpreter()
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!m_interpreters.is_empty());
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
return *m_interpreters.last();
}
Interpreter* VM::interpreter_if_exists()
{
if (m_interpreters.is_empty())
return nullptr;
return m_interpreters.last();
}
void VM::push_interpreter(Interpreter& interpreter)
{
m_interpreters.append(&interpreter);
}
void VM::pop_interpreter(Interpreter& interpreter)
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!m_interpreters.is_empty());
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
auto* popped_interpreter = m_interpreters.take_last();
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(popped_interpreter == &interpreter);
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
}
LibJS: Rename InterpreterScope => InterpreterExecutionScope 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.)
2020-09-21 13:36:32 +02:00
VM::InterpreterExecutionScope::InterpreterExecutionScope(Interpreter& interpreter)
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
: m_interpreter(interpreter)
{
m_interpreter.vm().push_interpreter(m_interpreter);
}
LibJS: Rename InterpreterScope => InterpreterExecutionScope 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.)
2020-09-21 13:36:32 +02:00
VM::InterpreterExecutionScope::~InterpreterExecutionScope()
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
{
m_interpreter.vm().pop_interpreter(m_interpreter);
}
LibJS: GC should gather roots from all active interpreters If we are in a nested execution context, we shouldn't only mark things used by the active interpreter.
2020-09-21 13:47:33 +02:00
void VM::gather_roots(HashTable<Cell*>& roots)
{
LibJS: Let the VM cache an empty ("") PrimitiveString Empty string is extremely common and we can avoid a lot of heap churn by simply caching one in the VM. Primitive strings are immutable anyway so there is no observable behavior change outside of fewer collections.
2020-09-22 16:36:33 +02:00
roots.set(m_empty_string);
LibJS: Give VM a cache of single-ASCII-character PrimitiveString A large number of JS strings are a single ASCII character. This patch adds a 128-entry cache for those strings to the VM. The cost of the cache is 1536 byte of GC heap (all in same block) + 2304 bytes malloc. This avoids a lot of GC heap allocations, and packing all of these in the same heap block is nice for fragmentation as well.
2020-10-22 17:43:48 +02:00
for (auto* string : m_single_ascii_character_strings)
roots.set(string);
LibJS: Remove some unnecessary null checks It's okay to add nullptr to the conservative roots set. We'll just ignore it later on anyway.
2020-12-08 16:06:05 +01:00
roots.set(m_exception);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
if (m_last_value.is_cell())
LibJS: Make Value::as_cell() return a Cell&
2021-05-25 18:48:11 +02:00
roots.set(&m_last_value.as_cell());
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
for (auto& execution_context : m_execution_context_stack) {
if (execution_context->this_value.is_cell())
roots.set(&execution_context->this_value.as_cell());
roots.set(execution_context->arguments_object);
for (auto& argument : execution_context->arguments) {
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
if (argument.is_cell())
LibJS: Make Value::as_cell() return a Cell&
2021-05-25 18:48:11 +02:00
roots.set(&argument.as_cell());
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
roots.set(execution_context->lexical_environment);
LibJS: Protect execution context variable environments from GC At the moment these environments are always the same as the lexical ones, so this didn't cause any trouble. Once we start separating them we have to make sure both environments are protected.
2021-06-24 20:10:31 +02:00
roots.set(execution_context->variable_environment);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
#define __JS_ENUMERATE(SymbolName, snake_name) \
roots.set(well_known_symbol_##snake_name());
JS_ENUMERATE_WELL_KNOWN_SYMBOLS
#undef __JS_ENUMERATE
for (auto& symbol : m_global_symbol_map)
roots.set(symbol.value);
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
for (auto* job : m_promise_jobs)
roots.set(job);
LibJS: Move well-known symbols to the VM No need to instantiate unique symbols for each Interpreter; they can be VM-global. This reduces the memory cost and startup time anyway.
2020-09-22 16:18:51 +02:00
}
Symbol* VM::get_global_symbol(const String& description)
{
auto result = m_global_symbol_map.get(description);
if (result.has_value())
return result.value();
auto new_global_symbol = js_symbol(*this, description, true);
m_global_symbol_map.set(description, new_global_symbol);
return new_global_symbol;
LibJS: GC should gather roots from all active interpreters If we are in a nested execution context, we shouldn't only mark things used by the active interpreter.
2020-09-21 13:47:33 +02:00
}
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
void VM::set_variable(const FlyString& name, Value value, GlobalObject& global_object, bool first_assignment, EnvironmentRecord* specific_scope)
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
{
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
Optional<Variable> possible_match;
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
if (!specific_scope && m_execution_context_stack.size()) {
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
for (auto* environment_record = lexical_environment(); environment_record; environment_record = environment_record->outer_environment()) {
LibJS: Rename virtuals in EnvironmentRecord This patch makes the following renames: - get_from_scope() => get_from_environment_record() - put_to_scope() => put_into_environment_record() - delete_from_scope() => delete_from_environment_record()
2021-06-21 23:41:38 +02:00
possible_match = environment_record->get_from_environment_record(name);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
if (possible_match.has_value()) {
LibJS: Rename EnvironmentRecord::parent() => outer_environment() This name matches the spec (corresponds to the [[OuterEnv]] slot.)
2021-06-21 23:35:30 +02:00
specific_scope = environment_record;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
break;
}
}
}
if (specific_scope && possible_match.has_value()) {
if (!first_assignment && possible_match.value().declaration_kind == DeclarationKind::Const) {
throw_exception<TypeError>(global_object, ErrorType::InvalidAssignToConst);
return;
}
LibJS: Rename virtuals in EnvironmentRecord This patch makes the following renames: - get_from_scope() => get_from_environment_record() - put_to_scope() => put_into_environment_record() - delete_from_scope() => delete_from_environment_record()
2021-06-21 23:41:38 +02:00
specific_scope->put_into_environment_record(name, { value, possible_match.value().declaration_kind });
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
return;
}
if (specific_scope) {
LibJS: Rename virtuals in EnvironmentRecord This patch makes the following renames: - get_from_scope() => get_from_environment_record() - put_to_scope() => put_into_environment_record() - delete_from_scope() => delete_from_environment_record()
2021-06-21 23:41:38 +02:00
specific_scope->put_into_environment_record(name, { value, DeclarationKind::Var });
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
return;
}
global_object.put(name, value);
}
LibJS: Support deleting local variables with operator delete To make this cleaner i also moved the logic into Reference::delete_.
2021-06-08 04:00:53 +03:00
bool VM::delete_variable(FlyString const& name)
{
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
EnvironmentRecord* specific_scope = nullptr;
LibJS: Support deleting local variables with operator delete To make this cleaner i also moved the logic into Reference::delete_.
2021-06-08 04:00:53 +03:00
Optional<Variable> possible_match;
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
if (!m_execution_context_stack.is_empty()) {
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
for (auto* environment_record = lexical_environment(); environment_record; environment_record = environment_record->outer_environment()) {
LibJS: Rename virtuals in EnvironmentRecord This patch makes the following renames: - get_from_scope() => get_from_environment_record() - put_to_scope() => put_into_environment_record() - delete_from_scope() => delete_from_environment_record()
2021-06-21 23:41:38 +02:00
possible_match = environment_record->get_from_environment_record(name);
LibJS: Support deleting local variables with operator delete To make this cleaner i also moved the logic into Reference::delete_.
2021-06-08 04:00:53 +03:00
if (possible_match.has_value()) {
LibJS: Rename EnvironmentRecord::parent() => outer_environment() This name matches the spec (corresponds to the [[OuterEnv]] slot.)
2021-06-21 23:35:30 +02:00
specific_scope = environment_record;
LibJS: Support deleting local variables with operator delete To make this cleaner i also moved the logic into Reference::delete_.
2021-06-08 04:00:53 +03:00
break;
}
}
}
if (!possible_match.has_value())
return false;
if (possible_match.value().declaration_kind == DeclarationKind::Const)
return false;
VERIFY(specific_scope);
LibJS: Rename virtuals in EnvironmentRecord This patch makes the following renames: - get_from_scope() => get_from_environment_record() - put_to_scope() => put_into_environment_record() - delete_from_scope() => delete_from_environment_record()
2021-06-21 23:41:38 +02:00
return specific_scope->delete_from_environment_record(name);
LibJS: Support deleting local variables with operator delete To make this cleaner i also moved the logic into Reference::delete_.
2021-06-08 04:00:53 +03:00
}
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
void VM::assign(const FlyString& target, Value value, GlobalObject& global_object, bool first_assignment, EnvironmentRecord* specific_scope)
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
{
set_variable(target, move(value), global_object, first_assignment, specific_scope);
}
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
void VM::assign(const Variant<NonnullRefPtr<Identifier>, NonnullRefPtr<BindingPattern>>& target, Value value, GlobalObject& global_object, bool first_assignment, EnvironmentRecord* specific_scope)
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
{
if (auto id_ptr = target.get_pointer<NonnullRefPtr<Identifier>>())
return assign((*id_ptr)->string(), move(value), global_object, first_assignment, specific_scope);
assign(target.get<NonnullRefPtr<BindingPattern>>(), move(value), global_object, first_assignment, specific_scope);
}
LibJS: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
void VM::assign(const NonnullRefPtr<BindingPattern>& target, Value value, GlobalObject& global_object, bool first_assignment, EnvironmentRecord* specific_scope)
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
{
auto& binding = *target;
switch (binding.kind) {
case BindingPattern::Kind::Array: {
LibJS: Replace iterator hint string argument with an enum There's no reason at all for this to be a string or to accept arbitrary values - just because it's displayed as strings in the spec doesn't mean we have to do the same :^)
2021-06-02 20:52:46 +01:00
auto iterator = get_iterator(global_object, value);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
if (!iterator)
return;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
for (size_t i = 0; i < binding.entries.size(); i++) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
if (exception())
return;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
auto& entry = binding.entries[i];
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
if (entry.is_rest) {
VERIFY(i == binding.entries.size() - 1);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
auto* array = Array::create(global_object);
for (;;) {
auto next_object = iterator_next(*iterator);
if (!next_object)
return;
auto done_property = next_object->get(names.done);
if (exception())
return;
if (!done_property.is_empty() && done_property.to_boolean())
break;
auto next_value = next_object->get(names.value);
if (exception())
return;
array->indexed_properties().append(next_value);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
value = array;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
} else if (iterator) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
auto next_object = iterator_next(*iterator);
if (!next_object)
return;
auto done_property = next_object->get(names.done);
if (exception())
return;
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
if (!done_property.is_empty() && done_property.to_boolean()) {
iterator = nullptr;
value = js_undefined();
} else {
value = next_object->get(names.value);
if (exception())
return;
}
} else {
value = js_undefined();
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
if (value.is_undefined() && entry.initializer) {
value = entry.initializer->execute(interpreter(), global_object);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
if (exception())
return;
}
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
entry.alias.visit(
[&](Empty) {},
[&](NonnullRefPtr<Identifier> const& identifier) {
set_variable(identifier->string(), value, global_object, first_assignment, specific_scope);
},
[&](NonnullRefPtr<BindingPattern> const& pattern) {
assign(pattern, value, global_object, first_assignment, specific_scope);
});
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
if (entry.is_rest)
break;
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
break;
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
case BindingPattern::Kind::Object: {
auto object = value.to_object(global_object);
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
HashTable<PropertyName, PropertyNameTraits> seen_names;
for (auto& property : binding.entries) {
VERIFY(!property.is_elision());
PropertyName assignment_name;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
JS::Value value_to_assign;
if (property.is_rest) {
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
VERIFY(property.name.has<NonnullRefPtr<Identifier>>());
assignment_name = property.name.get<NonnullRefPtr<Identifier>>()->string();
auto* rest_object = Object::create(global_object, global_object.object_prototype());
for (auto& object_property : object->shape().property_table()) {
if (!object_property.value.attributes.has_enumerable())
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
continue;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
if (seen_names.contains(object_property.key.to_display_string()))
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
continue;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
rest_object->put(object_property.key, object->get(object_property.key));
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
if (exception())
return;
}
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
value_to_assign = rest_object;
} else {
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
property.name.visit(
[&](Empty) { VERIFY_NOT_REACHED(); },
[&](NonnullRefPtr<Identifier> const& identifier) {
assignment_name = identifier->string();
},
[&](NonnullRefPtr<Expression> const& expression) {
auto result = expression->execute(interpreter(), global_object);
if (exception())
return;
assignment_name = result.to_property_key(global_object);
});
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
if (exception())
break;
value_to_assign = object->get(assignment_name);
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
seen_names.set(assignment_name);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
if (value_to_assign.is_empty())
value_to_assign = js_undefined();
if (value_to_assign.is_undefined() && property.initializer)
value_to_assign = property.initializer->execute(interpreter(), global_object);
if (exception())
break;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
property.alias.visit(
[&](Empty) {
set_variable(assignment_name.to_string(), value_to_assign, global_object, first_assignment, specific_scope);
},
[&](NonnullRefPtr<Identifier> const& identifier) {
VERIFY(!property.is_rest);
set_variable(identifier->string(), value_to_assign, global_object, first_assignment, specific_scope);
},
[&](NonnullRefPtr<BindingPattern> const& pattern) {
VERIFY(!property.is_rest);
assign(pattern, value_to_assign, global_object, first_assignment, specific_scope);
});
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
if (property.is_rest)
break;
}
break;
}
}
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
Value VM::get_variable(const FlyString& name, GlobalObject& global_object)
{
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
if (!m_execution_context_stack.is_empty()) {
auto& context = running_execution_context();
LibJS: Rename ExecutionContext::callee => function This matches what ECMAScript calls it. Also make it a JS::Function* instead of a generic Value, since it will always either be a function object or null.
2021-06-24 19:25:38 +02:00
if (name == names.arguments.as_string() && context.function) {
LibJS: Implement a very hackish "arguments" object We now lazily create an "arguments" array inside functions when code tries to access it. This doesn't follow the spec at all but still covers a lot of the basic uses of arguments, i.e "arguments.length" and "arguments[n]"
2020-12-05 16:38:29 +01:00
// HACK: Special handling for the name "arguments":
// If the name "arguments" is defined in the current scope, for example via
// a function parameter, or by a local var declaration, we use that.
// Otherwise, we return a lazily constructed Array with all the argument values.
// FIXME: Do something much more spec-compliant.
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
auto possible_match = lexical_environment()->get_from_environment_record(name);
LibJS: Implement a very hackish "arguments" object We now lazily create an "arguments" array inside functions when code tries to access it. This doesn't follow the spec at all but still covers a lot of the basic uses of arguments, i.e "arguments.length" and "arguments[n]"
2020-12-05 16:38:29 +01:00
if (possible_match.has_value())
return possible_match.value().value;
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
if (!context.arguments_object) {
LibJS: Use CreateUnmappedArgumentsObject for non-simple parameter lists This patch implements the IsSimpleParameterList static semantics for ordinary function objects. We now also create an unmapped arguments object for callee contexts with non-simple parameter lists, instead of only doing it in strict mode. Covered by test262.
2021-06-28 11:18:32 +02:00
if (context.function->is_strict_mode() || !context.function->has_simple_parameter_list()) {
LibJS: Implement the CreateUnmappedArgumentsObject abstract operation
2021-06-28 01:44:58 +02:00
context.arguments_object = create_unmapped_arguments_object(global_object, context.arguments);
} else {
LibJS: Add the CreateMappedArgumentsObject abstract operation This patch adds a new ArgumentsObject class to represent what the spec calls "Arguments Exotic Objects" These are constructed by the new CreateMappedArgumentsObject when the `arguments` identifier is resolved in a callee context. The implementation is incomplete and doesn't yet support mapping of the parameter variables to the indexed properties of `arguments`.
2021-06-28 13:26:01 +02:00
context.arguments_object = create_mapped_arguments_object(global_object, *context.function, verify_cast<OrdinaryFunctionObject>(context.function)->parameters(), context.arguments, *lexical_environment());
LibJS: Implement a very hackish "arguments" object We now lazily create an "arguments" array inside functions when code tries to access it. This doesn't follow the spec at all but still covers a lot of the basic uses of arguments, i.e "arguments.length" and "arguments[n]"
2020-12-05 16:38:29 +01:00
}
}
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
return context.arguments_object;
LibJS: Implement a very hackish "arguments" object We now lazily create an "arguments" array inside functions when code tries to access it. This doesn't follow the spec at all but still covers a lot of the basic uses of arguments, i.e "arguments.length" and "arguments[n]"
2020-12-05 16:38:29 +01:00
}
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
for (auto* environment_record = lexical_environment(); environment_record; environment_record = environment_record->outer_environment()) {
LibJS: Rename virtuals in EnvironmentRecord This patch makes the following renames: - get_from_scope() => get_from_environment_record() - put_to_scope() => put_into_environment_record() - delete_from_scope() => delete_from_environment_record()
2021-06-21 23:41:38 +02:00
auto possible_match = environment_record->get_from_environment_record(name);
LibJS: Don't suppress GlobalObject variable lookup exceptions In HackStudio's Debugger a custom GlobalObject is used to reflect debugger variables into the JS scope by overriding GlobalObject's get method. However, when throwing a custom error during that lookup it was replaced with the generic "not found" js exception. This patch makes it instead pass along the custom error.
2021-04-12 20:57:30 -04:00
if (exception())
return {};
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
if (possible_match.has_value())
return possible_match.value().value;
}
}
auto value = global_object.get(name);
if (m_underscore_is_last_value && name == "_" && value.is_empty())
return m_last_value;
return value;
}
LibJS: Rename VM::get_reference() => resolve_binding() This function maps to the ResolveBinding operation from the spec, so let's rename it to match.
2021-06-25 11:24:47 +02:00
// 9.4.2 ResolveBinding ( name [ , env ] ), https://tc39.es/ecma262/#sec-resolvebinding
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
Reference VM::resolve_binding(GlobalObject& global_object, FlyString const& name, EnvironmentRecord*)
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
{
LibJS: Rename VM::get_reference() => resolve_binding() This function maps to the ResolveBinding operation from the spec, so let's rename it to match.
2021-06-25 11:24:47 +02:00
// FIXME: This implementation of ResolveBinding is non-conforming.
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
for (auto* environment_record = lexical_environment(); environment_record && environment_record->outer_environment(); environment_record = environment_record->outer_environment()) {
auto possible_match = environment_record->get_from_environment_record(name);
if (possible_match.has_value())
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
return Reference { *environment_record, name };
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
return Reference { global_object.environment_record(), name };
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
Value VM::construct(FunctionObject& function, FunctionObject& new_target, Optional<MarkedValueList> arguments)
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
{
LibJS: Remove GlobalObject& argument from VM::construct() We can just get the global object from the constructor function.
2021-06-10 23:17:29 +02:00
auto& global_object = function.global_object();
LibJS: Create new object earlier in VM::construct() Also make use of OrdinaryCreateFromConstructor() instead of setting the prototype manually. This fixes 2 function tests in test262. :^)
2021-06-25 23:41:24 +02:00
Value this_argument;
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
if (function.constructor_kind() == FunctionObject::ConstructorKind::Base) {
LibJS: Create new object earlier in VM::construct() Also make use of OrdinaryCreateFromConstructor() instead of setting the prototype manually. This fixes 2 function tests in test262. :^)
2021-06-25 23:41:24 +02:00
this_argument = ordinary_create_from_constructor<Object>(global_object, new_target, &GlobalObject::object_prototype);
if (exception())
return {};
}
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
ExecutionContext callee_context;
callee_context.function = &function;
LibJS: Move AST node stack from VM to Interpreter
2021-03-21 12:18:56 +01:00
if (auto* interpreter = interpreter_if_exists())
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
callee_context.current_node = interpreter->current_node();
callee_context.is_strict_mode = function.is_strict_mode();
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
push_execution_context(callee_context, global_object);
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
if (exception())
return {};
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
ArmedScopeGuard pop_guard = [&] {
pop_execution_context();
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
};
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
callee_context.function_name = function.name();
callee_context.arguments = function.bound_arguments();
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
if (arguments.has_value())
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
callee_context.arguments.extend(arguments.value().values());
LibJS: FunctionEnvironment.[[FunctionObject]] is the *invoked* function We were setting the wrong [[FunctionObject]] on the environment when going through ProxyObject and BoundFunction.
2021-06-25 20:14:17 +02:00
auto* environment = function.create_environment_record(function);
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
callee_context.lexical_environment = environment;
callee_context.variable_environment = environment;
LibJS: Create new object earlier in VM::construct() Also make use of OrdinaryCreateFromConstructor() instead of setting the prototype manually. This fixes 2 function tests in test262. :^)
2021-06-25 23:41:24 +02:00
if (environment) {
LibJS: Don't create lexical environment for native (C++) function calls This was creating a ton of pointless busywork for the garbage collector and can be avoided simply by tolerating that the current call frame has a null scope object for the duration of a NativeFunction activation.
2021-06-09 20:52:35 +02:00
environment->set_new_target(&new_target);
LibJS: Create new object earlier in VM::construct() Also make use of OrdinaryCreateFromConstructor() instead of setting the prototype manually. This fixes 2 function tests in test262. :^)
2021-06-25 23:41:24 +02:00
if (!this_argument.is_empty()) {
environment->bind_this_value(global_object, this_argument);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
if (exception())
return {};
}
}
// If we are a Derived constructor, |this| has not been constructed before super is called.
LibJS: Create new object earlier in VM::construct() Also make use of OrdinaryCreateFromConstructor() instead of setting the prototype manually. This fixes 2 function tests in test262. :^)
2021-06-25 23:41:24 +02:00
callee_context.this_value = this_argument;
LibJS: Remove Interpreter& argument to Function::construct() This is no longer needed, we can get everything we need from the VM.
2020-09-27 18:45:21 +02:00
auto result = function.construct(new_target);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
LibJS: Create new object earlier in VM::construct() Also make use of OrdinaryCreateFromConstructor() instead of setting the prototype manually. This fixes 2 function tests in test262. :^)
2021-06-25 23:41:24 +02:00
Value this_value = this_argument;
LibJS: Don't create lexical environment for native (C++) function calls This was creating a ton of pointless busywork for the garbage collector and can be avoided simply by tolerating that the current call frame has a null scope object for the duration of a NativeFunction activation.
2021-06-09 20:52:35 +02:00
if (environment)
this_value = environment->get_this_binding(global_object);
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
pop_execution_context();
pop_guard.disarm();
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
// If we are constructing an instance of a derived class,
// set the prototype on objects created by constructors that return an object (i.e. NativeFunction subclasses).
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
if (function.constructor_kind() == FunctionObject::ConstructorKind::Base && new_target.constructor_kind() == FunctionObject::ConstructorKind::Derived && result.is_object()) {
LibJS: Don't create lexical environment for native (C++) function calls This was creating a ton of pointless busywork for the garbage collector and can be avoided simply by tolerating that the current call frame has a null scope object for the duration of a NativeFunction activation.
2021-06-09 20:52:35 +02:00
if (environment) {
Userland: Replace VERIFY(is<T>) with verify_cast<T> Instead of doing a VERIFY(is<T>(x)) and *then* casting it to T, we can just do the cast right away with verify_cast<T>. :^)
2021-06-24 21:13:09 +02:00
verify_cast<FunctionEnvironmentRecord>(lexical_environment())->replace_this_binding(result);
LibJS: Don't create lexical environment for native (C++) function calls This was creating a ton of pointless busywork for the garbage collector and can be avoided simply by tolerating that the current call frame has a null scope object for the duration of a NativeFunction activation.
2021-06-09 20:52:35 +02:00
}
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
auto prototype = new_target.get(names.prototype);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
if (exception())
return {};
if (prototype.is_object()) {
result.as_object().set_prototype(&prototype.as_object());
if (exception())
return {};
}
return result;
}
if (exception())
return {};
if (result.is_object())
return result;
return this_value;
}
LibJS: Add set_exception() and change throw_exception() to take a reference Sometimes we just want to set m_exception to some value we stored previously, without really "throwing" it again - that's what set_exception() does now. Since we have clear_exception(), it does take a reference, i.e. you don't set_exception(nullptr). For consistency I updated throw_exception() to do the same.
2021-04-13 01:02:38 +02:00
void VM::throw_exception(Exception& exception)
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
{
LibJS: Add set_exception() and change throw_exception() to take a reference Sometimes we just want to set m_exception to some value we stored previously, without really "throwing" it again - that's what set_exception() does now. Since we have clear_exception(), it does take a reference, i.e. you don't set_exception(nullptr). For consistency I updated throw_exception() to do the same.
2021-04-13 01:02:38 +02:00
set_exception(exception);
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
unwind(ScopeType::Try);
}
LibJS: Evaluate `this` in terms of ResolveThisBinding
2021-06-25 11:40:03 +02:00
// 9.4.4 ResolveThisBinding ( ), https://tc39.es/ecma262/#sec-resolvethisbinding
Value VM::resolve_this_binding(GlobalObject& global_object)
{
auto& environment = get_this_environment(*this);
return environment.get_this_binding(global_object);
}
LibJS: Implement console.assert()
2021-04-18 17:08:14 +02:00
String VM::join_arguments(size_t start_index) const
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
{
StringBuilder joined_arguments;
LibJS: Implement console.assert()
2021-04-18 17:08:14 +02:00
for (size_t i = start_index; i < argument_count(); ++i) {
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
joined_arguments.append(argument(i).to_string_without_side_effects().characters());
if (i != argument_count() - 1)
joined_arguments.append(' ');
}
return joined_arguments.build();
}
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
Value VM::get_new_target()
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
{
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
auto& env = get_this_environment(*this);
Userland: Replace VERIFY(is<T>) with verify_cast<T> Instead of doing a VERIFY(is<T>(x)) and *then* casting it to T, we can just do the cast right away with verify_cast<T>. :^)
2021-06-24 21:13:09 +02:00
return verify_cast<FunctionEnvironmentRecord>(env).new_target();
LibJS: Move most of Interpreter into VM 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.
2020-09-27 15:18:55 +02:00
}
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
Value VM::call_internal(FunctionObject& function, Value this_value, Optional<MarkedValueList> arguments)
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!exception());
LibJS: VERIFY(!this_value.is_empty()) in VM::call_internal() Just a sanity check, this must never happen. Manual invocations of call() e.g. in LibWeb bindings must pass js_undefined() if no specific this value is desired, which OrdinaryCallBindThis will then use as-is or turn into the global this value in non-strict mode.
2021-03-26 19:40:55 +01:00
VERIFY(!this_value.is_empty());
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
ExecutionContext callee_context;
callee_context.function = &function;
LibJS: Move AST node stack from VM to Interpreter
2021-03-21 12:18:56 +01:00
if (auto* interpreter = interpreter_if_exists())
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
callee_context.current_node = interpreter->current_node();
callee_context.is_strict_mode = function.is_strict_mode();
callee_context.function_name = function.name();
callee_context.this_value = function.bound_this().value_or(this_value);
callee_context.arguments = function.bound_arguments();
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
if (arguments.has_value())
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
callee_context.arguments.extend(arguments.value().values());
LibJS: FunctionEnvironment.[[FunctionObject]] is the *invoked* function We were setting the wrong [[FunctionObject]] on the environment when going through ProxyObject and BoundFunction.
2021-06-25 20:14:17 +02:00
auto* environment = function.create_environment_record(function);
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
callee_context.lexical_environment = environment;
callee_context.variable_environment = environment;
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
LibJS: Don't create lexical environment for native (C++) function calls This was creating a ton of pointless busywork for the garbage collector and can be avoided simply by tolerating that the current call frame has a null scope object for the duration of a NativeFunction activation.
2021-06-09 20:52:35 +02:00
if (environment) {
LibJS: Bring function environment records closer to the spec This patch adds FunctionEnvironmentRecord as a subclass of the existing DeclarativeEnvironmentRecord. Things that are specific to function environment records move into there, simplifying the base. Most of the abstract operations related to function environment records are rewritten to match the spec exactly. I also had to implement GetThisEnvironment() and GetSuperConstructor() to keep tests working after the changes, so that's nice as well. :^)
2021-06-22 13:30:48 +02:00
VERIFY(environment->this_binding_status() == FunctionEnvironmentRecord::ThisBindingStatus::Uninitialized);
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
environment->bind_this_value(function.global_object(), callee_context.this_value);
LibJS: Don't create lexical environment for native (C++) function calls This was creating a ton of pointless busywork for the garbage collector and can be avoided simply by tolerating that the current call frame has a null scope object for the duration of a NativeFunction activation.
2021-06-09 20:52:35 +02:00
}
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
if (exception())
return {};
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
LibJS: Rename the context in Call/Construct ops to "callee context" This matches what the spec calls them.
2021-06-25 20:10:00 +02:00
push_execution_context(callee_context, function.global_object());
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
if (exception())
return {};
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
auto result = function.call();
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
pop_execution_context();
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
return result;
}
LibJS: Move "strict mode" state to the call stack Each call frame now knows whether it's executing in strict mode. It's no longer necessary to access the scope stack to find this mode.
2020-10-04 13:54:44 +02:00
bool VM::in_strict_mode() const
{
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
if (execution_context_stack().is_empty())
LibJS: Move "strict mode" state to the call stack Each call frame now knows whether it's executing in strict mode. It's no longer necessary to access the scope stack to find this mode.
2020-10-04 13:54:44 +02:00
return false;
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
return running_execution_context().is_strict_mode;
LibJS: Move "strict mode" state to the call stack Each call frame now knows whether it's executing in strict mode. It's no longer necessary to access the scope stack to find this mode.
2020-10-04 13:54:44 +02:00
}
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
void VM::run_queued_promise_jobs()
{
dbgln_if(PROMISE_DEBUG, "Running queued promise jobs");
// Temporarily get rid of the exception, if any - job functions must be called
// either way, and that can't happen if we already have an exception stored.
LibJS: Add TemporaryClearException helper class This is very similar to AK::TemporaryChange (and in fact replaces one use of it), but since we can't directly set VM's m_exception from outside of the VM, we need something more sophisticated. Sometimes we need to temporarily remove the stored exception for some other operation to succeed (e.g. anything that uses call(), as well as get_without_side_effects()) and later restore it - the boilerplate code required for this is annoying enough to justify a helper.
2021-04-24 17:56:16 +02:00
TemporaryClearException clear_exception(*this);
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
while (!m_promise_jobs.is_empty()) {
auto* job = m_promise_jobs.take_first();
dbgln_if(PROMISE_DEBUG, "Calling promise job function @ {}", job);
[[maybe_unused]] auto result = call(*job, js_undefined());
}
// Ensure no job has created a new exception, they must clean up after themselves.
VERIFY(!m_exception);
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 9.5.4 HostEnqueuePromiseJob ( job, realm ), https://tc39.es/ecma262/#sec-hostenqueuepromisejob
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
void VM::enqueue_promise_job(NativeFunction& job)
{
m_promise_jobs.append(&job);
}
LibJS: Add the FinalizationRegistry built-in object As well as the needed functionality in VM to enqueue and run cleanup jobs for the FinalizationRegistry instances.
2021-06-15 22:16:17 +03:00
void VM::run_queued_finalization_registry_cleanup_jobs()
{
while (!m_finalization_registry_cleanup_jobs.is_empty()) {
auto* registry = m_finalization_registry_cleanup_jobs.take_first();
registry->cleanup();
}
}
// 9.10.4.1 HostEnqueueFinalizationRegistryCleanupJob ( finalizationRegistry ), https://tc39.es/ecma262/#sec-host-cleanup-finalization-registry
void VM::enqueue_finalization_registry_cleanup_job(FinalizationRegistry& registry)
{
m_finalization_registry_cleanup_jobs.append(&registry);
}
LibJS: Add ECMA-262 section/title/URL comments almost everywhere As mentioned on Discord earlier, we'll add these to all new functions going forward - this is the backfill. Reasons: - It makes you look at the spec, implementing based on MDN or V8 behavior is a no-go - It makes finding the various functions that are non-compliant easier, in the future everything should either have such a comment or, if it's not from the spec at all, a comment explaining why that is the case - It makes it easier to check whether a certain abstract operation is implemented in LibJS, not all of them use the same name as the spec. E.g. RejectPromise() is Promise::reject() - It makes it easier to reason about vm.arguments(), e.g. when the function has a rest parameter - It makes it easier to see whether a certain function is from a proposal or Annex B Also: - Add arguments to all functions and abstract operations that already had a comment - Fix some outdated section numbers - Replace some ecma-international.org URLs with tc39.es
2021-06-13 00:22:35 +01:00
// 27.2.1.9 HostPromiseRejectionTracker ( promise, operation ), https://tc39.es/ecma262/#sec-host-promise-rejection-tracker
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
void VM::promise_rejection_tracker(const Promise& promise, Promise::RejectionOperation operation) const
{
switch (operation) {
case Promise::RejectionOperation::Reject:
// A promise was rejected without any handlers
if (on_promise_unhandled_rejection)
on_promise_unhandled_rejection(promise);
break;
case Promise::RejectionOperation::Handle:
// A handler was added to an already rejected promise
if (on_promise_rejection_handled)
on_promise_rejection_handled(promise);
break;
default:
VERIFY_NOT_REACHED();
}
}
LibJS: Add VM::dump_backtrace() This is just a simple helper that dumps the current VM call stack to the debug console. I find myself rewriting this function over and over, so let's just have it in the tree.
2021-06-06 22:53:44 +02:00
void VM::dump_backtrace() const
{
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
for (ssize_t i = m_execution_context_stack.size() - 1; i >= 0; --i)
dbgln("-> {}", m_execution_context_stack[i]->function_name);
LibJS: Add VM::dump_backtrace() This is just a simple helper that dumps the current VM call stack to the debug console. I find myself rewriting this function over and over, so let's just have it in the tree.
2021-06-06 22:53:44 +02:00
}
LibJS: Rename VM::current_scope() => current_environment_record() And rename some related functions that wrapped this as well.
2021-06-21 23:47:44 +02:00
void VM::dump_environment_record_chain() const
LibJS: Add VM::dump_scope_chain() This is a handy helper that dumps the current scope chain, starting at the innermost scope.
2021-06-21 20:54:02 +02:00
{
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
for (auto* environment_record = lexical_environment(); environment_record; environment_record = environment_record->outer_environment()) {
LibJS: Rename EnvironmentRecord::parent() => outer_environment() This name matches the spec (corresponds to the [[OuterEnv]] slot.)
2021-06-21 23:35:30 +02:00
dbgln("+> {} ({:p})", environment_record->class_name(), environment_record);
if (is<DeclarativeEnvironmentRecord>(*environment_record)) {
auto& declarative_environment_record = static_cast<DeclarativeEnvironmentRecord const&>(*environment_record);
for (auto& variable : declarative_environment_record.variables()) {
LibJS: Add VM::dump_scope_chain() This is a handy helper that dumps the current scope chain, starting at the innermost scope.
2021-06-21 20:54:02 +02:00
dbgln(" {}", variable.key);
}
}
}
}
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter 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.
2020-09-20 19:24:44 +02:00
}
Reference in a new issue Copy permalink