beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-26 01:20:25 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
ladybird/Libraries/LibJS/Interpreter.cpp

227 lines
7.9 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 18:42:11 +00:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
LibJS: Make sure we mark everything reachable from the scope stack This ensures that local variables survive GC.
2020-03-09 20:29:22 +00:00
#include <AK/Badge.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 18:42:11 +00:00
#include <LibJS/AST.h>
#include <LibJS/Interpreter.h>
LibJS: Implement basic exception throwing You can now throw exceptions by calling Interpreter::throw_exception(). Anyone who calls ASTNode::execute() needs to check afterwards if the Interpreter now has an exception(), and if so, stop what they're doing and simply return. When catching an exception, we'll first execute the CatchClause node if present. After that, we'll execute the finalizer block if present. This is unlikely to be completely correct, but it's a start! :^)
2020-03-24 13:37:39 +00:00
#include <LibJS/Runtime/Error.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 13:20:30 +00: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 19:58:22 +00:00
#include <LibJS/Runtime/LexicalEnvironment.h>
LibJS: Add MarkedValueList and use it for argument passing A MarkedValueList is basically a Vector<JS::Value> that registers with the Heap and makes sure that the stored values don't get GC'd. Before this change, we were unsafely keeping Vector<JS::Value> in some places, which is out-of-reach for the live reference finding logic since Vector puts its elements on the heap by default. We now pass all the JavaScript tests even when running with "js -g", which does a GC on every heap allocation.
2020-04-19 15:24:56 +00:00
#include <LibJS/Runtime/MarkedValueList.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 13:20:30 +00:00
#include <LibJS/Runtime/NativeFunction.h>
#include <LibJS/Runtime/Object.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 17:32:21 +00: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 13:20:30 +00: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 18:42:11 +00:00
namespace JS {
Interpreter::Interpreter()
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 18:23:58 +00:00
: m_heap(*this)
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 18:42:11 +00:00
{
}
Interpreter::~Interpreter()
{
}
LibJS: Give argument vectors an inline capacity of 8 This avoids one malloc/free pair for every function call if there are 8 arguments or fewer.
2020-04-06 17:22:12 +00:00
Value Interpreter::run(const Statement& statement, ArgumentVector arguments, ScopeType scope_type)
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 18:42:11 +00:00
{
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 19:58:22 +00:00
if (statement.is_program()) {
if (m_call_stack.is_empty()) {
LibJS: Rename global_call_fram to global_call_frame Seems to be a typo.
2020-04-20 22:53:28 +00:00
CallFrame global_call_frame;
global_call_frame.this_value = m_global_object;
global_call_frame.function_name = "(global execution context)";
global_call_frame.environment = heap().allocate<LexicalEnvironment>();
m_call_stack.append(move(global_call_frame));
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 19:58:22 +00:00
}
}
LibJS: Implement "else" parsing We can now handle scripts with if/else in LibJS. Most of the changes are about fixing IfStatement to store the consequent and alternate node as Statements. Interpreter now also runs Statements, rather than running ScopeNodes.
2020-03-23 15:46:41 +00:00
if (!statement.is_scope_node())
return statement.execute(*this);
LibJS: Fix bad cast in Interpreter::run() We were casting to BlockStatement when we should cast to ScopeNode.
2020-04-02 07:53:27 +00:00
auto& block = static_cast<const ScopeNode&>(statement);
LibJS: Implement "else" parsing We can now handle scripts with if/else in LibJS. Most of the changes are about fixing IfStatement to store the consequent and alternate node as Statements. Interpreter now also runs Statements, rather than running ScopeNodes.
2020-03-23 15:46:41 +00:00
enter_scope(block, move(arguments), scope_type);
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 18:42:11 +00:00
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 18:24:45 +00:00
m_last_value = js_undefined();
LibJS: Implement "else" parsing We can now handle scripts with if/else in LibJS. Most of the changes are about fixing IfStatement to store the consequent and alternate node as Statements. Interpreter now also runs Statements, rather than running ScopeNodes.
2020-03-23 15:46:41 +00:00
for (auto& node : block.children()) {
LibJS: Don't return the "last computed value" from Interpreter::run() Only return whatever a "return" statment told us to return. The last computed value is now available in Interpreter::last_value() instead, where the REPL can pick it up.
2020-04-04 21:45:13 +00:00
m_last_value = node.execute(*this);
LibJS: Actually leave the current function scope on "return" We now unwind until the nearest function-level scope on the scope stack when executing a return statement.
2020-03-23 18:19:03 +00:00
if (m_unwind_until != ScopeType::None)
break;
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 18:42:11 +00:00
}
LibJS: Don't return the "last computed value" from Interpreter::run() Only return whatever a "return" statment told us to return. The last computed value is now available in Interpreter::last_value() instead, where the REPL can pick it up.
2020-04-04 21:45:13 +00:00
bool did_return = m_unwind_until == ScopeType::Function;
LibJS: Actually leave the current function scope on "return" We now unwind until the nearest function-level scope on the scope stack when executing a return statement.
2020-03-23 18:19:03 +00:00
if (m_unwind_until == scope_type)
m_unwind_until = ScopeType::None;
LibJS: Implement "else" parsing We can now handle scripts with if/else in LibJS. Most of the changes are about fixing IfStatement to store the consequent and alternate node as Statements. Interpreter now also runs Statements, rather than running ScopeNodes.
2020-03-23 15:46:41 +00:00
exit_scope(block);
LibJS: Don't return the "last computed value" from Interpreter::run() Only return whatever a "return" statment told us to return. The last computed value is now available in Interpreter::last_value() instead, where the REPL can pick it up.
2020-04-04 21:45:13 +00:00
return did_return ? m_last_value : js_undefined();
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 18:42:11 +00:00
}
LibJS: Give argument vectors an inline capacity of 8 This avoids one malloc/free pair for every function call if there are 8 arguments or fewer.
2020-04-06 17:22:12 +00:00
void Interpreter::enter_scope(const ScopeNode& scope_node, ArgumentVector arguments, ScopeType scope_type)
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 18:42:11 +00:00
{
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 19:58:22 +00:00
if (scope_type == ScopeType::Function) {
m_scope_stack.append({ scope_type, scope_node, false });
return;
}
LibJS: rename JS::DeclarationType => JS::DeclarationKind Many other parsers call it with this name. Also Type can be confusing in this context since the DeclarationType is not the type (number, string, etc.) of the variables that are being declared by the VariableDeclaration.
2020-04-08 09:59:18 +00:00
HashMap<FlyString, Variable> scope_variables_with_declaration_kind;
LibJS: Use HashMap::ensure_capacity() in enter_scope() Preallocate some space in the scope variable map. This avoids a bunch of incremental rehashing in the common case.
2020-04-13 15:23:42 +00:00
scope_variables_with_declaration_kind.ensure_capacity(16);
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 14:42:54 +00:00
for (auto& declaration : scope_node.variables()) {
for (auto& declarator : declaration.declarations()) {
if (scope_node.is_program())
global_object().put(declarator.id().string(), js_undefined());
else
scope_variables_with_declaration_kind.set(declarator.id().string(), { js_undefined(), declaration.declaration_kind() });
}
}
LibJS: Add NativeFunction, a callable wrapper around a C++ lambda This can be used to implement arbitrary functionality, callable from JavaScript. To make this work, I had to change the way CallExpression passes arguments to the callee. Instead of a HashMap<String, Value>, we now pass an ordered list of Argument { String name; Value value; }. This patch includes a native "print(argument)" function. :^)
2020-03-12 18:53:31 +00:00
for (auto& argument : arguments) {
LibJS: rename JS::DeclarationType => JS::DeclarationKind Many other parsers call it with this name. Also Type can be confusing in this context since the DeclarationType is not the type (number, string, etc.) of the variables that are being declared by the VariableDeclaration.
2020-04-08 09:59:18 +00:00
scope_variables_with_declaration_kind.set(argument.name, { argument.value, DeclarationKind::Var });
LibJS: Implement const variable declarations This also tightens the means of redeclaration of a variable by proxy, since we now have a way of knowing how a variable was initially declared, we can check if it was declared using `let` or `const` and not tolerate redeclaration like we did previously.
2020-03-12 12:24:34 +00:00
}
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 14:42:54 +00:00
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 19:58:22 +00:00
bool pushed_lexical_environment = false;
LibJS: Remove unreachable code in Interpreter::enter_scope() Functions are handled and short-circuited at the head of enter_scope().
2020-04-16 08:24:45 +00:00
if (!scope_variables_with_declaration_kind.is_empty()) {
auto* block_lexical_environment = heap().allocate<LexicalEnvironment>(move(scope_variables_with_declaration_kind), current_environment());
m_call_stack.last().environment = block_lexical_environment;
pushed_lexical_environment = true;
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 19:58:22 +00:00
}
m_scope_stack.append({ scope_type, scope_node, pushed_lexical_environment });
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 18:42:11 +00:00
}
void Interpreter::exit_scope(const ScopeNode& scope_node)
{
LibJS: Actually pop frames off of the scope stack when exiting a scope
2020-03-27 10:34:58 +00:00
while (!m_scope_stack.is_empty()) {
auto popped_scope = m_scope_stack.take_last();
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 19:58:22 +00:00
if (popped_scope.pushed_environment)
m_call_stack.last().environment = m_call_stack.last().environment->parent();
LibJS: Actually pop frames off of the scope stack when exiting a scope
2020-03-27 10:34:58 +00:00
if (popped_scope.scope_node.ptr() == &scope_node)
break;
}
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 18:42:11 +00:00
LibJS: Actually leave the current function scope on "return" We now unwind until the nearest function-level scope on the scope stack when executing a return statement.
2020-03-23 18:19:03 +00:00
// If we unwind all the way, just reset m_unwind_until so that future "return" doesn't break.
if (m_scope_stack.is_empty())
m_unwind_until = ScopeType::None;
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 18:42:11 +00:00
}
LibJS: Use FlyString for identifiers This makes variable and property lookups a lot faster since comparing two FlyStrings is O(1).
2020-03-22 10:07:55 +00:00
void Interpreter::set_variable(const FlyString& name, Value value, bool first_assignment)
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 20:13:55 +00:00
{
LibJS: Do not assume that a call frame exists in {get,set}_variable
2020-04-19 14:12:41 +00:00
if (m_call_stack.size()) {
for (auto* environment = current_environment(); environment; environment = environment->parent()) {
auto possible_match = environment->get(name);
if (possible_match.has_value()) {
if (!first_assignment && possible_match.value().declaration_kind == DeclarationKind::Const) {
throw_exception<TypeError>("Assignment to constant variable");
return;
}
environment->set(name, { value, possible_match.value().declaration_kind });
LibJS: Throw on assignment of an const variable Was stubbed out as an assert, should be handled with a runtime exception.
2020-04-12 22:50:49 +00:00
return;
}
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 20:13:55 +00:00
}
}
global_object().put(move(name), move(value));
}
LibJS: Stop using Optional<Value> in favor of Value's empty state JS::Value already has the empty state ({} or Value() gives you one.) Use this instead of wrapping Value in Optional in some places. I've also added Value::value_or(Value) so you can easily provide a fallback value when one is not present.
2020-04-25 16:43:34 +00:00
Value Interpreter::get_variable(const FlyString& name)
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 20:13:55 +00:00
{
LibJS: Do not assume that a call frame exists in {get,set}_variable
2020-04-19 14:12:41 +00:00
if (m_call_stack.size()) {
for (auto* environment = current_environment(); environment; environment = environment->parent()) {
auto possible_match = environment->get(name);
if (possible_match.has_value())
return possible_match.value().value;
}
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 20:13:55 +00:00
}
return global_object().get(name);
}
LibJS: Rename collect_roots() => gather_roots() Since this is about finding the things we should *not* garabge collect, it seemed wrong to call it "collect_something" :^)
2020-03-15 14:12:34 +00:00
void Interpreter::gather_roots(Badge<Heap>, HashTable<Cell*>& roots)
LibJS: Make sure we mark everything reachable from the scope stack This ensures that local variables survive GC.
2020-03-09 20:29:22 +00:00
{
roots.set(m_global_object);
LibJS: Implement basic exception throwing You can now throw exceptions by calling Interpreter::throw_exception(). Anyone who calls ASTNode::execute() needs to check afterwards if the Interpreter now has an exception(), and if so, stop what they're doing and simply return. When catching an exception, we'll first execute the CatchClause node if present. After that, we'll execute the finalizer block if present. This is unlikely to be completely correct, but it's a start! :^)
2020-03-24 13:37:39 +00:00
roots.set(m_exception);
LibJS: Make sure we mark everything reachable from the scope stack This ensures that local variables survive GC.
2020-03-09 20:29:22 +00:00
LibJS: Don't return the "last computed value" from Interpreter::run() Only return whatever a "return" statment told us to return. The last computed value is now available in Interpreter::last_value() instead, where the REPL can pick it up.
2020-04-04 21:45:13 +00:00
if (m_last_value.is_cell())
roots.set(m_last_value.as_cell());
LibJS: Protect function call "this" and arguments from GC This patch adds a CallFrame stack to Interpreter, which keeps track of the "this" value and all argument values passed in function calls. Interpreter::gather_roots() scans the call stack, making sure that all argument values get marked. :^)
2020-03-17 10:00:09 +00:00
for (auto& call_frame : m_call_stack) {
if (call_frame.this_value.is_cell())
roots.set(call_frame.this_value.as_cell());
for (auto& argument : call_frame.arguments) {
if (argument.is_cell())
roots.set(argument.as_cell());
}
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 19:58:22 +00:00
roots.set(call_frame.environment);
LibJS: Interpreter should make sure that the "this" stack gets marked
2020-03-15 14:07:49 +00:00
}
LibJS: Make sure we mark everything reachable from the scope stack This ensures that local variables survive GC.
2020-03-09 20:29:22 +00:00
}
LibJS: Add MarkedValueList and use it for argument passing A MarkedValueList is basically a Vector<JS::Value> that registers with the Heap and makes sure that the stored values don't get GC'd. Before this change, we were unsafely keeping Vector<JS::Value> in some places, which is out-of-reach for the live reference finding logic since Vector puts its elements on the heap by default. We now pass all the JavaScript tests even when running with "js -g", which does a GC on every heap allocation.
2020-04-19 15:24:56 +00:00
Value Interpreter::call(Function* function, Value this_value, Optional<MarkedValueList> arguments)
LibJS: Add Interpreter::call(Function*, this_value, arguments) This helper function takes care of pushing/popping a call frame so you don't need to worry about it.
2020-03-18 14:20:49 +00:00
{
auto& call_frame = push_call_frame();
LibJS: Make Function and CallFrame aware of their function name
2020-04-11 11:56:20 +00:00
call_frame.function_name = function->name();
LibJS: Add Interpreter::call(Function*, this_value, arguments) This helper function takes care of pushing/popping a call frame so you don't need to worry about it.
2020-03-18 14:20:49 +00:00
call_frame.this_value = this_value;
LibJS: Add MarkedValueList and use it for argument passing A MarkedValueList is basically a Vector<JS::Value> that registers with the Heap and makes sure that the stored values don't get GC'd. Before this change, we were unsafely keeping Vector<JS::Value> in some places, which is out-of-reach for the live reference finding logic since Vector puts its elements on the heap by default. We now pass all the JavaScript tests even when running with "js -g", which does a GC on every heap allocation.
2020-04-19 15:24:56 +00:00
if (arguments.has_value())
call_frame.arguments = arguments.value().values();
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 19:58:22 +00:00
call_frame.environment = function->create_environment();
LibJS: Rework how native functions are called to improve |this| value Native functions now only get the Interpreter& as an argument. They can then extract |this| along with any indexed arguments it wants from it. This forces functions that want |this| to actually deal with calling interpreter.this_value().to_object(), and dealing with the possibility of a non-object |this|. This is still not great but let's keep massaging it forward.
2020-03-28 21:48:35 +00:00
auto result = function->call(*this);
LibJS: Add Interpreter::call(Function*, this_value, arguments) This helper function takes care of pushing/popping a call frame so you don't need to worry about it.
2020-03-18 14:20:49 +00:00
pop_call_frame();
return result;
}
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 21:03:50 +00:00
Value Interpreter::throw_exception(Exception* exception)
LibJS: Implement basic exception throwing You can now throw exceptions by calling Interpreter::throw_exception(). Anyone who calls ASTNode::execute() needs to check afterwards if the Interpreter now has an exception(), and if so, stop what they're doing and simply return. When catching an exception, we'll first execute the CatchClause node if present. After that, we'll execute the finalizer block if present. This is unlikely to be completely correct, but it's a start! :^)
2020-03-24 13:37:39 +00:00
{
LibJS: Log when we throw a JavaScript Error This makes debugging a lot easier since we actually learn that an Error got thrown.
2020-04-04 20:14:03 +00:00
if (exception->value().is_object() && exception->value().as_object().is_error()) {
auto& error = static_cast<Error&>(exception->value().as_object());
dbg() << "Throwing JavaScript Error: " << error.name() << ", " << error.message();
LibJS: Dump a JavaScript backtrace when throwing exceptions
2020-04-16 18:23:03 +00:00
for (ssize_t i = m_call_stack.size() - 1; i >= 0; --i) {
auto function_name = m_call_stack[i].function_name;
if (function_name.is_empty())
function_name = "<anonymous>";
dbg() << " " << function_name;
}
LibJS: Log when we throw a JavaScript Error This makes debugging a lot easier since we actually learn that an Error got thrown.
2020-04-04 20:14:03 +00:00
}
LibJS: Implement basic exception throwing You can now throw exceptions by calling Interpreter::throw_exception(). Anyone who calls ASTNode::execute() needs to check afterwards if the Interpreter now has an exception(), and if so, stop what they're doing and simply return. When catching an exception, we'll first execute the CatchClause node if present. After that, we'll execute the finalizer block if present. This is unlikely to be completely correct, but it's a start! :^)
2020-03-24 13:37:39 +00:00
m_exception = exception;
unwind(ScopeType::Try);
return {};
}
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 09:05:38 +00:00
GlobalObject& Interpreter::global_object()
{
return static_cast<GlobalObject&>(*m_global_object);
}
const GlobalObject& Interpreter::global_object() const
{
return static_cast<const GlobalObject&>(*m_global_object);
}
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 18:42:11 +00:00
}
Reference in a new issue Copy permalink