Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 21:30:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Interpreter.h

238 lines
7.5 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>
* 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.
*/
#pragma once
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 22:03:50 +01:00
#include <AK/FlyString.h>
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
#include <AK/HashMap.h>
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 19:53:31 +01:00
#include <AK/String.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 <AK/Vector.h>
Browser: Add JS Console The JavaScript console can be opened with Control+I, or using the menu option. The console is currently a text box with JS syntax highlighting which will send commands to the document's interpreter. All output is printed to an HTML view in the console. The output is an HtmlView to easily allow complex output, such as expandable views for JS Objects in the long run.
2020-05-23 12:53:09 -04:00
#include <AK/Weakable.h>
LibJS: Add strict mode Adds the ability for a scope (either a function or the entire program) to be in strict mode. Scopes default to non-strict mode. There are two ways to determine the strict-ness of the JS engine: 1. In the parser, this can be accessed with the parser_state variable m_is_strict_mode boolean. If true, the Parser is currently parsing in strict mode. This is done so that the Parser can generate syntax errors at parse time, which is required in some cases. 2. With Interpreter.is_strict_mode(). This allows strict mode checking at runtime as opposed to compile time. Additionally, in order to test this, a global isStrictMode() function has been added to the JS ReplObject under the test-mode flag.
2020-05-27 22:22:08 -07:00
#include <LibJS/AST.h>
LibJS: Start implementing a Console class for the interpreter The goal is to start factoring out core ConsoleObject functionality and to make ConsoleObject only a JS wrapper around Console.
2020-05-01 14:40:43 +02:00
#include <LibJS/Console.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/Forward.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/Heap/Heap.h>
LibJS: Consolidate error messages into ErrorTypes.h Now, exceptions can be thrown with interpreter.throw_exception<T>(ErrorType:TYPE, "format", "args", "here").
2020-06-09 22:48:01 -07:00
#include <LibJS/Runtime/ErrorTypes.h>
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 22:03:50 +01:00
#include <LibJS/Runtime/Exception.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 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 17:24:56 +02: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 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: Allow the choice of a scope of declaration for a variable (#1408) Previously, we were assuming all declared variables were bound to a block scope, now, with the addition of declaration types, we can bind a variable to a block scope using `let`, or a function scope (the scope of the inner-most enclosing function of a `var` declaration) using `var`.
2020-03-11 21:09:20 +02:00
enum class ScopeType {
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 19:19:03 +01:00
None,
LibJS: Allow the choice of a scope of declaration for a variable (#1408) Previously, we were assuming all declared variables were bound to a block scope, now, with the addition of declaration types, we can bind a variable to a block scope using `let`, or a function scope (the scope of the inner-most enclosing function of a `var` declaration) using `var`.
2020-03-11 21:09:20 +02:00
Function,
Block,
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 14:37:39 +01:00
Try,
LibJS: Implement basic execution of "switch" statements The "break" keyword now unwinds to the nearest ScopeType::Breakable. There's no support for break labels yet, but we'll get there too.
2020-03-29 14:34:25 +02:00
Breakable,
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
Continuable,
LibJS: Allow the choice of a scope of declaration for a variable (#1408) Previously, we were assuming all declared variables were bound to a block scope, now, with the addition of declaration types, we can bind a variable to a block scope using `let`, or a function scope (the scope of the inner-most enclosing function of a `var` declaration) using `var`.
2020-03-11 21:09:20 +02: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
struct ScopeFrame {
LibJS: Allow the choice of a scope of declaration for a variable (#1408) Previously, we were assuming all declared variables were bound to a block scope, now, with the addition of declaration types, we can bind a variable to a block scope using `let`, or a function scope (the scope of the inner-most enclosing function of a `var` declaration) using `var`.
2020-03-11 21:09:20 +02:00
ScopeType type;
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 11:23:53 +01:00
NonnullRefPtr<ScopeNode> scope_node;
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
bool pushed_environment { false };
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: 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 11:00:09 +01:00
struct CallFrame {
LibJS: Make Function and CallFrame aware of their function name
2020-04-11 12:56:20 +01:00
FlyString function_name;
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 11:00:09 +01:00
Value this_value;
Vector<Value> arguments;
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
LexicalEnvironment* environment { nullptr };
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 11:00:09 +01:00
};
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 19:53:31 +01:00
struct Argument {
LibJS: Use FlyString for identifiers This makes variable and property lookups a lot faster since comparing two FlyStrings is O(1).
2020-03-22 11:07:55 +01:00
FlyString name;
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 19:53:31 +01:00
Value value;
};
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 19:22:12 +02:00
typedef Vector<Argument, 8> ArgumentVector;
Browser: Add JS Console The JavaScript console can be opened with Control+I, or using the menu option. The console is currently a text box with JS syntax highlighting which will send commands to the document's interpreter. All output is printed to an HTML view in the console. The output is an HtmlView to easily allow complex output, such as expandable views for JS Objects in the long run.
2020-05-23 12:53:09 -04:00
class Interpreter : public Weakable<Interpreter> {
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
public:
LibJS: Add Interpreter::create<GlobalObjectType>() Force Interpreter construction to go via a create() helper that takes the global object type as a template parameter.
2020-04-01 21:04:51 +02:00
template<typename GlobalObjectType, typename... Args>
static NonnullOwnPtr<Interpreter> create(Args&&... args)
LibWeb+LibJS: Move DOM Window object to dedicated classes LibWeb now creates a WindowObject which inherits from GlobalObject. Allocation of the global object is moved out of the Interpreter ctor to allow for specialized construction. The existing Window interfaces are moved to WindowObject with their implementation code in the new Window class.
2020-04-01 18:53:28 +02:00
{
LibJS: Add Interpreter::create<GlobalObjectType>() Force Interpreter construction to go via a create() helper that takes the global object type as a template parameter.
2020-04-01 21:04:51 +02:00
auto interpreter = adopt_own(*new Interpreter);
LibJS: Move native objects towards two-pass construction To make sure that everything is set up correctly in objects before we start adding properties to them, we split cell allocation into 3 steps: 1. Allocate a cell of appropriate size from the Heap 2. Call the C++ constructor on the cell 3. Call initialize() on the constructed object The job of initialize() is to define all the initial properties. Doing it in a second pass guarantees that the Object has a valid Shape and can find its own GlobalObject.
2020-06-20 15:40:48 +02:00
interpreter->m_global_object = interpreter->heap().allocate_without_global_object<GlobalObjectType>(forward<Args>(args)...);
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 13:18:06 +02:00
static_cast<GlobalObjectType*>(interpreter->m_global_object)->initialize();
LibJS: Add Interpreter::create<GlobalObjectType>() Force Interpreter construction to go via a create() helper that takes the global object type as a template parameter.
2020-04-01 21:04:51 +02:00
return interpreter;
LibWeb+LibJS: Move DOM Window object to dedicated classes LibWeb now creates a WindowObject which inherits from GlobalObject. Allocation of the global object is moved out of the Interpreter ctor to allow for specialized construction. The existing Window interfaces are moved to WindowObject with their implementation code in the new Window class.
2020-04-01 18:53:28 +02:00
}
LibJS: Add Interpreter::create<GlobalObjectType>() Force Interpreter construction to go via a create() helper that takes the global object type as a template parameter.
2020-04-01 21:04:51 +02:00
~Interpreter();
LibJS: Make more Interpreter functions take a GlobalObject&
2020-06-08 21:25:16 +02:00
Value run(GlobalObject&, const Statement&, ArgumentVector = {}, ScopeType = ScopeType::Block);
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: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
GlobalObject& global_object();
const GlobalObject& global_object() const;
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: 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 19:23:58 +01:00
Heap& heap() { return m_heap; }
LibJS: Integrate labels into the Interpreter The interpreter now considers a statement or block's label when considering whether or not to break. All statements can be labelled.
2020-05-28 13:36:59 -07:00
void unwind(ScopeType type, FlyString label = {})
{
m_unwind_until = type;
m_unwind_until_label = label;
}
LibJS: Make "break" actually work inside "switch"
2020-04-05 00:09:48 +02:00
void stop_unwind() { m_unwind_until = ScopeType::None; }
LibJS: Integrate labels into the Interpreter The interpreter now considers a statement or block's label when considering whether or not to break. All statements can be labelled.
2020-05-28 13:36:59 -07:00
bool should_unwind_until(ScopeType type, FlyString label) const
{
if (m_unwind_until_label.is_null())
return m_unwind_until == type;
return m_unwind_until == type && m_unwind_until_label == label;
}
LibJS: Implement basic execution of "switch" statements The "break" keyword now unwinds to the nearest ScopeType::Breakable. There's no support for break labels yet, but we'll get there too.
2020-03-29 14:34:25 +02:00
bool should_unwind() const { return 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 19:42:11 +01:00
LibJS: Make more Interpreter functions take a GlobalObject&
2020-06-08 21:25:16 +02:00
Value get_variable(const FlyString& name, GlobalObject&);
void set_variable(const FlyString& name, Value, GlobalObject&, bool first_assignment = false);
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: 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
Reference get_reference(const FlyString& name);
LibJS: Move global symbol map from SymbolObject to Interpreter This allows different instances of the Interpreter to have their own global symbols. Also makes Symbol non-copyable and non-moveable.
2020-07-06 16:57:22 -07:00
Symbol* get_global_symbol(const String& description);
Symbol* get_well_known_symbol(const String& description) const;
const HashMap<String, Symbol*>& get_well_known_symbol_map(Badge<SymbolConstructor>) const { return m_well_known_symbol_map; };
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 15:12:34 +01:00
void gather_roots(Badge<Heap>, HashTable<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: Make more Interpreter functions take a GlobalObject&
2020-06-08 21:25:16 +02:00
void enter_scope(const ScopeNode&, ArgumentVector, ScopeType, GlobalObject&);
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
void exit_scope(const ScopeNode&);
LibJS: Make Interpreter::call() this_value a required argument Right now the default is an empty value, which we accidentally exposed in set{Interval,Timeout}() by not providing a custom this value, which should't happen at all. Let's just make it a required argument instead.
2020-05-21 13:41:54 +01:00
Value call(Function&, Value this_value, Optional<MarkedValueList> arguments = {});
LibJS: Make Interpreter::construct() take a GlobalObject&
2020-06-20 17:53:33 +02:00
Value construct(Function&, Function& new_target, Optional<MarkedValueList> arguments, GlobalObject&);
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 15:20:49 +01: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 11:07:55 +01:00
CallFrame& push_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 21:58:22 +02:00
m_call_stack.append({ {}, js_undefined(), {}, nullptr });
LibJS: Use FlyString for identifiers This makes variable and property lookups a lot faster since comparing two FlyStrings is O(1).
2020-03-22 11:07:55 +01:00
return m_call_stack.last();
}
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 11:00:09 +01:00
void pop_call_frame() { m_call_stack.take_last(); }
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 22:48:35 +01:00
const CallFrame& call_frame() { return m_call_stack.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 21:58:22 +02:00
const Vector<CallFrame>& call_stack() { return m_call_stack; }
void push_environment(LexicalEnvironment*);
void pop_environment();
const LexicalEnvironment* current_environment() const { return m_call_stack.last().environment; }
LexicalEnvironment* current_environment() { return m_call_stack.last().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 22:48:35 +01:00
LibJS: Add strict mode Adds the ability for a scope (either a function or the entire program) to be in strict mode. Scopes default to non-strict mode. There are two ways to determine the strict-ness of the JS engine: 1. In the parser, this can be accessed with the parser_state variable m_is_strict_mode boolean. If true, the Parser is currently parsing in strict mode. This is done so that the Parser can generate syntax errors at parse time, which is required in some cases. 2. With Interpreter.is_strict_mode(). This allows strict mode checking at runtime as opposed to compile time. Additionally, in order to test this, a global isStrictMode() function has been added to the JS ReplObject under the test-mode flag.
2020-05-27 22:22:08 -07:00
bool in_strict_mode() const { return m_scope_stack.last().scope_node->in_strict_mode(); }
LibJS: Implement Proxy [[Call]] and [[Construct]] traps In order to do this, Proxy now extends Function rather than Object, and whether or not it returns true for is_function() depends on it's m_target.
2020-06-25 14:49:56 -07:00
template<typename Callback>
void for_each_argument(Callback callback)
{
if (m_call_stack.is_empty())
return;
for (auto& value : m_call_stack.last().arguments)
callback(value);
}
LibJS: Add argument(i) and argument_count() to Interpreter Add some convenience accessors for retrieving arguments from the current call frame.
2020-04-01 22:38:59 +02:00
size_t argument_count() const
{
if (m_call_stack.is_empty())
return 0;
return m_call_stack.last().arguments.size();
}
Value argument(size_t index) const
{
if (m_call_stack.is_empty())
return {};
auto& arguments = m_call_stack.last().arguments;
return index < arguments.size() ? arguments[index] : js_undefined();
}
LibJS: Interpreter::this_value() => this_value(GlobalObject&) Once the Interpreter has no global object attached to it, we have to provide it everywhere.
2020-06-08 21:10:22 +02:00
Value this_value(Object& global_object) const
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
{
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 11:00:09 +01:00
if (m_call_stack.is_empty())
LibJS: Interpreter::this_value() => this_value(GlobalObject&) Once the Interpreter has no global object attached to it, we have to provide it everywhere.
2020-06-08 21:10:22 +02:00
return &global_object;
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 11:00:09 +01:00
return m_call_stack.last().this_value;
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
}
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 14:06:52 +02:00
Exception* exception()
{
return m_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 14:37:39 +01:00
void clear_exception() { m_exception = nullptr; }
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 22:03:50 +01:00
template<typename T, typename... Args>
Value throw_exception(Args&&... args)
{
LibJS: Pass prototype to Error constructors
2020-04-17 19:31:48 +02:00
return throw_exception(T::create(global_object(), forward<Args>(args)...));
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 22:03:50 +01:00
}
Value throw_exception(Exception*);
Value throw_exception(Value value)
{
LibJS: Move native objects towards two-pass construction To make sure that everything is set up correctly in objects before we start adding properties to them, we split cell allocation into 3 steps: 1. Allocate a cell of appropriate size from the Heap 2. Call the C++ constructor on the cell 3. Call initialize() on the constructed object The job of initialize() is to define all the initial properties. Doing it in a second pass guarantees that the Object has a valid Shape and can find its own GlobalObject.
2020-06-20 15:40:48 +02:00
return throw_exception(heap().allocate<Exception>(global_object(), value));
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 22:03:50 +01:00
}
LibJS: Use the same StringPrototype globally To make sure that everyone has the same instance of StringPrototype, hang a global prototype off of the Interpreter that can be fetched when constructing new StringObjects.
2020-03-15 15:11:13 +01:00
LibJS: Consolidate error messages into ErrorTypes.h Now, exceptions can be thrown with interpreter.throw_exception<T>(ErrorType:TYPE, "format", "args", "here").
2020-06-09 22:48:01 -07:00
template<typename T, typename... Args>
Value throw_exception(ErrorType type, Args&&... args)
{
return throw_exception(T::create(global_object(), String::format(type.message(), forward<Args>(args)...)));
}
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 23:45:13 +02:00
Value last_value() const { return m_last_value; }
LibJS+js: Support getting last value from "_" variable The interpreter now has an "underscore is last value" flag, which makes Interpreter::get_variable() return the last value if: - The m_underscore_is_last_value flag is enabled - The name of the variable lookup is "_" - The result of that lookup is an empty value That means "_" can still be used as a regular variable and will stop doing its magic once anything is assigned to it. Example REPL session: > 1 1 > _ + _ 2 > _ + _ 4 > _ = "foo" "foo" > 1 1 > _ "foo" > delete _ true > 1 1 > _ 1 >
2020-06-08 12:08:35 +01:00
bool underscore_is_last_value() const { return m_underscore_is_last_value; }
void set_underscore_is_last_value(bool b) { m_underscore_is_last_value = b; }
LibJS: Start implementing a Console class for the interpreter The goal is to start factoring out core ConsoleObject functionality and to make ConsoleObject only a JS wrapper around Console.
2020-05-01 14:40:43 +02:00
Console& console() { return m_console; }
LibJS: Add some helpers and use them to re-implement Console functions Also add const overloads for some getters. Also const-qualify Interpreter::join_arguments().
2020-05-04 14:18:15 +02:00
const Console& console() const { return m_console; }
LibJS: Implement console.count()
2020-05-01 07:14:57 +02:00
LibJS: Add some helpers and use them to re-implement Console functions Also add const overloads for some getters. Also const-qualify Interpreter::join_arguments().
2020-05-04 14:18:15 +02:00
String join_arguments() const;
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
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
Value resolve_this_binding() const;
const LexicalEnvironment* get_this_environment() const;
Value get_new_target() const;
LibJS: Evaluate for statements in their own scope if necessary We now evaluate for loops in their own scope if their init statement is a lexical declaration. Evaluating for loops in their own scope allow us to obtain expected behaviour, which means for example, that the block-scoped variables declared in a for statement will be limited to the scope of the for loop's body and statement and not to that of the current scope (i.e the one where the for statement was made)
2020-03-14 13:56:49 +02:00
private:
LibJS: Add Interpreter::create<GlobalObjectType>() Force Interpreter construction to go via a create() helper that takes the global object type as a template parameter.
2020-04-01 21:04:51 +02:00
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 19:23:58 +01:00
Heap m_heap;
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 23:45:13 +02:00
Value m_last_value;
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
Vector<ScopeFrame> m_scope_stack;
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 11:00:09 +01:00
Vector<CallFrame> m_call_stack;
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
Object* m_global_object { nullptr };
LibJS: Add all the Error subclasses This patch adds instance, constructor and prototype classes for: - EvalError - InternalError - RangeError - ReferenceError - SyntaxError - TypeError - URIError Enumerator macros are used to reduce the amount of typing. :^)
2020-04-10 12:42:33 +02:00
LibJS: Move global symbol map from SymbolObject to Interpreter This allows different instances of the Interpreter to have their own global symbols. Also makes Symbol non-copyable and non-moveable.
2020-07-06 16:57:22 -07:00
HashMap<String, Symbol*> m_well_known_symbol_map;
HashMap<String, Symbol*> m_global_symbol_map;
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 22:03:50 +01:00
Exception* m_exception { nullptr };
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 19:19:03 +01:00
ScopeType m_unwind_until { ScopeType::None };
LibJS: Integrate labels into the Interpreter The interpreter now considers a statement or block's label when considering whether or not to break. All statements can be labelled.
2020-05-28 13:36:59 -07:00
FlyString m_unwind_until_label;
LibJS: Implement console.count()
2020-05-01 07:14:57 +02:00
LibJS+js: Support getting last value from "_" variable The interpreter now has an "underscore is last value" flag, which makes Interpreter::get_variable() return the last value if: - The m_underscore_is_last_value flag is enabled - The name of the variable lookup is "_" - The result of that lookup is an empty value That means "_" can still be used as a regular variable and will stop doing its magic once anything is assigned to it. Example REPL session: > 1 1 > _ + _ 2 > _ + _ 4 > _ = "foo" "foo" > 1 1 > _ "foo" > delete _ true > 1 1 > _ 1 >
2020-06-08 12:08:35 +01:00
bool m_underscore_is_last_value { false };
LibJS: Start implementing a Console class for the interpreter The goal is to start factoring out core ConsoleObject functionality and to make ConsoleObject only a JS wrapper around Console.
2020-05-01 14:40:43 +02:00
Console m_console;
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