LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-22 19:07:20 +03:00
Code Issues Packages Projects Releases Wiki Activity
f73afbb5ae
ladybird/Userland/Libraries/LibJS/Interpreter.h

96 lines
2.7 KiB
C
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 21:42:11 +03:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 11:24:48 +03: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 21:42:11 +03:00
*/
#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-25 00:03:50 +03: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 23:13:55 +03: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 21:53:31 +03: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 21:42:11 +03: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 19:53:09 +03: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-28 08:22:08 +03:00
#include <LibJS/AST.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 21:42:11 +03:00
#include <LibJS/Forward.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 20:24:44 +03:00
#include <LibJS/Heap/DeferGC.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 16:20:30 +03:00
#include <LibJS/Heap/Heap.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 13:24:46 +03:00
#include <LibJS/Runtime/DeclarativeEnvironment.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-10 08:48:01 +03: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-25 00:03:50 +03:00
#include <LibJS/Runtime/Exception.h>
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 21:36:25 +03:00
#include <LibJS/Runtime/GlobalObject.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 18:24:56 +03:00
#include <LibJS/Runtime/MarkedValueList.h>
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 21:36:25 +03:00
#include <LibJS/Runtime/Realm.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 20:24:44 +03:00
#include <LibJS/Runtime/VM.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 16:20:30 +03: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 21:42:11 +03:00
namespace JS {
LibJS: Don't track executing AST nodes in a Vector Instead just link together the InterpreterNodeScopes in a linked list. This was surprisingly hot on CanvasCycle.
2021-03-21 19:38:42 +03:00
struct ExecutingASTNodeChain {
ExecutingASTNodeChain* previous { nullptr };
const ASTNode& node;
};
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 19:53:09 +03: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 21:42:11 +03: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 22:04:51 +03:00
template<typename GlobalObjectType, typename... Args>
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 20:24:44 +03:00
static NonnullOwnPtr<Interpreter> create(VM& vm, 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 19:53:28 +03:00
{
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 20:24:44 +03:00
DeferGC defer_gc(vm.heap());
auto interpreter = adopt_own(*new Interpreter(vm));
LibJS: Rename InterpreterScope => InterpreterExecutionScope To make it a little clearer what this is for. (This is an RAII helper class for adding and removing an Interpreter to a VM's list of the currently active (executing code) Interpreters.)
2020-09-21 14:36:32 +03:00
VM::InterpreterExecutionScope scope(*interpreter);
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 21:36:25 +03:00
auto* global_object = static_cast<GlobalObject*>(interpreter->heap().allocate_without_global_object<GlobalObjectType>(forward<Args>(args)...));
auto* realm = Realm::create(vm);
realm->set_global_object(*global_object, global_object);
interpreter->m_global_object = make_handle(global_object);
interpreter->m_realm = make_handle(realm);
static_cast<GlobalObjectType*>(global_object)->initialize_global_object();
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 22:04:51 +03: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 19:53:28 +03: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 14:33:54 +03:00
static NonnullOwnPtr<Interpreter> create_with_existing_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 18:24:14 +03: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 22:04:51 +03:00
~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 11:09:56 +03:00
void run(GlobalObject&, const Program&);
LibJS: Extract most of Interpreter's run() into execute_statement() Interpreter::run() was so far being used both as the "public API entry point" for running a JS::Program as well as internally to execute JS::Statement|s of all kinds - this is now more distinctly separated. A program as returned by the parser is still going through run(), which is responsible for creating the initial global call frame, but all other statements are executed via execute_statement() directly. Fixes #3437, a regression introduced by adding ASSERT(!exception()) to run() without considering the effects that would have on internal usage.
2020-09-12 00:47:43 +03:00
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 12:05:38 +03: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 21:42:11 +03: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 21:36:25 +03:00
Realm& realm();
Realm const& realm() const;
LibJS: Always inline some tiny Interpreter getters
2021-03-21 19:39:43 +03:00
ALWAYS_INLINE VM& vm() { return *m_vm; }
ALWAYS_INLINE const VM& vm() const { return *m_vm; }
ALWAYS_INLINE Heap& heap() { return vm().heap(); }
ALWAYS_INLINE Exception* exception() { return vm().exception(); }
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 21:23:58 +03:00
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 13:24:46 +03:00
Environment* lexical_environment() { return vm().lexical_environment(); }
LibJS: Rename VM::current_scope() => current_environment_record() And rename some related functions that wrapped this as well.
2021-06-22 00:47:44 +03:00
LibJS: Don't track executing AST nodes in a Vector Instead just link together the InterpreterNodeScopes in a linked list. This was surprisingly hot on CanvasCycle.
2021-03-21 19:38:42 +03:00
void push_ast_node(ExecutingASTNodeChain& chain_node)
{
chain_node.previous = m_ast_node_chain;
m_ast_node_chain = &chain_node;
}
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:15:22 +03:00
LibJS: Don't track executing AST nodes in a Vector Instead just link together the InterpreterNodeScopes in a linked list. This was surprisingly hot on CanvasCycle.
2021-03-21 19:38:42 +03:00
void pop_ast_node()
{
VERIFY(m_ast_node_chain);
m_ast_node_chain = m_ast_node_chain->previous;
}
LibJS: Move AST node stack from VM to Interpreter
2021-03-21 14:18:56 +03:00
LibJS: Don't track executing AST nodes in a Vector Instead just link together the InterpreterNodeScopes in a linked list. This was surprisingly hot on CanvasCycle.
2021-03-21 19:38:42 +03:00
const ASTNode* current_node() const { return m_ast_node_chain ? &m_ast_node_chain->node : nullptr; }
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 17:56:58 +03:00
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 14:56:49 +03:00
private:
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 20:24:44 +03:00
explicit Interpreter(VM&);
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 22:04:51 +03:00
LibJS: Don't track executing AST nodes in a Vector Instead just link together the InterpreterNodeScopes in a linked list. This was surprisingly hot on CanvasCycle.
2021-03-21 19:38:42 +03:00
ExecutingASTNodeChain* m_ast_node_chain { nullptr };
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-04 03:02:43 +03:00
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 20:24:44 +03:00
NonnullRefPtr<VM> m_vm;
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 21:23:58 +03: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 21:36:25 +03:00
Handle<GlobalObject> m_global_object;
Handle<Realm> m_realm;
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 21:42:11 +03:00
};
}
Reference in New Issue Copy Permalink