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

707 lines
26 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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/FunctionEnvironment.h>
#include <LibJS/Runtime/GlobalEnvironment.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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
void VM::set_variable(const FlyString& name, Value value, GlobalObject& global_object, bool first_assignment, Environment* 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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
for (auto* environment = lexical_environment(); environment; environment = environment->outer_environment()) {
possible_match = environment->get_from_environment(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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
specific_scope = environment;
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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
specific_scope->put_into_environment(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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
specific_scope->put_into_environment(name, { value, DeclarationKind::Var });
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
return;
}
LibJS: Replace the boolean argument of Object::set with an enum class This is more serenity-esque and also makes pointing out missing exception checks during reviews much easier.
2021-07-16 15:16:27 +03:00
global_object.set(name, value, Object::ShouldThrowExceptions::Yes);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
}
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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
Environment* 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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
for (auto* environment = lexical_environment(); environment; environment = environment->outer_environment()) {
possible_match = environment->get_from_environment(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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
specific_scope = environment;
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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
return specific_scope->delete_from_environment(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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
void VM::assign(const FlyString& target, Value value, GlobalObject& global_object, bool first_assignment, Environment* 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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
void VM::assign(const Variant<NonnullRefPtr<Identifier>, NonnullRefPtr<BindingPattern>>& target, Value value, GlobalObject& global_object, bool first_assignment, Environment* 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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
void VM::assign(const NonnullRefPtr<BindingPattern>& target, Value value, GlobalObject& global_object, bool first_assignment, Environment* 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
LibJS: Bring ArrayCreate and ArrayConstructor closer to spec Specifically, this now explicitly takes the length, adds missing exceptions checks to calls with user-supplied lengths, takes and uses the prototype argument, and fixes some spec non-conformance in ArrayConstructor and its native functions around the use of ArrayCreate
2021-07-04 01:36:44 +03:00
auto* array = Array::create(global_object, 0);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
for (;;) {
auto next_object = iterator_next(*iterator);
if (!next_object)
return;
auto done_property = next_object->get(names.done);
if (exception())
return;
LibJS: Remove unnecessary value_or() from get() Object::get() never returns an empty value anymore, as per the spec, so having a value_or() fallback is no longer needed.
2021-07-04 22:55:45 +01:00
if (done_property.to_boolean())
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
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: Remove unnecessary value_or() from get() Object::get() never returns an empty value anymore, as per the spec, so having a value_or() fallback is no longer needed.
2021-07-04 22:55:45 +01:00
if (done_property.to_boolean()) {
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
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()) {
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
if (!object_property.value.attributes.is_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: Replace the boolean argument of Object::set with an enum class This is more serenity-esque and also makes pointing out missing exception checks during reviews much easier.
2021-07-16 15:16:27 +03:00
rest_object->set(object_property.key, object->get(object_property.key), Object::ShouldThrowExceptions::Yes);
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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
auto possible_match = lexical_environment()->get_from_environment(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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
for (auto* environment = lexical_environment(); environment; environment = environment->outer_environment()) {
auto possible_match = environment->get_from_environment(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;
LibJS: Make FunctionExpression more spec-compliant
2021-07-07 22:53:32 +02:00
if (environment->has_binding(name))
return environment->get_binding_value(global_object, name, false);
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: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
if (!global_object.storage_has(name)) {
if (m_underscore_is_last_value && name == "_")
return m_last_value;
return {};
}
return global_object.get(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: Improve ResolveBinding + add GetIdentifierReference ResolveBinding now matches the spec, while the non-conforming parts are moved to GetIdentifierReference. Implementing this properly requires variable bindings.
2021-07-02 21:54:56 +02:00
// 9.1.2.1 GetIdentifierReference ( env, name, strict ), https://tc39.es/ecma262/#sec-getidentifierreference
Reference VM::get_identifier_reference(Environment* environment, FlyString const& name, bool strict)
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: Improve ResolveBinding + add GetIdentifierReference ResolveBinding now matches the spec, while the non-conforming parts are moved to GetIdentifierReference. Implementing this properly requires variable bindings.
2021-07-02 21:54:56 +02:00
// 1. If env is the value null, then
if (!environment) {
// a. Return the Reference Record { [[Base]]: unresolvable, [[ReferencedName]]: name, [[Strict]]: strict, [[ThisValue]]: empty }.
return Reference { Reference::BaseType::Unresolvable, name, strict };
}
// FIXME: The remainder of this function is non-conforming.
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
LibJS: Improve ResolveBinding + add GetIdentifierReference ResolveBinding now matches the spec, while the non-conforming parts are moved to GetIdentifierReference. Implementing this properly requires variable bindings.
2021-07-02 21:54:56 +02:00
auto& global_object = environment->global_object();
for (; environment && environment->outer_environment(); environment = environment->outer_environment()) {
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
auto possible_match = environment->get_from_environment(name);
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
if (possible_match.has_value())
LibJS: Improve ResolveBinding + add GetIdentifierReference ResolveBinding now matches the spec, while the non-conforming parts are moved to GetIdentifierReference. Implementing this properly requires variable bindings.
2021-07-02 21:54:56 +02:00
return Reference { *environment, name, strict };
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: Improve ResolveBinding + add GetIdentifierReference ResolveBinding now matches the spec, while the non-conforming parts are moved to GetIdentifierReference. Implementing this properly requires variable bindings.
2021-07-02 21:54:56 +02:00
return Reference { global_object.environment(), name, strict };
}
// 9.4.2 ResolveBinding ( name [ , env ] ), https://tc39.es/ecma262/#sec-resolvebinding
Reference VM::resolve_binding(FlyString const& name, Environment* environment)
{
// 1. If env is not present or if env is undefined, then
if (!environment) {
// a. Set env to the running execution context's LexicalEnvironment.
environment = running_execution_context().lexical_environment;
}
// 2. Assert: env is an Environment Record.
VERIFY(environment);
// 3. If the code matching the syntactic production that is being evaluated is contained in strict mode code, let strict be true; else let strict be false.
bool strict = in_strict_mode();
// 4. Return ? GetIdentifierReference(env, name, strict).
return get_identifier_reference(environment, name, strict);
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;
LibJS: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
prepare_for_ordinary_call(function, callee_context, &new_target);
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: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +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
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: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
if (auto* interpreter = interpreter_if_exists())
callee_context.current_node = interpreter->current_node();
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 = 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: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
if (auto* environment = callee_context.lexical_environment) {
auto& function_environment = verify_cast<FunctionEnvironment>(*environment);
function_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()) {
LibJS: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
function_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: 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: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
if (auto* environment = callee_context.lexical_environment)
verify_cast<FunctionEnvironment>(environment)->replace_this_binding(result);
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()) {
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
result.as_object().internal_set_prototype_of(&prototype.as_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
if (exception())
return {};
}
return result;
}
if (exception())
return {};
if (result.is_object())
return result;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
if (auto* environment = callee_context.lexical_environment)
return environment->get_this_binding(global_object);
return 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
}
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);
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
return verify_cast<FunctionEnvironment>(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: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
// 10.2.1.1 PrepareForOrdinaryCall ( F, newTarget ), https://tc39.es/ecma262/#sec-prepareforordinarycall
void VM::prepare_for_ordinary_call(FunctionObject& function, ExecutionContext& callee_context, Value new_target)
{
// NOTE: This is a LibJS specific hack for NativeFunction to inherit the strictness of its caller.
// FIXME: I feel like we should be able to get rid of this.
if (is<NativeFunction>(function))
callee_context.is_strict_mode = in_strict_mode();
else
callee_context.is_strict_mode = function.is_strict_mode();
// 1. Assert: Type(newTarget) is Undefined or Object.
VERIFY(new_target.is_undefined() || new_target.is_object());
// 2. Let callerContext be the running execution context.
// 3. Let calleeContext be a new ECMAScript code execution context.
// NOTE: In the specification, PrepareForOrdinaryCall "returns" a new callee execution context.
// To avoid heap allocations, we put our ExecutionContext objects on the C++ stack instead.
// Whoever calls us should put an ExecutionContext on their stack and pass that as the `callee_context`.
// 4. Set the Function of calleeContext to F.
callee_context.function = &function;
callee_context.function_name = function.name();
// 5. Let calleeRealm be F.[[Realm]].
// 6. Set the Realm of calleeContext to calleeRealm.
// 7. Set the ScriptOrModule of calleeContext to F.[[ScriptOrModule]].
// FIXME: Our execution context struct currently does not track these items.
// 8. Let localEnv be NewFunctionEnvironment(F, newTarget).
// FIXME: This should call NewFunctionEnvironment instead of the ad-hoc FunctionObject::create_environment()
auto* local_environment = function.create_environment(function);
// 9. Set the LexicalEnvironment of calleeContext to localEnv.
callee_context.lexical_environment = local_environment;
// 10. Set the VariableEnvironment of calleeContext to localEnv.
callee_context.variable_environment = local_environment;
// 11. Set the PrivateEnvironment of calleeContext to F.[[PrivateEnvironment]].
// FIXME: We currently don't support private environments.
// 12. If callerContext is not already suspended, suspend callerContext.
// FIXME: We don't have this concept yet.
// 13. Push calleeContext onto the execution context stack; calleeContext is now the running execution context.
push_execution_context(callee_context, function.global_object());
// 14. NOTE: Any exception objects produced after this point are associated with calleeRealm.
// 15. Return calleeContext. (See NOTE above about how contexts are allocated on the C++ stack.)
}
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;
LibJS: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
prepare_for_ordinary_call(function, callee_context, js_undefined());
if (exception())
return {};
ScopeGuard pop_guard = [&] {
pop_execution_context();
};
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();
LibJS: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +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.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: 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: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
if (auto* environment = callee_context.lexical_environment) {
auto& function_environment = verify_cast<FunctionEnvironment>(*environment);
VERIFY(function_environment.this_binding_status() == FunctionEnvironment::ThisBindingStatus::Uninitialized);
function_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: Implement the PrepareForOrdinaryCall abstract operation This is used by VM::call_internal() and VM::construct() which roughly map to function objects' [[Call]] and [[Construct]] slots in the spec. Reorganizing this code revealed something weird: NativeFunction gets its strictness by checking VM::in_strict_mode(). In other words, it inherits the strict flag from the caller context. This is quite weird, but many test-js tests rely on it, so let's preserve it until we can think of something nicer.
2021-07-02 21:02:56 +02:00
return function.call();
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: 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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
void VM::dump_environment_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: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
for (auto* environment = lexical_environment(); environment; environment = environment->outer_environment()) {
dbgln("+> {} ({:p})", environment->class_name(), environment);
if (is<DeclarativeEnvironment>(*environment)) {
auto& declarative_environment = static_cast<DeclarativeEnvironment const&>(*environment);
for (auto& variable : declarative_environment.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