Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-20 08:03:21 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Interpreter.cpp

222 lines
8 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>
LibJS: Ensure function declarations don't leak outside function scopes When using VM::set_variable() to put the created ScriptFunction onto a ScopeObject, we would previously unexpectedly reach the global object as set_variable() checks each traversed scope for an existing Variable with the given name - which would cause a leak of the inner function past the outer function (we even had a test expecting that behaviour!). Now we first declare functions (as DeclarationKind::Var) before setting them. This will need some more work to make hoisting across non-lexical scopes work, but it fixes this specific issue for now. Fixes #6766.
2021-05-13 23:58:45 +01:00
* Copyright (c) 2020-2021, Linus Groh <linusg@serenityos.org>
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
*
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: Ensure function declarations don't leak outside function scopes When using VM::set_variable() to put the created ScriptFunction onto a ScopeObject, we would previously unexpectedly reach the global object as set_variable() checks each traversed scope for an existing Variable with the given name - which would cause a leak of the inner function past the outer function (we even had a test expecting that behaviour!). Now we first declare functions (as DeclarationKind::Var) before setting them. This will need some more work to make hoisting across non-lexical scopes work, but it fixes this specific issue for now. Fixes #6766.
2021-05-13 23:58:45 +01:00
#include <AK/ScopeGuard.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: 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: 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: 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: 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: 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: Change Interpreter::create_with_existing_{global_object => realm} We need both a GlobalObject and Realm now, but can get the former from the latter (once initialized). This also fixes JS execution in LibWeb, as we failed to set the Realm of the newly created Interpreter in this function.
2021-09-12 12:33:54 +01:00
NonnullOwnPtr<Interpreter> Interpreter::create_with_existing_realm(Realm& realm)
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: Change Interpreter::create_with_existing_{global_object => realm} We need both a GlobalObject and Realm now, but can get the former from the latter (once initialized). This also fixes JS execution in LibWeb, as we failed to set the Realm of the newly created Interpreter in this function.
2021-09-12 12:33:54 +01:00
auto& global_object = realm.global_object();
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
DeferGC defer_gc(global_object.heap());
auto interpreter = adopt_own(*new Interpreter(global_object.vm()));
LibJS: Allocate a Realm next to GlobalObject in Interpreter::create() Also pass a Realm reference to the Bytecode::Interpreter constructor, just like we pass the GlobalObject.
2021-09-11 19:36:25 +01:00
interpreter->m_global_object = make_handle(&global_object);
LibJS: Change Interpreter::create_with_existing_{global_object => realm} We need both a GlobalObject and Realm now, but can get the former from the latter (once initialized). This also fixes JS execution in LibWeb, as we failed to set the Realm of the newly created Interpreter in this function.
2021-09-12 12:33:54 +01:00
interpreter->m_realm = make_handle(&realm);
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
return 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: Move the GlobalEnvironment from GlobalObject to Realm This is where the spec wants to have it. Requires a couple of hacks as currently everything that needs a Realm actually has a GlobalObject, so we need to go via the Interpreter.
2021-09-11 20:27:36 +01:00
// FIXME: Why does this receive a GlobalObject? Interpreter has one already, and this might not be in sync with the Realm's GlobalObject.
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: Let the bytecode interpreter set the VM's last value
2021-06-10 21:01:44 +02:00
vm.set_last_value(Badge<Interpreter> {}, {});
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: Change ExecutionContext's arguments list to a MarkedValueList The test262 tests under RegExp/property-escapes/generated will invoke Reflect.apply with up to 10,000 arguments at a time. In LibJS, when the call stack reached VM::call_internal, we transfer those arguments from a MarkedValueList to the execution context's arguments Vector. Because these types differ (MarkedValueList is a Vector<Value, 32>), the arguments are copied rather than moved. By changing the arguments vector to a MarkedValueList, we can properly move the passed arguments over. This shaves about 2 seconds off the following test262 test (from 15sec): RegExp/property-escapes/generated/General_Category_-_Decimal_Number.js
2021-08-09 17:09:48 -04:00
ExecutionContext execution_context(heap());
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
execution_context.current_node = &program;
execution_context.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)";
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
execution_context.function_name = global_execution_context_name;
LibJS: Move the GlobalEnvironment from GlobalObject to Realm This is where the spec wants to have it. Requires a couple of hacks as currently everything that needs a Realm actually has a GlobalObject, so we need to go via the Interpreter.
2021-09-11 20:27:36 +01:00
execution_context.lexical_environment = &realm().global_environment();
execution_context.variable_environment = &realm().global_environment();
LibJS: Set the callee context's realm in prepare_for_ordinary_call() This includes making FunctionObject::realm() actually return a Realm, instead of a GlobalObject.
2021-09-11 21:42:01 +01:00
execution_context.realm = &realm();
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
execution_context.is_strict_mode = program.is_strict_mode();
vm.push_execution_context(execution_context, 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: Return undefined from a with statement if no value was generated Co-authored-by: Linus Groh <mail@linusgroh.de>
2021-06-08 16:49:06 +03:00
auto value = program.execute(*this, global_object);
LibJS: Let the bytecode interpreter set the VM's last value
2021-06-10 21:01:44 +02:00
vm.set_last_value(Badge<Interpreter> {}, value.value_or(js_undefined()));
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: 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
vm.pop_execution_context();
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
// 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: Store and maintain an "execution generation" counter This counter is increased each time a synchronous execution sequence completes, and will allow us to emulate the abstract operations AddToKeptObjects & ClearKeptObjects efficiently.
2021-06-12 17:32:54 +03:00
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
vm.run_queued_finalization_registry_cleanup_jobs();
LibJS: Store and maintain an "execution generation" counter This counter is increased each time a synchronous execution sequence completes, and will allow us to emulate the abstract operations AddToKeptObjects & ClearKeptObjects efficiently.
2021-06-12 17:32:54 +03:00
vm.finish_execution_generation();
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: Allocate a Realm next to GlobalObject in Interpreter::create() Also pass a Realm reference to the Bytecode::Interpreter constructor, just like we pass the GlobalObject.
2021-09-11 19:36:25 +01:00
Realm& Interpreter::realm()
{
return static_cast<Realm&>(*m_realm.cell());
}
const Realm& Interpreter::realm() const
{
return static_cast<const Realm&>(*m_realm.cell());
}
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
{
LibJS: Ensure function declarations don't leak outside function scopes When using VM::set_variable() to put the created ScriptFunction onto a ScopeObject, we would previously unexpectedly reach the global object as set_variable() checks each traversed scope for an existing Variable with the given name - which would cause a leak of the inner function past the outer function (we even had a test expecting that behaviour!). Now we first declare functions (as DeclarationKind::Var) before setting them. This will need some more work to make hoisting across non-lexical scopes work, but it fixes this specific issue for now. Fixes #6766.
2021-05-13 23:58:45 +01:00
ScopeGuard guard([&] {
LibJS: Improve function hoisting across blocks The parser now keeps track of a scope chain so that it can hoist function declarations to the closest function scope.
2021-07-04 03:15:52 +02:00
for (auto& declaration : scope_node.hoisted_functions()) {
lexical_environment()->put_into_environment(declaration.name(), { js_undefined(), DeclarationKind::Var });
}
LibJS: Ensure function declarations don't leak outside function scopes When using VM::set_variable() to put the created ScriptFunction onto a ScopeObject, we would previously unexpectedly reach the global object as set_variable() checks each traversed scope for an existing Variable with the given name - which would cause a leak of the inner function past the outer function (we even had a test expecting that behaviour!). Now we first declare functions (as DeclarationKind::Var) before setting them. This will need some more work to make hoisting across non-lexical scopes work, but it fixes this specific issue for now. Fixes #6766.
2021-05-13 23:58:45 +01:00
for (auto& declaration : scope_node.functions()) {
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
auto* function = OrdinaryFunctionObject::create(global_object, declaration.name(), declaration.body(), declaration.parameters(), declaration.function_length(), lexical_environment(), declaration.kind(), declaration.is_strict_mode());
LibJS: Ensure function declarations don't leak outside function scopes When using VM::set_variable() to put the created ScriptFunction onto a ScopeObject, we would previously unexpectedly reach the global object as set_variable() checks each traversed scope for an existing Variable with the given name - which would cause a leak of the inner function past the outer function (we even had a test expecting that behaviour!). Now we first declare functions (as DeclarationKind::Var) before setting them. This will need some more work to make hoisting across non-lexical scopes work, but it fixes this specific issue for now. Fixes #6766.
2021-05-13 23:58:45 +01:00
vm().set_variable(declaration.name(), function, 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
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: Ensure function declarations don't leak outside function scopes When using VM::set_variable() to put the created ScriptFunction onto a ScopeObject, we would previously unexpectedly reach the global object as set_variable() checks each traversed scope for an existing Variable with the given name - which would cause a leak of the inner function past the outer function (we even had a test expecting that behaviour!). Now we first declare functions (as DeclarationKind::Var) before setting them. This will need some more work to make hoisting across non-lexical scopes work, but it fixes this specific issue for now. Fixes #6766.
2021-05-13 23:58:45 +01:00
for (auto& declaration : scope_node.functions())
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
lexical_environment()->put_into_environment(declaration.name(), { js_undefined(), DeclarationKind::Var });
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);
LibJS: Only "var" declarations go in the global object at program level "let" and "const" go in the lexical environment. This fixes one part of #4001 (Lexically declared variables are mixed up with global object properties)
2021-06-09 23:21:42 +02:00
bool is_program_node = 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
for (auto& declaration : scope_node.variables()) {
for (auto& declarator : declaration.declarations()) {
LibJS: Only "var" declarations go in the global object at program level "let" and "const" go in the lexical environment. This fixes one part of #4001 (Lexically declared variables are mixed up with global object properties)
2021-06-09 23:21:42 +02:00
if (is_program_node && declaration.declaration_kind() == DeclarationKind::Var) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
declarator.target().visit(
[&](const NonnullRefPtr<Identifier>& id) {
LibJS: Remove the non-standard put helper and replace it's usages This removes all usages of the non-standard put helper method and replaces all of it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 01:15:50 +03:00
global_object.define_direct_property(id->string(), js_undefined(), JS::Attribute::Writable | JS::Attribute::Enumerable);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
},
[&](const NonnullRefPtr<BindingPattern>& binding) {
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
binding->for_each_bound_name([&](const auto& name) {
LibJS: Remove the non-standard put helper and replace it's usages This removes all usages of the non-standard put helper method and replaces all of it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 01:15:50 +03:00
global_object.define_direct_property(name, js_undefined(), JS::Attribute::Writable | JS::Attribute::Enumerable);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
});
});
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 (exception())
return;
} else {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
declarator.target().visit(
[&](const NonnullRefPtr<Identifier>& id) {
scope_variables_with_declaration_kind.set(id->string(), { js_undefined(), declaration.declaration_kind() });
},
[&](const NonnullRefPtr<BindingPattern>& binding) {
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
binding->for_each_bound_name([&](const auto& name) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
scope_variables_with_declaration_kind.set(name, { js_undefined(), declaration.declaration_kind() });
});
});
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: 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
bool pushed_environment = 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
if (!scope_variables_with_declaration_kind.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
auto* environment = heap().allocate<DeclarativeEnvironment>(global_object, move(scope_variables_with_declaration_kind), lexical_environment());
vm().running_execution_context().lexical_environment = environment;
vm().running_execution_context().variable_environment = environment;
pushed_environment = true;
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: 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
push_scope({ scope_type, scope_node, pushed_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();
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
if (popped_scope.pushed_environment) {
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
vm().running_execution_context().lexical_environment = vm().running_execution_context().lexical_environment->outer_environment();
vm().running_execution_context().variable_environment = vm().running_execution_context().variable_environment->outer_environment();
LibJS: Split the per-call-frame environment into lexical and variable To better follow the spec, we need to distinguish between the current execution context's lexical environment and variable environment. This patch moves us to having two record pointers, although both of them point at the same environment records for now.
2021-06-22 15:42:44 +02:00
}
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
LibJS: Return undefined from a with statement if no value was generated Co-authored-by: Linus Groh <mail@linusgroh.de>
2021-06-08 16:49:06 +03:00
Value 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
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())
LibJS: Return undefined from a with statement if no value was generated Co-authored-by: Linus Groh <mail@linusgroh.de>
2021-06-08 16:49:06 +03:00
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)
LibJS: Return undefined from a with statement if no value was generated Co-authored-by: Linus Groh <mail@linusgroh.de>
2021-06-08 16:49:06 +03:00
last_value = js_undefined();
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: 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: Return undefined from a with statement if no value was generated Co-authored-by: Linus Groh <mail@linusgroh.de>
2021-06-08 16:49:06 +03:00
return 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: 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
FunctionEnvironment* Interpreter::current_function_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
{
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>(vm().running_execution_context().lexical_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
}
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