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/Interpreter.cpp

179 lines
5.7 KiB
C++
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
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: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*/
LibJS: Move join_args() in Interpreter It can be useful outside of Runtime/ConsoleObject.cpp. join_args() => Interpreter::join_arguments()
2020-05-04 12:34:49 +02:00
#include <AK/StringBuilder.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
#include <LibJS/AST.h>
#include <LibJS/Interpreter.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 21:58:22 +02:00
#include <LibJS/Runtime/LexicalEnvironment.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Object.h>
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 12:37:27 +02:00
#include <LibJS/Runtime/Reference.h>
LibJS: Hoist function declarations This patch adds function declaration hoisting. The mechanism is similar to var hoisting. Hoisted function declarations are to be put before the hoisted var declarations, hence they have to be treated separately.
2020-06-04 14:48:36 +02:00
#include <LibJS/Runtime/ScriptFunction.h>
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
#include <LibJS/Runtime/Shape.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
namespace JS {
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
NonnullOwnPtr<Interpreter> Interpreter::create_with_existing_global_object(GlobalObject& global_object)
{
DeferGC defer_gc(global_object.heap());
auto interpreter = adopt_own(*new Interpreter(global_object.vm()));
interpreter->m_global_object = make_handle(static_cast<Object*>(&global_object));
return 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
Interpreter::Interpreter(VM& vm)
: m_vm(vm)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
}
Interpreter::~Interpreter()
{
}
LibJS: Make Interpreter::run() a void function With one small exception, this is how we've been using this API already, and it makes sense: a Program is just a ScopeNode with any number of statements, which are executed one by one. There's no explicit return value at the end, only a completion value of the last value-producing statement, which we then access using VM::last_value() if needed (e.g. in the REPL).
2021-03-16 09:09:56 +01:00
void Interpreter::run(GlobalObject& global_object, const Program& program)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01: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
auto& vm = this->vm();
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(!vm.exception());
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
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
VM::InterpreterExecutionScope scope(*this);
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
vm.set_last_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
CallFrame global_call_frame;
LibJS: Keep track of current AST node inside the call stack
2021-02-28 10:45:26 +01:00
global_call_frame.current_node = &program;
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
global_call_frame.this_value = &global_object;
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
static FlyString global_execution_context_name = "(global execution context)";
global_call_frame.function_name = global_execution_context_name;
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
global_call_frame.scope = &global_object;
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(!vm.exception());
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
global_call_frame.is_strict_mode = program.is_strict_mode();
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
vm.push_call_frame(global_call_frame, global_object);
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(!vm.exception());
LibJS: Make Interpreter::run() a void function With one small exception, this is how we've been using this API already, and it makes sense: a Program is just a ScopeNode with any number of statements, which are executed one by one. There's no explicit return value at the end, only a completion value of the last value-producing statement, which we then access using VM::last_value() if needed (e.g. in the REPL).
2021-03-16 09:09:56 +01:00
program.execute(*this, global_object);
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
LibJS: Add VM::on_call_stack_emptied callback Instead of having to run queued promise jobs in LibWeb in various places, this allows us to consolidate that into one function - this is very close to how the spec describes it as well ("at some future point in time, when there is no running execution context and the execution context stack is empty, the implementation must [...]"). Eventually this will also be used to log unhandled exceptions, and possibly other actions that require JS execution to have ended.
2021-04-24 18:21:02 +02:00
// Whatever the promise jobs or on_call_stack_emptied do should not affect the effective
// 'last 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
auto last_value = vm.last_value();
LibJS: Add VM::on_call_stack_emptied callback Instead of having to run queued promise jobs in LibWeb in various places, this allows us to consolidate that into one function - this is very close to how the spec describes it as well ("at some future point in time, when there is no running execution context and the execution context stack is empty, the implementation must [...]"). Eventually this will also be used to log unhandled exceptions, and possibly other actions that require JS execution to have ended.
2021-04-24 18:21:02 +02:00
vm.pop_call_frame();
// At this point we may have already run any queued promise jobs via on_call_stack_emptied,
// in which case this is a no-op.
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
vm.run_queued_promise_jobs();
LibJS: Add VM::on_call_stack_emptied callback Instead of having to run queued promise jobs in LibWeb in various places, this allows us to consolidate that into one function - this is very close to how the spec describes it as well ("at some future point in time, when there is no running execution context and the execution context stack is empty, the implementation must [...]"). Eventually this will also be used to log unhandled exceptions, and possibly other actions that require JS execution to have ended.
2021-04-24 18:21:02 +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
vm.set_last_value({}, last_value.value_or(js_undefined()));
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
}
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
GlobalObject& Interpreter::global_object()
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 12:37:27 +02:00
{
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
return static_cast<GlobalObject&>(*m_global_object.cell());
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 12:37:27 +02:00
}
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
const GlobalObject& Interpreter::global_object() const
LibJS: Make sure we mark everything reachable from the scope stack This ensures that local variables survive GC.
2020-03-09 21:29:22 +01:00
{
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
return static_cast<const GlobalObject&>(*m_global_object.cell());
LibJS: Make sure we mark everything reachable from the scope stack This ensures that local variables survive GC.
2020-03-09 21:29:22 +01:00
}
LibJS: Get rid of Argument and ArgumentVector This was used for a feature where you could pass a vector of arguments to enter_scope(). Since that way of passing arguments was not GC-aware (as vectors use C++ heap storage), let's avoid using it and make sure everything that needs to stay alive is either on the stack or in traced storage instead.
2020-12-08 18:21:55 +01:00
void Interpreter::enter_scope(const ScopeNode& scope_node, ScopeType scope_type, GlobalObject& global_object)
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
{
for (auto& declaration : scope_node.functions()) {
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
auto* function = ScriptFunction::create(global_object, declaration.name(), declaration.body(), declaration.parameters(), declaration.function_length(), current_scope(), declaration.is_strict_mode());
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
vm().set_variable(declaration.name(), function, global_object);
}
if (scope_type == ScopeType::Function) {
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
push_scope({ scope_type, scope_node, false });
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
return;
}
HashMap<FlyString, Variable> scope_variables_with_declaration_kind;
scope_variables_with_declaration_kind.ensure_capacity(16);
for (auto& declaration : scope_node.variables()) {
for (auto& declarator : declaration.declarations()) {
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (is<Program>(scope_node)) {
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
global_object.put(declarator.id().string(), js_undefined());
if (exception())
return;
} else {
scope_variables_with_declaration_kind.set(declarator.id().string(), { js_undefined(), declaration.declaration_kind() });
}
}
}
bool pushed_lexical_environment = false;
if (!scope_variables_with_declaration_kind.is_empty()) {
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
auto* block_lexical_environment = heap().allocate<LexicalEnvironment>(global_object, move(scope_variables_with_declaration_kind), current_scope());
vm().call_frame().scope = block_lexical_environment;
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
pushed_lexical_environment = true;
}
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
push_scope({ scope_type, scope_node, pushed_lexical_environment });
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
}
void Interpreter::exit_scope(const ScopeNode& scope_node)
{
while (!m_scope_stack.is_empty()) {
auto popped_scope = m_scope_stack.take_last();
if (popped_scope.pushed_environment)
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
vm().call_frame().scope = vm().call_frame().scope->parent();
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
if (popped_scope.scope_node.ptr() == &scope_node)
break;
}
// If we unwind all the way, just reset m_unwind_until so that future "return" doesn't break.
if (m_scope_stack.is_empty())
LibJS: Replace two more uses of unwind(ScopeType::None) with stop_unwind() Same thing, but a lot more clear.
2021-04-13 00:32:32 +02:00
vm().stop_unwind();
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
}
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-03 17:02:43 -07:00
void Interpreter::push_scope(ScopeFrame frame)
{
m_scope_stack.append(move(frame));
}
LibJS: Get rid of Argument and ArgumentVector This was used for a feature where you could pass a vector of arguments to enter_scope(). Since that way of passing arguments was not GC-aware (as vectors use C++ heap storage), let's avoid using it and make sure everything that needs to stay alive is either on the stack or in traced storage instead.
2020-12-08 18:21:55 +01:00
Value Interpreter::execute_statement(GlobalObject& global_object, const Statement& statement, ScopeType scope_type)
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
{
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (!is<ScopeNode>(statement))
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
return statement.execute(*this, global_object);
auto& block = static_cast<const ScopeNode&>(statement);
LibJS: Get rid of Argument and ArgumentVector This was used for a feature where you could pass a vector of arguments to enter_scope(). Since that way of passing arguments was not GC-aware (as vectors use C++ heap storage), let's avoid using it and make sure everything that needs to stay alive is either on the stack or in traced storage instead.
2020-12-08 18:21:55 +01:00
enter_scope(block, scope_type, global_object);
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
for (auto& node : block.children()) {
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
auto value = node.execute(*this, global_object);
if (!value.is_empty())
vm().set_last_value({}, value);
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
if (vm().should_unwind()) {
if (!block.label().is_null() && vm().should_unwind_until(ScopeType::Breakable, block.label()))
vm().stop_unwind();
break;
}
}
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
if (scope_type == ScopeType::Function) {
bool did_return = vm().unwind_until() == ScopeType::Function;
if (!did_return)
vm().set_last_value({}, js_undefined());
}
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
if (vm().unwind_until() == scope_type)
LibJS: Replace two more uses of unwind(ScopeType::None) with stop_unwind() Same thing, but a lot more clear.
2021-04-13 00:32:32 +02:00
vm().stop_unwind();
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
exit_scope(block);
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
return vm().last_value();
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
}
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
LexicalEnvironment* Interpreter::current_environment()
{
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(is<LexicalEnvironment>(vm().call_frame().scope));
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
return static_cast<LexicalEnvironment*>(vm().call_frame().scope);
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Reference in a new issue Copy permalink