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

2643 lines
88 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
/*
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
Everywhere: Use linusg@serenityos.org for my copyright headers
2021-04-22 22:51:19 +02:00
* Copyright (c) 2020-2021, Linus Groh <linusg@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*/
LibJS: Replace ASTNode::class_name() with RTTI This is only used for debugging anyway, so performance doesn't matter too much.
2021-01-17 09:21:15 +01:00
#include <AK/Demangle.h>
LibJS: Allow functions to take arguments (#1405)
2020-03-12 19:22:13 +08:00
#include <AK/HashMap.h>
LibJS: Do not revisit already visited values in update_function_name() Fixes #3471, adds a test.
2020-09-18 18:00:57 +04:30
#include <AK/HashTable.h>
LibJS: Clean up the anonymous wrapper block in "for" using ScopeGuard This ensures that we don't forget to pop the wrapper off of the scope stack when returning early due to an exception or some such. :^)
2020-04-05 00:24:32 +02:00
#include <AK/ScopeGuard.h>
LibJS: Allow functions to take arguments (#1405)
2020-03-12 19:22:13 +08:00
#include <AK/StringBuilder.h>
LibJS: Add basic support for "with" statements with statements evaluate an expression and put the result of it at the "front" of the scope chain. This is implemented by creating a WithScope object and placing it in front of the VM's current call frame's scope.
2020-11-28 16:14:26 +01:00
#include <AK/TemporaryChange.h>
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
#include <LibCrypto/BigInt/SignedBigInteger.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
#include <LibJS/AST.h>
#include <LibJS/Interpreter.h>
LibJS: Implement the NewObjectEnvironment() abstract operation
2021-06-22 01:14:27 +02:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
#include <LibJS/Runtime/Accessor.h>
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
#include <LibJS/Runtime/Array.h>
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
#include <LibJS/Runtime/BigInt.h>
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
#include <LibJS/Runtime/ECMAScriptFunctionObject.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 14:37:39 +01:00
#include <LibJS/Runtime/Error.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/FunctionEnvironment.h>
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Integrate iterator protocol into language features Finally use Symbol.iterator protocol in language features :) currently only used in for-of loops and spread expressions, but will have more uses later (Maps, Sets, Array.from, etc).
2020-07-13 08:27:20 -07:00
#include <LibJS/Runtime/IteratorOperations.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: Implement constructor/non-constructor function calls This adds Function::construct() for constructor function calls via `new` keyword. NativeFunction doesn't have constructor behaviour by default, ScriptFunction simply calls call() in construct()
2020-04-01 18:31:24 +01:00
#include <LibJS/Runtime/NativeFunction.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/ObjectEnvironment.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/PrimitiveString.h>
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
#include <LibJS/Runtime/Reference.h>
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
#include <LibJS/Runtime/RegExpObject.h>
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
#include <LibJS/Runtime/Shape.h>
LibJS: Include <typeinfo> in AST.cpp again Linus points out that oss-fuzz wants this to be there.
2021-02-10 12:21:14 +01:00
#include <typeinfo>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
namespace JS {
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
class InterpreterNodeScope {
AK_MAKE_NONCOPYABLE(InterpreterNodeScope);
AK_MAKE_NONMOVABLE(InterpreterNodeScope);
public:
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
InterpreterNodeScope(Interpreter& interpreter, ASTNode const& node)
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
: m_interpreter(interpreter)
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 17:38:42 +01:00
, m_chain_node { nullptr, node }
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
{
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
m_interpreter.vm().running_execution_context().current_node = &node;
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 17:38:42 +01:00
m_interpreter.push_ast_node(m_chain_node);
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
}
~InterpreterNodeScope()
{
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 17:38:42 +01:00
m_interpreter.pop_ast_node();
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
}
private:
Interpreter& m_interpreter;
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 17:38:42 +01:00
ExecutingASTNodeChain m_chain_node;
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
};
LibJS: Replace ASTNode::class_name() with RTTI This is only used for debugging anyway, so performance doesn't matter too much.
2021-01-17 09:21:15 +01:00
String ASTNode::class_name() const
{
// NOTE: We strip the "JS::" prefix.
return demangle(typeid(*this).name()).substring(4);
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
static void update_function_name(Value value, FlyString const& name)
LibJS: Do not revisit already visited values in update_function_name() Fixes #3471, adds a test.
2020-09-18 18:00:57 +04:30
{
LibJS: Only update anonymous function names when necessary Previously we would generate function names for anonymous functions on every AssignmentExpression, even if we weren't assigning a function. We were also setting names of anonymous functions in arrays, which is apparently a SpiderMonkey specific behavior not supported by V8, JSC or required by ECMA262. This patch removes that behavior. This is a huge performance improvement on the CanvasCycle demo! :^)
2021-03-21 17:14:20 +01:00
if (!value.is_function())
return;
auto& function = value.as_function();
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
if (is<ECMAScriptFunctionObject>(function) && function.name().is_empty())
static_cast<ECMAScriptFunctionObject&>(function).set_name(name);
LibJS: Do not revisit already visited values in update_function_name() Fixes #3471, adds a test.
2020-09-18 18:00:57 +04:30
}
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
static String get_function_name(GlobalObject& global_object, Value value)
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
{
if (value.is_symbol())
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
return String::formatted("[{}]", value.as_symbol().description());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
if (value.is_string())
return value.as_string().string();
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
return value.to_string(global_object);
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
}
LibJS: Make more Interpreter functions take a GlobalObject&
2020-06-08 21:25:16 +02:00
Value ScopeNode::execute(Interpreter& interpreter, 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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
return interpreter.execute_statement(global_object, *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 19:42:11 +01:00
}
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-03 17:02:43 -07:00
Value Program::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Get rid of Argument and ArgumentVector This was used for a feature where you could pass a vector of arguments to enter_scope(). Since that way of passing arguments was not GC-aware (as vectors use C++ heap storage), let's avoid using it and make sure everything that needs to stay alive is either on the stack or in traced storage instead.
2020-12-08 18:21:55 +01:00
return interpreter.execute_statement(global_object, *this, ScopeType::Block);
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-03 17:02:43 -07:00
}
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:45:22 +03:30
Value FunctionDeclaration::execute(Interpreter& interpreter, GlobalObject&) 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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
return {};
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 FunctionExpression more spec-compliant
2021-07-07 22:53:32 +02:00
// 15.2.5 Runtime Semantics: InstantiateOrdinaryFunctionExpression, https://tc39.es/ecma262/#sec-runtime-semantics-instantiateordinaryfunctionexpression
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value FunctionExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Make FunctionExpression more spec-compliant
2021-07-07 22:53:32 +02:00
auto* func_env = interpreter.lexical_environment();
bool has_identifier = !name().is_empty() && !is_auto_renamed();
if (has_identifier) {
func_env = interpreter.heap().allocate<DeclarativeEnvironment>(global_object, func_env);
func_env->create_immutable_binding(global_object, name(), false);
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
auto closure = ECMAScriptFunctionObject::create(global_object, name(), body(), parameters(), function_length(), func_env, kind(), is_strict_mode(), is_arrow_function());
LibJS: Make FunctionExpression more spec-compliant
2021-07-07 22:53:32 +02:00
if (has_identifier)
func_env->initialize_binding(global_object, name(), closure);
return closure;
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ExpressionStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
return m_expression->execute(interpreter, global_object);
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
}
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
CallExpression::ThisAndCallee CallExpression::compute_this_and_callee(Interpreter& interpreter, GlobalObject& global_object, Reference const& callee_reference) const
LibJS: Reorganize computing of |this| for CallExpressions This avoids executing the LHS of the object expression twice when doing a call on the result of an object expression.
2020-04-01 18:51:27 +02:00
{
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
auto& vm = interpreter.vm();
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
if (callee_reference.is_property_reference()) {
auto this_value = callee_reference.get_this_value();
auto callee = callee_reference.get_value(global_object);
if (vm.exception())
return {};
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
LibJS: Reorganize computing of |this| for CallExpressions This avoids executing the LHS of the object expression twice when doing a call on the result of an object expression.
2020-04-01 18:51:27 +02:00
return { this_value, callee };
}
LibJS: Fix functions binding this to global object in strict mode This fixes an issue where this would be bound to the global object by default when operating in strict mode. According to the specification, the expected value for |this| when no binding is provided is undefined.
2021-06-04 11:52:20 +01:00
LibJS: Follow the spec more closely when determining the this value Co-authored-by: davidot <david.tuin@gmail.com>
2021-07-12 01:37:51 +02:00
// [[Call]] will handle that in non-strict mode the this value becomes the global object
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
return {
js_undefined(),
callee_reference.is_unresolvable()
? m_callee->execute(interpreter, global_object)
: callee_reference.get_value(global_object)
};
LibJS: Reorganize computing of |this| for CallExpressions This avoids executing the LHS of the object expression twice when doing a call on the result of an object expression.
2020-04-01 18:51:27 +02:00
}
LibJS: Break out ArgumentListEvaluation AO from CallExpression
2021-07-02 14:24:50 +02:00
// 13.3.8.1 Runtime Semantics: ArgumentListEvaluation, https://tc39.es/ecma262/#sec-runtime-semantics-argumentlistevaluation
static void argument_list_evaluation(Interpreter& interpreter, GlobalObject& global_object, Vector<CallExpression::Argument> const& arguments, MarkedValueList& list)
{
auto& vm = global_object.vm();
list.ensure_capacity(arguments.size());
for (auto& argument : arguments) {
auto value = argument.value->execute(interpreter, global_object);
if (vm.exception())
return;
if (argument.is_spread) {
get_iterator_values(global_object, value, [&](Value iterator_value) {
if (vm.exception())
return IterationDecision::Break;
list.append(iterator_value);
return IterationDecision::Continue;
});
if (vm.exception())
return;
} else {
list.append(value);
}
}
}
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
Value NewExpression::execute(Interpreter& interpreter, 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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
auto& vm = interpreter.vm();
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
LibJS: NewExpression doesn't need compute_this_and_callee() Now that NewExpression is separated from CallExpression, it doesn't have to use the ad-hoc compute_this_and_callee() logic.
2021-07-02 18:43:25 +02:00
auto callee_value = m_callee->execute(interpreter, global_object);
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
if (vm.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
return {};
LibJS: Move has_constructor() from NativeFunction to FunctionObject At a later point this will indicate whether some FunctionObject "has a [[Construct]] internal method" (separate from the current FunctionObject call() / construct()), to help with a more spec-compliant implementation of [[Call]] and [[Construct]]. This means that it is no longer relevant to just NativeFunction.
2021-09-25 09:52:49 +02:00
if (!callee_value.is_function() || !callee_value.as_function().has_constructor()) {
LibJS: NewExpression doesn't need compute_this_and_callee() Now that NewExpression is separated from CallExpression, it doesn't have to use the ad-hoc compute_this_and_callee() logic.
2021-07-02 18:43:25 +02:00
throw_type_error_for_callee(interpreter, global_object, callee_value, "constructor"sv);
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
return {};
}
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 20:24:45 +02:00
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
MarkedValueList arg_list(vm.heap());
argument_list_evaluation(interpreter, global_object, m_arguments, arg_list);
if (interpreter.exception())
return {};
LibJS: NewExpression doesn't need compute_this_and_callee() Now that NewExpression is separated from CallExpression, it doesn't have to use the ad-hoc compute_this_and_callee() logic.
2021-07-02 18:43:25 +02:00
auto& function = callee_value.as_function();
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
return vm.construct(function, function, move(arg_list));
}
void CallExpression::throw_type_error_for_callee(Interpreter& interpreter, GlobalObject& global_object, Value callee_value, StringView call_type) const
{
auto& vm = interpreter.vm();
if (is<Identifier>(*m_callee) || is<MemberExpression>(*m_callee)) {
String expression_string;
if (is<Identifier>(*m_callee)) {
expression_string = static_cast<Identifier const&>(*m_callee).string();
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
} else {
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
expression_string = static_cast<MemberExpression const&>(*m_callee).to_string_approximation();
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
}
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
vm.throw_exception<TypeError>(global_object, ErrorType::IsNotAEvaluatedFrom, callee_value.to_string_without_side_effects(), call_type, expression_string);
} else {
vm.throw_exception<TypeError>(global_object, ErrorType::IsNotA, callee_value.to_string_without_side_effects(), call_type);
LibJS: Implement constructor/non-constructor function calls This adds Function::construct() for constructor function calls via `new` keyword. NativeFunction doesn't have constructor behaviour by default, ScriptFunction simply calls call() in construct()
2020-04-01 18:31:24 +01:00
}
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
}
LibJS: Implement constructor/non-constructor function calls This adds Function::construct() for constructor function calls via `new` keyword. NativeFunction doesn't have constructor behaviour by default, ScriptFunction simply calls call() in construct()
2020-04-01 18:31:24 +01:00
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
Value CallExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
InterpreterNodeScope node_scope { interpreter, *this };
auto& vm = interpreter.vm();
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
auto callee_reference = m_callee->to_reference(interpreter, global_object);
if (vm.exception())
return {};
auto [this_value, callee] = compute_this_and_callee(interpreter, global_object, callee_reference);
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
if (vm.exception())
return {};
VERIFY(!callee.is_empty());
LibJS: Break out ArgumentListEvaluation AO from CallExpression
2021-07-02 14:24:50 +02:00
MarkedValueList arg_list(vm.heap());
argument_list_evaluation(interpreter, global_object, m_arguments, arg_list);
if (interpreter.exception())
return {};
LibJS: Allow functions to take arguments (#1405)
2020-03-12 19:22:13 +08:00
LibJS: Evaluate function arguments before checking callee type In the spec, this happens in the EvaluateCall abstract operation (https://tc39.es/ecma262/#sec-evaluatecall), and the order is defined as: 3. Let argList be ? ArgumentListEvaluation of arguments. 4. If Type(func) is not Object, throw a TypeError exception. 5. If IsCallable(func) is false, throw a TypeError exception. In LibJS this is handled by CallExpression::execute(), which had the callee function check first and would therefore never evaluate the arguments for a non-function callee.
2021-09-13 17:44:08 +01:00
if (!callee.is_function()) {
throw_type_error_for_callee(interpreter, global_object, callee, "function"sv);
return {};
}
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
auto& function = callee.as_function();
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
if (&function == global_object.eval_function()
&& callee_reference.is_environment_reference()
&& callee_reference.name().is_string()
&& callee_reference.name().as_string() == vm.names.eval.as_string()) {
LibJS: Break out ArgumentListEvaluation AO from CallExpression
2021-07-02 14:24:50 +02:00
auto script_value = arg_list.size() == 0 ? js_undefined() : arg_list[0];
LibJS: Convert perform_eval to ThrowCompletionOr
2021-09-21 22:16:08 +03:00
return TRY_OR_DISCARD(perform_eval(script_value, global_object, vm.in_strict_mode() ? CallerMode::Strict : CallerMode::NonStrict, EvalMode::Direct));
LibJS: Correct behaviour of direct vs. indirect eval eval only has direct access to the local scope when accessed through the name eval. This includes locals named eval, because of course it does.
2021-06-19 20:13:53 -07:00
}
LibJS: Convert Value::invoke and VM::call to ThrowCompletionOr
2021-09-23 20:56:28 +03:00
return TRY_OR_DISCARD(vm.call(function, this_value, move(arg_list)));
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
}
// 13.3.7.1 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
// SuperCall : super Arguments
Value SuperCall::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
InterpreterNodeScope node_scope { interpreter, *this };
auto& vm = interpreter.vm();
// 1. Let newTarget be GetNewTarget().
auto new_target = vm.get_new_target();
if (vm.exception())
return {};
// 2. Assert: Type(newTarget) is Object.
VERIFY(new_target.is_function());
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
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// 3. Let func be ! GetSuperConstructor().
auto* func = get_super_constructor(interpreter.vm());
VERIFY(!vm.exception());
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// 4. Let argList be ? ArgumentListEvaluation of Arguments.
MarkedValueList arg_list(vm.heap());
argument_list_evaluation(interpreter, global_object, m_arguments, arg_list);
if (interpreter.exception())
return {};
// 5. If IsConstructor(func) is false, throw a TypeError exception.
// FIXME: This check is non-conforming.
if (!func || !func->is_function()) {
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
vm.throw_exception<TypeError>(global_object, ErrorType::NotAConstructor, "Super constructor");
return {};
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
}
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// 6. Let result be ? Construct(func, argList, newTarget).
auto& function = new_target.as_function();
auto result = vm.construct(static_cast<FunctionObject&>(*func), function, move(arg_list));
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
if (vm.exception())
return {};
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// 7. Let thisER be GetThisEnvironment().
auto& this_er = verify_cast<FunctionEnvironment>(get_this_environment(interpreter.vm()));
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: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// 8. Perform ? thisER.BindThisValue(result).
this_er.bind_this_value(global_object, result);
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
if (vm.exception())
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 20:24:45 +02:00
return {};
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// 9. Let F be thisER.[[FunctionObject]].
// 10. Assert: F is an ECMAScript function object. (NOTE: This is implied by the strong C++ type.)
[[maybe_unused]] auto& f = this_er.function_object();
// 11. Perform ? InitializeInstanceElements(result, F).
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
VERIFY(result.is_object());
vm.initialize_instance_elements(result.as_object(), f);
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// 12. Return result.
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
return result;
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: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
Value YieldExpression::execute(Interpreter&, GlobalObject&) const
{
// This should be transformed to a return.
VERIFY_NOT_REACHED();
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ReturnStatement::execute(Interpreter& interpreter, 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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto value = argument() ? argument()->execute(interpreter, global_object) : js_undefined();
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
interpreter.vm().unwind(ScopeType::Function);
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
return value;
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value IfStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto predicate_result = m_predicate->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
LibJS: Implement basic boolean coercion We can't expect the conditionals in "if" and "while" statements to always return a bool, so we need to know how to boolify a JS::Value.
2020-03-10 08:46:20 +01:00
if (predicate_result.to_boolean())
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
return interpreter.execute_statement(global_object, *m_consequent);
LibJS: Parse "if" statements This patch implements basic parsing of "if" statements. We don't yet support parsing "else", so I added a FIXME about that.
2020-03-21 18:40:17 +01:00
if (m_alternate)
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
return interpreter.execute_statement(global_object, *m_alternate);
LibJS: Parse "if" statements This patch implements basic parsing of "if" statements. We don't yet support parsing "else", so I added a FIXME about that.
2020-03-21 18:40:17 +01: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 20:24:45 +02:00
return js_undefined();
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
}
LibJS: Make the `with` statement evaluation follow the spec even more This was almost entirely up-to-spec already, just missing exception checks, and we now leave the lexical environment in the modified state if an exception occurs during statement evaluation.
2021-07-04 17:22:27 +02:00
// 14.11.2 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-with-statement-runtime-semantics-evaluation
// WithStatement : with ( Expression ) Statement
LibJS: Add basic support for "with" statements with statements evaluate an expression and put the result of it at the "front" of the scope chain. This is implemented by creating a WithScope object and placing it in front of the VM's current call frame's scope.
2020-11-28 16:14:26 +01:00
Value WithStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Make the `with` statement evaluation follow the spec even more This was almost entirely up-to-spec already, just missing exception checks, and we now leave the lexical environment in the modified state if an exception occurs during statement evaluation.
2021-07-04 17:22:27 +02:00
// 1. Let value be the result of evaluating Expression.
auto value = m_object->execute(interpreter, global_object);
LibJS: Add basic support for "with" statements with statements evaluate an expression and put the result of it at the "front" of the scope chain. This is implemented by creating a WithScope object and placing it in front of the VM's current call frame's scope.
2020-11-28 16:14:26 +01:00
if (interpreter.exception())
return {};
LibJS: Make the `with` statement evaluation follow the spec even more This was almost entirely up-to-spec already, just missing exception checks, and we now leave the lexical environment in the modified state if an exception occurs during statement evaluation.
2021-07-04 17:22:27 +02:00
// 2. Let obj be ? ToObject(? GetValue(value)).
auto* object = value.to_object(global_object);
LibJS: Add basic support for "with" statements with statements evaluate an expression and put the result of it at the "front" of the scope chain. This is implemented by creating a WithScope object and placing it in front of the VM's current call frame's scope.
2020-11-28 16:14:26 +01:00
if (interpreter.exception())
return {};
LibJS: Make the `with` statement evaluation follow the spec even more This was almost entirely up-to-spec already, just missing exception checks, and we now leave the lexical environment in the modified state if an exception occurs during statement evaluation.
2021-07-04 17:22:27 +02:00
// 3. Let oldEnv be the running execution context's LexicalEnvironment.
auto* old_environment = interpreter.vm().running_execution_context().lexical_environment;
LibJS: Add basic support for "with" statements with statements evaluate an expression and put the result of it at the "front" of the scope chain. This is implemented by creating a WithScope object and placing it in front of the VM's current call frame's scope.
2020-11-28 16:14:26 +01:00
LibJS: Make the `with` statement evaluation follow the spec even more This was almost entirely up-to-spec already, just missing exception checks, and we now leave the lexical environment in the modified state if an exception occurs during statement evaluation.
2021-07-04 17:22:27 +02:00
// 4. Let newEnv be NewObjectEnvironment(obj, true, oldEnv).
auto* new_environment = new_object_environment(*object, true, old_environment);
if (interpreter.exception())
return {};
// 5. Set the running execution context's LexicalEnvironment to newEnv.
interpreter.vm().running_execution_context().lexical_environment = new_environment;
// 6. Let C be the result of evaluating Statement.
auto result = interpreter.execute_statement(global_object, m_body).value_or(js_undefined());
// 7. Set the running execution context's LexicalEnvironment to oldEnv.
interpreter.vm().running_execution_context().lexical_environment = old_environment;
LibJS: Restore the environment if an exception is thrown in 'with' block
2021-09-08 20:46:11 +02:00
if (interpreter.exception())
return {};
LibJS: Make the `with` statement evaluation follow the spec even more This was almost entirely up-to-spec already, just missing exception checks, and we now leave the lexical environment in the modified state if an exception occurs during statement evaluation.
2021-07-04 17:22:27 +02:00
// 8. Return Completion(UpdateEmpty(C, undefined)).
return result;
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value WhileStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
auto last_value = js_undefined();
LibJS: Check for exception after executing (do)while test expression Otherwise we crash the interpreter when an exception is thrown during evaluation of the while or do/while test expression - which is easily caused by a ReferenceError - e.g.: while (someUndefinedVariable) { // ... }
2020-10-23 00:40:14 +01:00
for (;;) {
auto test_result = m_test->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Check for exception after executing (do)while test expression Otherwise we crash the interpreter when an exception is thrown during evaluation of the while or do/while test expression - which is easily caused by a ReferenceError - e.g.: while (someUndefinedVariable) { // ... }
2020-10-23 00:40:14 +01:00
if (!test_result.to_boolean())
break;
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
last_value = interpreter.execute_statement(global_object, *m_body).value_or(last_value);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Handle unwinding in while and do-while statements For some reason, this was never added. So something like "while (true) { return }" would loop infinitely.
2020-10-08 13:12:31 -07:00
if (interpreter.vm().should_unwind()) {
if (interpreter.vm().should_unwind_until(ScopeType::Continuable, m_label)) {
interpreter.vm().stop_unwind();
} else if (interpreter.vm().should_unwind_until(ScopeType::Breakable, m_label)) {
interpreter.vm().stop_unwind();
break;
} else {
LibJS: Fix return statements not working properly in loops Previously, when a loop detected an unwind of type ScopeType::Function (which means a return statement was executed inside of the loop), it would just return undefined. This set the VM's last_value to undefined, when it should have been the returned value. This patch makes all loop statements return the appropriate value in the above case.
2020-10-08 13:17:40 -07:00
return last_value;
LibJS: Handle unwinding in while and do-while statements For some reason, this was never added. So something like "while (true) { return }" would loop infinitely.
2020-10-08 13:12:31 -07:00
}
}
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
}
return last_value;
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value DoWhileStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
auto last_value = js_undefined();
LibJS: Check for exception after executing (do)while test expression Otherwise we crash the interpreter when an exception is thrown during evaluation of the while or do/while test expression - which is easily caused by a ReferenceError - e.g.: while (someUndefinedVariable) { // ... }
2020-10-23 00:40:14 +01:00
for (;;) {
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
if (interpreter.exception())
return {};
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
last_value = interpreter.execute_statement(global_object, *m_body).value_or(last_value);
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
if (interpreter.exception())
return {};
LibJS: Handle unwinding in while and do-while statements For some reason, this was never added. So something like "while (true) { return }" would loop infinitely.
2020-10-08 13:12:31 -07:00
if (interpreter.vm().should_unwind()) {
if (interpreter.vm().should_unwind_until(ScopeType::Continuable, m_label)) {
interpreter.vm().stop_unwind();
} else if (interpreter.vm().should_unwind_until(ScopeType::Breakable, m_label)) {
interpreter.vm().stop_unwind();
break;
} else {
LibJS: Fix return statements not working properly in loops Previously, when a loop detected an unwind of type ScopeType::Function (which means a return statement was executed inside of the loop), it would just return undefined. This set the VM's last_value to undefined, when it should have been the returned value. This patch makes all loop statements return the appropriate value in the above case.
2020-10-08 13:17:40 -07:00
return last_value;
LibJS: Handle unwinding in while and do-while statements For some reason, this was never added. So something like "while (true) { return }" would loop infinitely.
2020-10-08 13:12:31 -07:00
}
}
LibJS: Check for exception after executing (do)while test expression Otherwise we crash the interpreter when an exception is thrown during evaluation of the while or do/while test expression - which is easily caused by a ReferenceError - e.g.: while (someUndefinedVariable) { // ... }
2020-10-23 00:40:14 +01:00
auto test_result = m_test->execute(interpreter, global_object);
if (interpreter.exception())
return {};
if (!test_result.to_boolean())
break;
}
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
return last_value;
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ForStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
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
RefPtr<BlockStatement> wrapper;
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
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
if (m_init && is<VariableDeclaration>(*m_init) && static_cast<VariableDeclaration const&>(*m_init).declaration_kind() != DeclarationKind::Var) {
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:45:22 +03:30
wrapper = create_ast_node<BlockStatement>(source_range());
LibJS: Limit scope of 'for' loop variables This required 2 changes: 1. In the parser, create a new variable scope, so the variable is declared in it instead of the scope in which the 'for' is found. 2. On execute, push the variable into the newly created block. Existing code created an empty block (no variables, no arguments) which allows Interpreter::enter_scope() to skip the creation of a new environment, therefore when the variable initializer is executed, it sets the variable to the outer scope. By attaching the variable to the new block, the block gets a new environment. This is only needed for 'let' / 'const' declarations, since 'var' declarations are expected to leak. Fixes: #2103
2020-05-05 01:58:53 +03:00
NonnullRefPtrVector<VariableDeclaration> decls;
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
decls.append(*static_cast<VariableDeclaration const*>(m_init.ptr()));
LibJS: Limit scope of 'for' loop variables This required 2 changes: 1. In the parser, create a new variable scope, so the variable is declared in it instead of the scope in which the 'for' is found. 2. On execute, push the variable into the newly created block. Existing code created an empty block (no variables, no arguments) which allows Interpreter::enter_scope() to skip the creation of a new environment, therefore when the variable initializer is executed, it sets the variable to the outer scope. By attaching the variable to the new block, the block gets a new environment. This is only needed for 'let' / 'const' declarations, since 'var' declarations are expected to leak. Fixes: #2103
2020-05-05 01:58:53 +03:00
wrapper->add_variables(decls);
LibJS: Get rid of Argument and ArgumentVector This was used for a feature where you could pass a vector of arguments to enter_scope(). Since that way of passing arguments was not GC-aware (as vectors use C++ heap storage), let's avoid using it and make sure everything that needs to stay alive is either on the stack or in traced storage instead.
2020-12-08 18:21:55 +01:00
interpreter.enter_scope(*wrapper, ScopeType::Block, global_object);
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
}
LibJS: Clean up the anonymous wrapper block in "for" using ScopeGuard This ensures that we don't forget to pop the wrapper off of the scope stack when returning early due to an exception or some such. :^)
2020-04-05 00:24:32 +02:00
auto wrapper_cleanup = ScopeGuard([&] {
if (wrapper)
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
interpreter.exit_scope(*wrapper);
LibJS: Clean up the anonymous wrapper block in "for" using ScopeGuard This ensures that we don't forget to pop the wrapper off of the scope stack when returning early due to an exception or some such. :^)
2020-04-05 00:24:32 +02:00
});
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
auto last_value = js_undefined();
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (m_init) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
m_init->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
}
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
if (m_test) {
LibJS: Handle exception in for loop test execution
2020-04-28 20:16:40 +01:00
while (true) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto test_result = m_test->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Handle exception in for loop test execution
2020-04-28 20:16:40 +01:00
if (!test_result.to_boolean())
break;
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
last_value = interpreter.execute_statement(global_object, *m_body).value_or(last_value);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
if (interpreter.vm().should_unwind()) {
if (interpreter.vm().should_unwind_until(ScopeType::Continuable, m_label)) {
interpreter.vm().stop_unwind();
} else if (interpreter.vm().should_unwind_until(ScopeType::Breakable, m_label)) {
interpreter.vm().stop_unwind();
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
break;
} else {
LibJS: Fix return statements not working properly in loops Previously, when a loop detected an unwind of type ScopeType::Function (which means a return statement was executed inside of the loop), it would just return undefined. This set the VM's last_value to undefined, when it should have been the returned value. This patch makes all loop statements return the appropriate value in the above case.
2020-10-08 13:17:40 -07:00
return last_value;
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
}
}
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (m_update) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
m_update->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
}
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
}
} else {
while (true) {
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
last_value = interpreter.execute_statement(global_object, *m_body).value_or(last_value);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
if (interpreter.vm().should_unwind()) {
if (interpreter.vm().should_unwind_until(ScopeType::Continuable, m_label)) {
interpreter.vm().stop_unwind();
} else if (interpreter.vm().should_unwind_until(ScopeType::Breakable, m_label)) {
interpreter.vm().stop_unwind();
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
break;
} else {
LibJS: Fix return statements not working properly in loops Previously, when a loop detected an unwind of type ScopeType::Function (which means a return statement was executed inside of the loop), it would just return undefined. This set the VM's last_value to undefined, when it should have been the returned value. This patch makes all loop statements return the appropriate value in the above case.
2020-10-08 13:17:40 -07:00
return last_value;
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
}
}
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (m_update) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
m_update->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
}
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
}
}
return last_value;
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
static Variant<NonnullRefPtr<Identifier>, NonnullRefPtr<BindingPattern>> variable_from_for_declaration(Interpreter& interpreter, GlobalObject& global_object, ASTNode const& node, RefPtr<BlockStatement> wrapper)
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
{
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (is<VariableDeclaration>(node)) {
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
auto& variable_declaration = static_cast<VariableDeclaration const&>(node);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!variable_declaration.declarations().is_empty());
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (variable_declaration.declaration_kind() != DeclarationKind::Var) {
wrapper = create_ast_node<BlockStatement>(node.source_range());
LibJS: Get rid of Argument and ArgumentVector This was used for a feature where you could pass a vector of arguments to enter_scope(). Since that way of passing arguments was not GC-aware (as vectors use C++ heap storage), let's avoid using it and make sure everything that needs to stay alive is either on the stack or in traced storage instead.
2020-12-08 18:21:55 +01:00
interpreter.enter_scope(*wrapper, ScopeType::Block, global_object);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
variable_declaration.execute(interpreter, global_object);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
return variable_declaration.declarations().first().target();
}
if (is<Identifier>(node)) {
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
return NonnullRefPtr(static_cast<Identifier const&>(node));
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
VERIFY_NOT_REACHED();
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ForInStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Set declared for-in and for-of variables as first time. These declarations might be const, and now when we're handling it properly, we have to set values to them correctly.
2021-02-26 00:37:27 +02:00
bool has_declaration = is<VariableDeclaration>(*m_lhs);
if (!has_declaration && !is<Identifier>(*m_lhs)) {
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
// FIXME: Implement "for (foo.bar in baz)", "for (foo[0] in bar)"
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
RefPtr<BlockStatement> wrapper;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
auto target = variable_from_for_declaration(interpreter, global_object, m_lhs, wrapper);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
auto wrapper_cleanup = ScopeGuard([&] {
if (wrapper)
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
interpreter.exit_scope(*wrapper);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
});
auto last_value = js_undefined();
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto rhs_result = m_rhs->execute(interpreter, global_object);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
if (interpreter.exception())
return {};
LibJS: Implicitly break for..in loop if the RHS result is nullish This implements the missing step 6a of 14.7.5.6 ForIn/OfHeadEvaluation: a. If exprValue is undefined or null, then i. Return Completion { [[Type]]: break, [[Value]]: empty, [[Target]]: empty }. In other words, this should just do nothing instead of throwing during the undefined to object coercion: for (const x in undefined);
2021-04-10 18:47:18 +02:00
if (rhs_result.is_nullish())
return {};
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
auto* object = rhs_result.to_object(global_object);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
while (object) {
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
auto property_names = object->enumerable_own_property_names(Object::PropertyKind::Key);
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
for (auto& value : property_names) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
interpreter.vm().assign(target, value, global_object, has_declaration);
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (interpreter.exception())
return {};
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
last_value = interpreter.execute_statement(global_object, *m_body).value_or(last_value);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
if (interpreter.exception())
return {};
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
if (interpreter.vm().should_unwind()) {
if (interpreter.vm().should_unwind_until(ScopeType::Continuable, m_label)) {
interpreter.vm().stop_unwind();
} else if (interpreter.vm().should_unwind_until(ScopeType::Breakable, m_label)) {
interpreter.vm().stop_unwind();
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
break;
} else {
LibJS: Fix return statements not working properly in loops Previously, when a loop detected an unwind of type ScopeType::Function (which means a return statement was executed inside of the loop), it would just return undefined. This set the VM's last_value to undefined, when it should have been the returned value. This patch makes all loop statements return the appropriate value in the above case.
2020-10-08 13:17:40 -07:00
return last_value;
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
}
}
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
object = object->internal_get_prototype_of();
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter.exception())
return {};
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
return last_value;
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ForOfStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Set declared for-in and for-of variables as first time. These declarations might be const, and now when we're handling it properly, we have to set values to them correctly.
2021-02-26 00:37:27 +02:00
bool has_declaration = is<VariableDeclaration>(*m_lhs);
if (!has_declaration && !is<Identifier>(*m_lhs)) {
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
// FIXME: Implement "for (foo.bar of baz)", "for (foo[0] of bar)"
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
RefPtr<BlockStatement> wrapper;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
auto target = variable_from_for_declaration(interpreter, global_object, m_lhs, wrapper);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
auto wrapper_cleanup = ScopeGuard([&] {
if (wrapper)
LibJS: Move scope stack from VM back to Interpreter Okay, my vision here is improving. Interpreter should be a thing that executes an AST. The scope stack is irrelevant to the VM proper, so we can move that to the Interpreter. Same with execute_statement().
2020-09-27 16:56:58 +02:00
interpreter.exit_scope(*wrapper);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
});
auto last_value = js_undefined();
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto rhs_result = m_rhs->execute(interpreter, global_object);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
if (interpreter.exception())
return {};
LibJS: get_iterator_values() should pass Value to callback (not Value&) Value& implies that the callback is expected/able to modify the value, which is not the case.
2020-09-08 14:15:13 +02:00
get_iterator_values(global_object, rhs_result, [&](Value value) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
interpreter.vm().assign(target, value, global_object, has_declaration);
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
last_value = interpreter.execute_statement(global_object, *m_body).value_or(last_value);
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
if (interpreter.exception())
LibJS: Integrate iterator protocol into language features Finally use Symbol.iterator protocol in language features :) currently only used in for-of loops and spread expressions, but will have more uses later (Maps, Sets, Array.from, etc).
2020-07-13 08:27:20 -07:00
return IterationDecision::Break;
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
if (interpreter.vm().should_unwind()) {
if (interpreter.vm().should_unwind_until(ScopeType::Continuable, m_label)) {
interpreter.vm().stop_unwind();
} else if (interpreter.vm().should_unwind_until(ScopeType::Breakable, m_label)) {
interpreter.vm().stop_unwind();
LibJS: Integrate iterator protocol into language features Finally use Symbol.iterator protocol in language features :) currently only used in for-of loops and spread expressions, but will have more uses later (Maps, Sets, Array.from, etc).
2020-07-13 08:27:20 -07:00
return IterationDecision::Break;
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
} else {
LibJS: Integrate iterator protocol into language features Finally use Symbol.iterator protocol in language features :) currently only used in for-of loops and spread expressions, but will have more uses later (Maps, Sets, Array.from, etc).
2020-07-13 08:27:20 -07:00
return IterationDecision::Break;
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
}
LibJS: Integrate iterator protocol into language features Finally use Symbol.iterator protocol in language features :) currently only used in for-of loops and spread expressions, but will have more uses later (Maps, Sets, Array.from, etc).
2020-07-13 08:27:20 -07:00
return IterationDecision::Continue;
});
if (interpreter.exception())
return {};
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
return last_value;
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value BinaryExpression::execute(Interpreter& interpreter, 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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto lhs_result = m_lhs->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto rhs_result = m_rhs->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
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
switch (m_op) {
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Addition:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return add(global_object, lhs_result, rhs_result);
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Subtraction:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return sub(global_object, lhs_result, rhs_result);
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Multiplication:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return mul(global_object, lhs_result, rhs_result);
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Division:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return div(global_object, lhs_result, rhs_result);
LibJS: Add basic support for modulo (%) in binary expressions
2020-04-04 21:17:34 +02:00
case BinaryOp::Modulo:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return mod(global_object, lhs_result, rhs_result);
LibJS: Implement exponentiation (** operator)
2020-04-05 13:40:00 +01:00
case BinaryOp::Exponentiation:
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
return exp(global_object, lhs_result, rhs_result);
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyEquals:
LibJS: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
return Value(is_strictly_equal(lhs_result, rhs_result));
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyInequals:
LibJS: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
return Value(!is_strictly_equal(lhs_result, rhs_result));
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyEquals:
LibJS: Rename abstract_eq() to is_loosely_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/c7d6d1c
2021-09-23 23:46:36 +02:00
return Value(is_loosely_equal(global_object, lhs_result, rhs_result));
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyInequals:
LibJS: Rename abstract_eq() to is_loosely_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/c7d6d1c
2021-09-23 23:46:36 +02:00
return Value(!is_loosely_equal(global_object, lhs_result, rhs_result));
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::GreaterThan:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return greater_than(global_object, lhs_result, rhs_result);
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
case BinaryOp::GreaterThanEquals:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return greater_than_equals(global_object, lhs_result, rhs_result);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::LessThan:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return less_than(global_object, lhs_result, rhs_result);
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
case BinaryOp::LessThanEquals:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return less_than_equals(global_object, lhs_result, rhs_result);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::BitwiseAnd:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return bitwise_and(global_object, lhs_result, rhs_result);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::BitwiseOr:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return bitwise_or(global_object, lhs_result, rhs_result);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::BitwiseXor:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return bitwise_xor(global_object, lhs_result, rhs_result);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::LeftShift:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return left_shift(global_object, lhs_result, rhs_result);
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::RightShift:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return right_shift(global_object, lhs_result, rhs_result);
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
case BinaryOp::UnsignedRightShift:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return unsigned_right_shift(global_object, lhs_result, rhs_result);
LibJS: Implement 'in' operator
2020-04-23 16:06:01 +01:00
case BinaryOp::In:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return in(global_object, lhs_result, rhs_result);
LibJS: Implement the "instanceof" operator This operator walks the prototype chain of the RHS value and looks for a "prototype" property with the same value as the prototype of the LHS. This is pretty cool. :^)
2020-03-28 16:56:54 +01:00
case BinaryOp::InstanceOf:
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
return instance_of(global_object, lhs_result, rhs_result);
LibJS: Add typed comparison operator The `===` operator allows us to compare two values while taking their type into consideration.
2020-03-08 07:53:02 +02:00
}
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Add typed comparison operator The `===` operator allows us to compare two values while taking their type into consideration.
2020-03-08 07:53:02 +02:00
}
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value LogicalExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto lhs_result = m_lhs->execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Add short circuit logical evaluation When evaluating logical binop expressions, the rhs must not be evaluated if the lhs leads to the whole expression not being truthy.
2020-04-03 19:11:31 +02:00
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
switch (m_op) {
case LogicalOp::And:
LibJS: Add short circuit logical evaluation When evaluating logical binop expressions, the rhs must not be evaluated if the lhs leads to the whole expression not being truthy.
2020-04-03 19:11:31 +02:00
if (lhs_result.to_boolean()) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto rhs_result = m_rhs->execute(interpreter, global_object);
LibJS: Add short circuit logical evaluation When evaluating logical binop expressions, the rhs must not be evaluated if the lhs leads to the whole expression not being truthy.
2020-04-03 19:11:31 +02:00
if (interpreter.exception())
return {};
LibJS: Implement nullish coalescing operator (??)
2020-04-18 00:49:11 +01:00
return rhs_result;
LibJS: Add short circuit logical evaluation When evaluating logical binop expressions, the rhs must not be evaluated if the lhs leads to the whole expression not being truthy.
2020-04-03 19:11:31 +02:00
}
LibJS: Implement nullish coalescing operator (??)
2020-04-18 00:49:11 +01:00
return lhs_result;
case LogicalOp::Or: {
LibJS: Fix logical expressions The current implementation of logical AND (&&) and logical OR (||) always returns a boolean - this is not correct.
2020-04-03 14:33:28 +01:00
if (lhs_result.to_boolean())
LibJS: Implement nullish coalescing operator (??)
2020-04-18 00:49:11 +01:00
return lhs_result;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto rhs_result = m_rhs->execute(interpreter, global_object);
LibJS: Add short circuit logical evaluation When evaluating logical binop expressions, the rhs must not be evaluated if the lhs leads to the whole expression not being truthy.
2020-04-03 19:11:31 +02:00
if (interpreter.exception())
return {};
LibJS: Implement nullish coalescing operator (??)
2020-04-18 00:49:11 +01:00
return rhs_result;
}
case LogicalOp::NullishCoalescing:
LibJS: Add Value::is_nullish()
2020-10-02 16:00:15 +02:00
if (lhs_result.is_nullish()) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto rhs_result = m_rhs->execute(interpreter, global_object);
LibJS: Implement nullish coalescing operator (??)
2020-04-18 00:49:11 +01:00
if (interpreter.exception())
return {};
return rhs_result;
}
return lhs_result;
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
}
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Reference Expression::to_reference(Interpreter&, GlobalObject&) const
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
{
return {};
}
LibJS: Improve ResolveBinding + add GetIdentifierReference ResolveBinding now matches the spec, while the non-conforming parts are moved to GetIdentifierReference. Implementing this properly requires variable bindings.
2021-07-02 21:54:56 +02:00
Reference Identifier::to_reference(Interpreter& interpreter, GlobalObject&) const
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 12:37:27 +02:00
{
LibJS: Improve ResolveBinding + add GetIdentifierReference ResolveBinding now matches the spec, while the non-conforming parts are moved to GetIdentifierReference. Implementing this properly requires variable bindings.
2021-07-02 21:54:56 +02:00
return interpreter.vm().resolve_binding(string());
LibJS: Allow "delete someGlobalVariable" This is solved by allowing Identifier nodes to produce a Reference with the global object as base.
2020-04-27 12:37:27 +02:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Reference MemberExpression::to_reference(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
{
LibJS: Bring the `super` keyword in line with the spec This patch implements spec-compliant runtime semantics for the following constructs: - super.property - super[property] The MakeSuperPropertyReference AO is added to support this. :^)
2021-07-03 00:20:52 +02:00
// 13.3.7.1 Runtime Semantics: Evaluation
// SuperProperty : super [ Expression ]
// SuperProperty : super . IdentifierName
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(object())) {
// 1. Let env be GetThisEnvironment().
auto& environment = get_this_environment(interpreter.vm());
// 2. Let actualThis be ? env.GetThisBinding().
auto actual_this = environment.get_this_binding(global_object);
StringOrSymbol property_key;
if (is_computed()) {
// SuperProperty : super [ Expression ]
// 3. Let propertyNameReference be the result of evaluating Expression.
// 4. Let propertyNameValue be ? GetValue(propertyNameReference).
auto property_name_value = m_property->execute(interpreter, global_object);
if (interpreter.exception())
return {};
// 5. Let propertyKey be ? ToPropertyKey(propertyNameValue).
property_key = property_name_value.to_property_key(global_object);
} else {
// SuperProperty : super . IdentifierName
// 3. Let propertyKey be StringValue of IdentifierName.
VERIFY(is<Identifier>(property()));
property_key = static_cast<Identifier const&>(property()).string();
}
// 6. If the code matched by this SuperProperty is strict mode code, let strict be true; else let strict be false.
bool strict = interpreter.vm().in_strict_mode();
// 7. Return ? MakeSuperPropertyReference(actualThis, propertyKey, strict).
LibJS: Convert make_super_property_reference to ThrowCompletionOr
2021-09-21 21:52:09 +03:00
return TRY_OR_DISCARD(make_super_property_reference(global_object, actual_this, property_key, strict));
LibJS: Bring the `super` keyword in line with the spec This patch implements spec-compliant runtime semantics for the following constructs: - super.property - super[property] The MakeSuperPropertyReference AO is added to support this. :^)
2021-07-03 00:20:52 +02:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto object_value = m_object->execute(interpreter, global_object);
LibJS: Throw in strict mode when assigning property to primitive value
2020-05-28 17:48:25 +01:00
if (interpreter.exception())
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
return {};
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// From here on equivalent to
// 13.3.4 EvaluatePropertyAccessWithIdentifierKey ( baseValue, identifierName, strict ), https://tc39.es/ecma262/#sec-evaluate-property-access-with-identifier-key
LibJS: Use ThrowCompletionOr in require_object_coercible()
2021-09-15 20:52:21 +01:00
object_value = TRY_OR_DISCARD(require_object_coercible(global_object, object_value));
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto property_name = computed_property_name(interpreter, global_object);
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
if (!property_name.is_valid())
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
return Reference {};
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
auto strict = interpreter.vm().in_strict_mode();
LibJS: Use move semantics more when creating Reference objects Turns a bunch of FlyString copies into moves.
2021-09-11 19:03:38 +02:00
return Reference { object_value, move(property_name), {}, strict };
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value UnaryExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
auto& vm = interpreter.vm();
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (m_op == UnaryOp::Delete) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto reference = m_lhs->to_reference(interpreter, global_object);
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (interpreter.exception())
return {};
LibJS: Support deleting local variables with operator delete To make this cleaner i also moved the logic into Reference::delete_.
2021-06-08 04:00:53 +03:00
return Value(reference.delete_(global_object));
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
}
LibJS: Make typeof return undefined for undefined variables This makes `typeof i_dont_exist` return `undefined` instead of throwing an error.
2020-06-02 23:26:39 +02:00
Value lhs_result;
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (m_op == UnaryOp::Typeof && is<Identifier>(*m_lhs)) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto reference = m_lhs->to_reference(interpreter, global_object);
LibJS: Make typeof return undefined for undefined variables This makes `typeof i_dont_exist` return `undefined` instead of throwing an error.
2020-06-02 23:26:39 +02:00
if (interpreter.exception()) {
return {};
}
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
if (reference.is_unresolvable()) {
lhs_result = js_undefined();
} else {
LibJS: Rename Reference methods to match the spec - get -> get_value (GetValue in the spec) - put -> put_value (PutValue in the spec) Also add spec links. :^)
2021-06-25 17:19:01 +02:00
lhs_result = reference.get_value(global_object, false);
LibJS: Make typeof return undefined for undefined variables This makes `typeof i_dont_exist` return `undefined` instead of throwing an error.
2020-06-02 23:26:39 +02:00
}
} else {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
lhs_result = m_lhs->execute(interpreter, global_object);
LibJS: Make typeof return undefined for undefined variables This makes `typeof i_dont_exist` return `undefined` instead of throwing an error.
2020-06-02 23:26:39 +02:00
if (interpreter.exception())
return {};
}
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
switch (m_op) {
LibJS: Rename BitNot -> BitwiseNot to match other bitwise operators
2020-03-14 20:43:35 +02:00
case UnaryOp::BitwiseNot:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return bitwise_not(global_object, lhs_result);
LibJS: Move logical not operator to new unary expression class
2020-03-09 19:04:44 +02:00
case UnaryOp::Not:
LibJS: Use Value::to_boolean() wherever we haven't checked is_boolean() Unless we've verified that a Value is a boolean, we should not be calling as_bool() on it.
2020-03-10 11:08:37 +01:00
return Value(!lhs_result.to_boolean());
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
case UnaryOp::Plus:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return unary_plus(global_object, lhs_result);
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
case UnaryOp::Minus:
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
return unary_minus(global_object, lhs_result);
LibJS: Implement typeof operator
2020-03-18 06:33:32 +11:00
case UnaryOp::Typeof:
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
return js_string(vm, lhs_result.typeof());
LibJS: Implement void operator
2020-04-15 17:55:03 +01:00
case UnaryOp::Void:
return js_undefined();
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
case UnaryOp::Delete:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
}
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
}
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
Value SuperExpression::execute(Interpreter&, GlobalObject&) const
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
{
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
// The semantics for SuperExpression are handled in CallExpression and SuperCall.
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
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 ClassMethod::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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
return m_function->execute(interpreter, global_object);
}
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
Value ClassField::execute(Interpreter& interpreter, GlobalObject&) const
{
InterpreterNodeScope node_scope { interpreter, *this };
return {};
}
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 ClassExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
auto& vm = interpreter.vm();
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 class_constructor_value = m_constructor->execute(interpreter, global_object);
if (interpreter.exception())
return {};
update_function_name(class_constructor_value, m_name);
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
VERIFY(class_constructor_value.is_function() && is<ECMAScriptFunctionObject>(class_constructor_value.as_function()));
auto* class_constructor = static_cast<ECMAScriptFunctionObject*>(&class_constructor_value.as_function());
LibJS: Throw TypeError when calling class constructor without 'new'
2020-11-11 21:37:40 +00:00
class_constructor->set_is_class_constructor();
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 super_constructor = js_undefined();
if (!m_super_class.is_null()) {
super_constructor = m_super_class->execute(interpreter, global_object);
if (interpreter.exception())
return {};
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
if (!super_constructor.is_function() && !super_constructor.is_null()) {
LibJS: Check if class extends value has a valid prototype If we have a function as class extends value, we still cannot assume that it has a prototype property and that property has a function or null as its value - blindly calling to_object() on it may fail. Fixes #5075.
2021-01-23 23:49:04 +01:00
interpreter.vm().throw_exception<TypeError>(global_object, ErrorType::ClassExtendsValueNotAConstructorOrNull, super_constructor.to_string_without_side_effects());
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
}
LibJS: Move [[ConstructorKind]] to ECMAScriptFunctionObject
2021-09-24 23:34:13 +02:00
class_constructor->set_constructor_kind(ECMAScriptFunctionObject::ConstructorKind::Derived);
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
Object* super_constructor_prototype = nullptr;
if (!super_constructor.is_null()) {
LibJS: Remove unnecessary value_or() from get() Object::get() never returns an empty value anymore, as per the spec, so having a value_or() fallback is no longer needed.
2021-07-04 22:55:45 +01:00
auto super_constructor_prototype_value = super_constructor.as_object().get(vm.names.prototype);
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
if (interpreter.exception())
return {};
LibJS: Check if class extends value has a valid prototype If we have a function as class extends value, we still cannot assume that it has a prototype property and that property has a function or null as its value - blindly calling to_object() on it may fail. Fixes #5075.
2021-01-23 23:49:04 +01:00
if (!super_constructor_prototype_value.is_object() && !super_constructor_prototype_value.is_null()) {
interpreter.vm().throw_exception<TypeError>(global_object, ErrorType::ClassExtendsValueInvalidPrototype, super_constructor_prototype_value.to_string_without_side_effects());
return {};
}
LibJS: Remove redundant exception check from ClassExpression::execute() as_object() cannot fail, leftover from ea55453.
2021-01-24 00:15:35 +01:00
if (super_constructor_prototype_value.is_object())
LibJS: Check if class extends value has a valid prototype If we have a function as class extends value, we still cannot assume that it has a prototype property and that property has a function or null as its value - blindly calling to_object() on it may fail. Fixes #5075.
2021-01-23 23:49:04 +01:00
super_constructor_prototype = &super_constructor_prototype_value.as_object();
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
}
LibJS: Replace Object's create_empty() with create() taking a prototype This now matches the spec's OrdinaryObjectCreate() across the board: instead of implicitly setting the created object's prototype to %Object.prototype% and then in many cases setting it to a nullptr right away, it now has an 'Object* prototype' parameter with _no default value_. This makes the code easier to compare with the spec, very clear in terms of what prototype is being used as well as avoiding unnecessary shape transitions. Also fixes a couple of cases were we weren't setting the correct prototype. There's no reason to assume that the object would not be empty (as in having own properties), so let's follow our existing pattern of Type::create(...) and simply call it 'create'.
2021-06-16 20:52:30 +01:00
auto* prototype = Object::create(global_object, super_constructor_prototype);
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
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
prototype->define_direct_property(vm.names.constructor, class_constructor, 0);
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
if (interpreter.exception())
return {};
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
class_constructor->define_direct_property(vm.names.prototype, prototype, Attribute::Writable);
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
if (interpreter.exception())
return {};
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
class_constructor->internal_set_prototype_of(super_constructor.is_null() ? global_object.function_prototype() : &super_constructor.as_object());
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
}
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
auto class_prototype = class_constructor->get(vm.names.prototype);
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
if (interpreter.exception())
return {};
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
if (!class_prototype.is_object()) {
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
interpreter.vm().throw_exception<TypeError>(global_object, ErrorType::NotAnObject, "Class prototype");
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
}
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
for (auto const& method : m_methods) {
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
auto method_value = method.execute(interpreter, global_object);
if (interpreter.exception())
return {};
LibJS: Move [[HomeObject]] to ECMAScriptFunctionObject
2021-09-24 23:49:24 +02:00
auto& method_function = static_cast<ECMAScriptFunctionObject&>(method_value.as_function());
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
auto key = method.key().execute(interpreter, global_object);
if (interpreter.exception())
return {};
LibJS: Add missing to_property_key exception check in ClassExpression
2021-06-17 01:32:08 +03:00
auto property_key = key.to_property_key(global_object);
if (interpreter.exception())
return {};
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
auto& target = method.is_static() ? *class_constructor : class_prototype.as_object();
method_function.set_home_object(&target);
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
switch (method.kind()) {
case ClassMethod::Kind::Method:
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
target.define_property_or_throw(property_key, { .value = method_value, .writable = true, .enumerable = false, .configurable = true });
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
break;
case ClassMethod::Kind::Getter:
update_function_name(method_value, String::formatted("get {}", get_function_name(global_object, key)));
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
target.define_property_or_throw(property_key, { .get = &method_function, .enumerable = true, .configurable = true });
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
break;
case ClassMethod::Kind::Setter:
update_function_name(method_value, String::formatted("set {}", get_function_name(global_object, key)));
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
target.define_property_or_throw(property_key, { .set = &method_function, .enumerable = true, .configurable = true });
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
break;
default:
VERIFY_NOT_REACHED();
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
}
if (interpreter.exception())
return {};
}
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
for (auto& field : m_fields) {
auto key = field.key().execute(interpreter, global_object);
if (interpreter.exception())
return {};
auto property_key = key.to_property_key(global_object);
if (interpreter.exception())
return {};
LibJS: Move [[HomeObject]] to ECMAScriptFunctionObject
2021-09-24 23:49:24 +02:00
ECMAScriptFunctionObject* initializer = nullptr;
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
if (field.initializer()) {
auto copy_initializer = field.initializer();
auto body = create_ast_node<ExpressionStatement>(field.initializer()->source_range(), copy_initializer.release_nonnull());
// FIXME: A potential optimization is not creating the functions here since these are never directly accessible.
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
initializer = ECMAScriptFunctionObject::create(interpreter.global_object(), property_key.to_display_string(), *body, {}, 0, interpreter.lexical_environment(), FunctionKind::Regular, false);
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
initializer->set_home_object(field.is_static() ? class_constructor : &class_prototype.as_object());
}
if (field.is_static()) {
Value field_value = js_undefined();
LibJS: Convert Value::invoke and VM::call to ThrowCompletionOr
2021-09-23 20:56:28 +03:00
if (initializer)
field_value = TRY_OR_DISCARD(interpreter.vm().call(*initializer, class_constructor_value));
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
class_constructor->create_data_property_or_throw(property_key, field_value);
if (interpreter.exception())
return {};
} else {
class_constructor->add_field(property_key, initializer);
}
}
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
return class_constructor;
}
Value ClassDeclaration::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
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 class_constructor = m_class_expression->execute(interpreter, global_object);
if (interpreter.exception())
return {};
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
interpreter.lexical_environment()->put_into_environment(m_class_expression->name(), { class_constructor, DeclarationKind::Let });
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
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
return {};
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
}
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
static void print_indent(int indent)
{
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
out("{}", String::repeated(' ', indent * 2));
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 ASTNode::dump(int indent) const
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", class_name());
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 ScopeNode::dump(int indent) const
{
ASTNode::dump(indent);
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
if (!m_variables.is_empty()) {
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Variables)");
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
for (auto& variable : m_variables)
variable.dump(indent + 2);
}
if (!m_children.is_empty()) {
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Children)");
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
for (auto& child : children())
child.dump(indent + 2);
}
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 BinaryExpression::dump(int indent) const
{
LibJS: Include the operator in BinaryExpression dumps
2020-03-07 23:16:34 +01:00
const char* op_string = nullptr;
switch (m_op) {
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Addition:
LibJS: Include the operator in BinaryExpression dumps
2020-03-07 23:16:34 +01:00
op_string = "+";
break;
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Subtraction:
LibJS: Include the operator in BinaryExpression dumps
2020-03-07 23:16:34 +01:00
op_string = "-";
break;
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Multiplication:
LibJS: Implement multiplication and division operators
2020-03-12 23:04:52 +11:00
op_string = "*";
break;
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
case BinaryOp::Division:
LibJS: Implement multiplication and division operators
2020-03-12 23:04:52 +11:00
op_string = "/";
break;
LibJS: Add basic support for modulo (%) in binary expressions
2020-04-04 21:17:34 +02:00
case BinaryOp::Modulo:
op_string = "%";
break;
LibJS: Implement exponentiation (** operator)
2020-04-05 13:40:00 +01:00
case BinaryOp::Exponentiation:
op_string = "**";
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyEquals:
LibJS: Add typed comparison operator The `===` operator allows us to compare two values while taking their type into consideration.
2020-03-08 07:53:02 +02:00
op_string = "===";
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyInequals:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = "!==";
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyEquals:
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
op_string = "==";
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyInequals:
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
op_string = "!=";
break;
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::GreaterThan:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = ">";
break;
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
case BinaryOp::GreaterThanEquals:
op_string = ">=";
break;
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::LessThan:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = "<";
break;
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
case BinaryOp::LessThanEquals:
op_string = "<=";
break;
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::BitwiseAnd:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = "&";
break;
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::BitwiseOr:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = "|";
break;
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::BitwiseXor:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = "^";
break;
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::LeftShift:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = "<<";
break;
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
case BinaryOp::RightShift:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = ">>";
break;
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
case BinaryOp::UnsignedRightShift:
op_string = ">>>";
break;
LibJS: Implement 'in' operator
2020-04-23 16:06:01 +01:00
case BinaryOp::In:
op_string = "in";
break;
LibJS: Implement the "instanceof" operator This operator walks the prototype chain of the RHS value and looks for a "prototype" property with the same value as the prototype of the LHS. This is pretty cool. :^)
2020-03-28 16:56:54 +01:00
case BinaryOp::InstanceOf:
op_string = "instanceof";
break;
LibJS: Add typed comparison operator The `===` operator allows us to compare two values while taking their type into consideration.
2020-03-08 07:53:02 +02:00
}
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", class_name());
LibJS: Add typed comparison operator The `===` operator allows us to compare two values while taking their type into consideration.
2020-03-08 07:53:02 +02:00
m_lhs->dump(indent + 1);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", op_string);
LibJS: Add typed comparison operator The `===` operator allows us to compare two values while taking their type into consideration.
2020-03-08 07:53:02 +02:00
m_rhs->dump(indent + 1);
}
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
void LogicalExpression::dump(int indent) const
{
const char* op_string = nullptr;
switch (m_op) {
case LogicalOp::And:
op_string = "&&";
break;
case LogicalOp::Or:
op_string = "||";
break;
LibJS: Implement nullish coalescing operator (??)
2020-04-18 00:49:11 +01:00
case LogicalOp::NullishCoalescing:
op_string = "??";
break;
LibJS: Include the operator in BinaryExpression dumps
2020-03-07 23:16:34 +01:00
}
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", class_name());
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
m_lhs->dump(indent + 1);
LibJS: Include the operator in BinaryExpression dumps
2020-03-07 23:16:34 +01:00
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", op_string);
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
m_rhs->dump(indent + 1);
}
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
void UnaryExpression::dump(int indent) const
{
const char* op_string = nullptr;
switch (m_op) {
LibJS: Rename BitNot -> BitwiseNot to match other bitwise operators
2020-03-14 20:43:35 +02:00
case UnaryOp::BitwiseNot:
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
op_string = "~";
break;
LibJS: Move logical not operator to new unary expression class
2020-03-09 19:04:44 +02:00
case UnaryOp::Not:
op_string = "!";
break;
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
case UnaryOp::Plus:
op_string = "+";
break;
case UnaryOp::Minus:
op_string = "-";
break;
LibJS: Implement typeof operator
2020-03-18 06:33:32 +11:00
case UnaryOp::Typeof:
op_string = "typeof ";
break;
LibJS: Implement void operator
2020-04-15 17:55:03 +01:00
case UnaryOp::Void:
op_string = "void ";
break;
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
case UnaryOp::Delete:
op_string = "delete ";
break;
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
}
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", class_name());
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", op_string);
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
m_lhs->dump(indent + 1);
}
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 CallExpression::dump(int indent) const
{
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 20:24:45 +02:00
print_indent(indent);
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (is<NewExpression>(*this))
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("CallExpression [new]");
else
outln("CallExpression");
LibJS: Add operator precedence parsing Obey precedence and associativity rules when parsing expressions with chained operators.
2020-03-12 23:02:41 +01:00
m_callee->dump(indent + 1);
LibJS: Dump CallExpression arguments (if any)
2020-03-12 19:34:59 +01:00
for (auto& argument : m_arguments)
LibJS: Add function call spreading Adds support for the following syntax: myFunction(...x, ...[1, 2, 3], ...o.foo, ...'abcd')
2020-05-05 22:36:24 -07:00
argument.value->dump(indent + 1);
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 SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
void SuperCall::dump(int indent) const
{
print_indent(indent);
outln("SuperCall");
for (auto& argument : m_arguments)
argument.value->dump(indent + 1);
}
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
void ClassDeclaration::dump(int indent) const
{
ASTNode::dump(indent);
m_class_expression->dump(indent + 1);
}
void ClassExpression::dump(int indent) const
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("ClassExpression: \"{}\"", m_name);
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
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Constructor)");
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
m_constructor->dump(indent + 1);
if (!m_super_class.is_null()) {
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Super Class)");
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
m_super_class->dump(indent + 1);
}
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Methods)");
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
for (auto& method : m_methods)
method.dump(indent + 1);
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
print_indent(indent);
outln("(Fields)");
for (auto& field : m_fields)
field.dump(indent + 1);
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
}
void ClassMethod::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Key)");
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
m_key->dump(indent + 1);
const char* kind_string = nullptr;
switch (m_kind) {
case Kind::Method:
kind_string = "Method";
break;
case Kind::Getter:
kind_string = "Getter";
break;
case Kind::Setter:
kind_string = "Setter";
break;
}
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("Kind: {}", kind_string);
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
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("Static: {}", m_is_static);
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
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Function)");
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
m_function->dump(indent + 1);
}
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
void ClassField::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
outln("(Key)");
m_key->dump(indent + 1);
print_indent(indent);
outln("Static: {}", m_is_static);
if (m_initializer) {
print_indent(indent);
outln("(Initializer)");
m_initializer->dump(indent + 1);
}
}
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
void StringLiteral::dump(int indent) 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
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("StringLiteral \"{}\"", m_value);
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01: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
void SuperExpression::dump(int indent) const
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("super");
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
}
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
void NumericLiteral::dump(int indent) const
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("NumericLiteral {}", m_value);
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
}
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
void BigIntLiteral::dump(int indent) const
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("BigIntLiteral {}", m_value);
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
void BooleanLiteral::dump(int indent) const
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("BooleanLiteral {}", m_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
}
LibJS: Implement null and undefined literals
2020-03-15 23:32:34 +02:00
void NullLiteral::dump(int indent) const
{
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("null");
LibJS: Implement null and undefined literals
2020-03-15 23:32:34 +02:00
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
void BindingPattern::dump(int indent) const
{
print_indent(indent);
outln("BindingPattern {}", kind == Kind::Array ? "Array" : "Object");
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
for (auto& entry : entries) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
print_indent(indent + 1);
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
outln("(Property)");
if (kind == Kind::Object) {
print_indent(indent + 2);
outln("(Identifier)");
if (entry.name.has<NonnullRefPtr<Identifier>>()) {
entry.name.get<NonnullRefPtr<Identifier>>()->dump(indent + 3);
} else {
entry.name.get<NonnullRefPtr<Expression>>()->dump(indent + 3);
}
} else if (entry.is_elision()) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
print_indent(indent + 2);
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
outln("(Elision)");
continue;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
}
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
print_indent(indent + 2);
outln("(Pattern{})", entry.is_rest ? " rest=true" : "");
if (entry.alias.has<NonnullRefPtr<Identifier>>()) {
entry.alias.get<NonnullRefPtr<Identifier>>()->dump(indent + 3);
} else if (entry.alias.has<NonnullRefPtr<BindingPattern>>()) {
entry.alias.get<NonnullRefPtr<BindingPattern>>()->dump(indent + 3);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
} else {
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
print_indent(indent + 3);
outln("<empty>");
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
}
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
if (entry.initializer) {
print_indent(indent + 2);
outln("(Initializer)");
entry.initializer->dump(indent + 3);
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
}
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
void FunctionNode::dump(int indent, String const& class_name) 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
{
print_indent(indent);
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11 03:38:05 +04:30
outln("{}{} '{}'", class_name, m_kind == FunctionKind::Generator ? "*" : "", name());
LibJS: Add function default arguments Adds the ability for function arguments to have default values. This works for standard functions as well as arrow functions. Default values are not printed in a <function>.toString() call, as nodes cannot print their source string representation.
2020-05-02 11:46:39 -07:00
if (!m_parameters.is_empty()) {
print_indent(indent + 1);
Everywhere: Remove accidental '\n' from various outln() invocations Also convert outln(stderr, ...) to warnln(...)
2021-06-03 22:49:37 +02:00
outln("(Parameters)");
LibJS: Add function default arguments Adds the ability for function arguments to have default values. This works for standard functions as well as arrow functions. Default values are not printed in a <function>.toString() call, as nodes cannot print their source string representation.
2020-05-02 11:46:39 -07:00
for (auto& parameter : m_parameters) {
print_indent(indent + 2);
LibJS: Implement rest parameters
2020-05-04 16:05:13 +01:00
if (parameter.is_rest)
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
out("...");
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
parameter.binding.visit(
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
[&](FlyString const& name) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
outln("{}", name);
},
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
[&](BindingPattern const& pattern) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
pattern.dump(indent + 2);
});
LibJS: Implement rest parameters
2020-05-04 16:05:13 +01:00
if (parameter.default_value)
LibJS: Add function default arguments Adds the ability for function arguments to have default values. This works for standard functions as well as arrow functions. Default values are not printed in a <function>.toString() call, as nodes cannot print their source string representation.
2020-05-02 11:46:39 -07:00
parameter.default_value->dump(indent + 3);
}
}
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Body)");
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
body().dump(indent + 2);
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 FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
void FunctionDeclaration::dump(int indent) const
{
FunctionNode::dump(indent, class_name());
}
void FunctionExpression::dump(int indent) const
{
FunctionNode::dump(indent, class_name());
}
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
void YieldExpression::dump(int indent) const
{
ASTNode::dump(indent);
if (argument())
argument()->dump(indent + 1);
}
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 ReturnStatement::dump(int indent) const
{
ASTNode::dump(indent);
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
if (argument())
argument()->dump(indent + 1);
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: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
void IfStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("If");
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
predicate().dump(indent + 1);
consequent().dump(indent + 1);
LibJS: Parse "if" statements This patch implements basic parsing of "if" statements. We don't yet support parsing "else", so I added a FIXME about that.
2020-03-21 18:40:17 +01:00
if (alternate()) {
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("Else");
LibJS: Parse "if" statements This patch implements basic parsing of "if" statements. We don't yet support parsing "else", so I added a FIXME about that.
2020-03-21 18:40:17 +01:00
alternate()->dump(indent + 1);
}
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
}
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
void WhileStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("While");
LibJS: Rename WhileStatement::predicate() => body() This name matches other parsers.
2020-04-04 21:21:19 +02:00
test().dump(indent + 1);
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
body().dump(indent + 1);
}
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
void WithStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("Object");
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
object().dump(indent + 2);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("Body");
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
body().dump(indent + 2);
}
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
void DoWhileStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("DoWhile");
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
test().dump(indent + 1);
body().dump(indent + 1);
}
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
void ForStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("For");
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
if (init())
init()->dump(indent + 1);
if (test())
test()->dump(indent + 1);
if (update())
update()->dump(indent + 1);
body().dump(indent + 1);
}
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
void ForInStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("ForIn");
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
lhs().dump(indent + 1);
rhs().dump(indent + 1);
body().dump(indent + 1);
}
void ForOfStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("ForOf");
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
lhs().dump(indent + 1);
rhs().dump(indent + 1);
body().dump(indent + 1);
}
LibJS: Make more Interpreter functions take a GlobalObject&
2020-06-08 21:25:16 +02:00
Value Identifier::execute(Interpreter& interpreter, GlobalObject& global_object) const
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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
auto value = interpreter.vm().get_variable(string(), global_object);
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
if (interpreter.exception())
return {};
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
if (value.is_empty()) {
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
interpreter.vm().throw_exception<ReferenceError>(global_object, ErrorType::UnknownIdentifier, string());
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
}
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 18:43:34 +02:00
return 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 21:13:55 +01:00
}
void Identifier::dump(int indent) const
{
print_indent(indent);
LibJS: Remove direct argument loading since it was buggy The parser doesn't always track lexical scopes correctly, so let's not rely on that for direct argument loading. This reverts the LoadArguments bytecode instruction as well. We can bring these things back when the parser can reliably tell us that a given Identifier is indeed a function argument.
2021-06-22 22:20:17 +02:00
outln("Identifier \"{}\"", m_string);
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: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
void SpreadExpression::dump(int indent) const
{
ASTNode::dump(indent);
m_target->dump(indent + 1);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value SpreadExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
return m_target->execute(interpreter, global_object);
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
}
LibJS: Reduce use of Interpreter in LexicalEnvironment
2020-09-29 16:41:28 +02:00
Value ThisExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Parse "this" as ThisExpression
2020-04-13 00:42:14 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Evaluate `this` in terms of ResolveThisBinding
2021-06-25 11:40:03 +02:00
return interpreter.vm().resolve_this_binding(global_object);
LibJS: Parse "this" as ThisExpression
2020-04-13 00:42:14 +02:00
}
void ThisExpression::dump(int indent) const
{
ASTNode::dump(indent);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value AssignmentExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
#define EXECUTE_LHS() \
do { \
if (auto* ptr = m_lhs.get_pointer<NonnullRefPtr<Expression>>()) { \
lhs_result = (*ptr)->execute(interpreter, global_object); \
if (interpreter.exception()) \
return {}; \
} \
} while (0)
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
#define EXECUTE_LHS_AND_RHS() \
do { \
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
EXECUTE_LHS(); \
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
rhs_result = m_rhs->execute(interpreter, global_object); \
if (interpreter.exception()) \
return {}; \
} while (0)
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: 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 20:24:45 +02:00
Value lhs_result;
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
Value rhs_result;
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
switch (m_op) {
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::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 21:13:55 +01:00
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::AdditionAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = add(global_object, lhs_result, rhs_result);
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::SubtractionAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = sub(global_object, lhs_result, rhs_result);
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::MultiplicationAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = mul(global_object, lhs_result, rhs_result);
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::DivisionAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = div(global_object, lhs_result, rhs_result);
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
break;
LibJS: Implement modulo assignment operator (%=)
2020-05-04 23:07:05 +01:00
case AssignmentOp::ModuloAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = mod(global_object, lhs_result, rhs_result);
LibJS: Implement modulo assignment operator (%=)
2020-05-04 23:07:05 +01:00
break;
LibJS: Implement exponentiation assignment operator (**=)
2020-05-04 23:03:35 +01:00
case AssignmentOp::ExponentiationAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
rhs_result = exp(global_object, lhs_result, rhs_result);
LibJS: Implement exponentiation assignment operator (**=)
2020-05-04 23:03:35 +01:00
break;
LibJS: Implement bitwise assignment operators (&=, |=, ^=)
2020-05-04 22:34:45 +01:00
case AssignmentOp::BitwiseAndAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = bitwise_and(global_object, lhs_result, rhs_result);
LibJS: Implement bitwise assignment operators (&=, |=, ^=)
2020-05-04 22:34:45 +01:00
break;
case AssignmentOp::BitwiseOrAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = bitwise_or(global_object, lhs_result, rhs_result);
LibJS: Implement bitwise assignment operators (&=, |=, ^=)
2020-05-04 22:34:45 +01:00
break;
case AssignmentOp::BitwiseXorAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = bitwise_xor(global_object, lhs_result, rhs_result);
LibJS: Implement bitwise assignment operators (&=, |=, ^=)
2020-05-04 22:34:45 +01:00
break;
LibJS: Implement bitwise left shift operator (<<)
2020-04-23 13:36:14 +01:00
case AssignmentOp::LeftShiftAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = left_shift(global_object, lhs_result, rhs_result);
LibJS: Implement bitwise left shift operator (<<)
2020-04-23 13:36:14 +01:00
break;
LibJS: Implement bitwise right shift operator (>>)
2020-04-23 13:45:19 +01:00
case AssignmentOp::RightShiftAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = right_shift(global_object, lhs_result, rhs_result);
LibJS: Implement bitwise right shift operator (>>)
2020-04-23 13:45:19 +01:00
break;
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
case AssignmentOp::UnsignedRightShiftAssignment:
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
EXECUTE_LHS_AND_RHS();
LibJS: Make all the JS::Value binary op helpers take GlobalObject& We don't need the Interpreter& for anything here, the GlobalObject is enough for getting to the VM and possibly throwing exceptions.
2020-09-27 19:52:47 +02:00
rhs_result = unsigned_right_shift(global_object, lhs_result, rhs_result);
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
break;
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
case AssignmentOp::AndAssignment:
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
EXECUTE_LHS();
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
if (!lhs_result.to_boolean())
return lhs_result;
rhs_result = m_rhs->execute(interpreter, global_object);
break;
case AssignmentOp::OrAssignment:
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
EXECUTE_LHS();
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
if (lhs_result.to_boolean())
return lhs_result;
rhs_result = m_rhs->execute(interpreter, global_object);
break;
case AssignmentOp::NullishAssignment:
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
EXECUTE_LHS();
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
if (!lhs_result.is_nullish())
return lhs_result;
rhs_result = m_rhs->execute(interpreter, global_object);
break;
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: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Remove unnecessary malloc+free in AssignmentExpression::execute We were creating a temporary AK::Function for no good reason, and this was dominating profiles. Reorganize the code so it's not necessary.
2020-04-05 19:21:36 +02:00
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
return m_lhs.visit(
[&](NonnullRefPtr<Expression>& lhs) -> JS::Value {
auto reference = lhs->to_reference(interpreter, global_object);
if (interpreter.exception())
return {};
LibJS: Make AssignmentExpression assign through a Reference Reference now has assign(Interpreter&, Value) which is used to write transparently through a Reference into whatever location it refers to.
2020-04-27 12:56:09 +02:00
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
if (m_op == AssignmentOp::Assignment) {
rhs_result = m_rhs->execute(interpreter, global_object);
if (interpreter.exception())
return {};
}
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
if (reference.is_unresolvable()) {
interpreter.vm().throw_exception<ReferenceError>(global_object, ErrorType::InvalidLeftHandAssignment);
return {};
}
LibJS: Only update anonymous function names when necessary Previously we would generate function names for anonymous functions on every AssignmentExpression, even if we weren't assigning a function. We were also setting names of anonymous functions in arrays, which is apparently a SpiderMonkey specific behavior not supported by V8, JSC or required by ECMA262. This patch removes that behavior. This is a huge performance improvement on the CanvasCycle demo! :^)
2021-03-21 17:14:20 +01:00
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
reference.put_value(global_object, rhs_result);
if (interpreter.exception())
return {};
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
return rhs_result;
},
[&](NonnullRefPtr<BindingPattern>& pattern) -> JS::Value {
VERIFY(m_op == AssignmentOp::Assignment);
rhs_result = m_rhs->execute(interpreter, global_object);
if (interpreter.exception())
return {};
interpreter.vm().assign(pattern, rhs_result, global_object);
if (interpreter.exception())
return {};
return rhs_result;
});
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value UpdateExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto reference = m_argument->to_reference(interpreter, global_object);
LibJS: Bring Reference records a bit closer to the ECMAScript spec Our Reference class now has the same fields as the spec: - Base (a non-nullish value, an environment record, or `unresolvable`) - Referenced Name (the name of the binding) - Strict (whether the reference originated in strict mode code) - ThisValue (if non-empty, the reference represents a `super` keyword) The main difference from before is that we now resolve the environment record that a reference interacts with. Previously we simply resolved to either "local variable" or "global variable". The associated abstract operations are still largely non-conforming, since we don't yet implement proper variable bindings. But this patch should at least fix a handful of test262 cases. :^) There's one minor regression: some TypeError message strings get a little worse due to doing a RequireObjectCoercible earlier in the evaluation of MemberExpression.
2021-06-25 16:27:59 +02:00
LibJS: Support o.f++ :^) This patch teaches UpdateExpression how to use a Reference. Some other changes were necessary to keep tests working: A Reference can now also refer to a local or global variable. This is not fully aligned with the spec since we don't have a Record concept.
2020-04-28 14:44:48 +02:00
if (interpreter.exception())
return {};
LibJS: Rename Reference methods to match the spec - get -> get_value (GetValue in the spec) - put -> put_value (PutValue in the spec) Also add spec links. :^)
2021-06-25 17:19:01 +02:00
auto old_value = reference.get_value(global_object);
LibJS: Improve UpdateExpression::execute() - Let undefined variables throw a ReferenceError by using Identifier::execute() rather than doing variable lookup manually and ASSERT()ing - Coerce value to number rather than ASSERT()ing - Make code DRY - Add tests
2020-04-21 23:27:11 +01:00
if (interpreter.exception())
return {};
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
old_value = old_value.to_numeric(global_object);
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
if (interpreter.exception())
return {};
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
Value new_value;
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
switch (m_op) {
case UpdateOp::Increment:
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (old_value.is_number())
new_value = Value(old_value.as_double() + 1);
else
LibJS: Remove js_bigint(Interpreter&, ...)
2020-09-27 20:00:38 +02:00
new_value = js_bigint(interpreter.heap(), old_value.as_bigint().big_integer().plus(Crypto::SignedBigInteger { 1 }));
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
break;
case UpdateOp::Decrement:
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
if (old_value.is_number())
new_value = Value(old_value.as_double() - 1);
else
LibJS: Remove js_bigint(Interpreter&, ...)
2020-09-27 20:00:38 +02:00
new_value = js_bigint(interpreter.heap(), old_value.as_bigint().big_integer().minus(Crypto::SignedBigInteger { 1 }));
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 14:24:34 +02:00
break;
LibJS: Improve UpdateExpression::execute() - Let undefined variables throw a ReferenceError by using Identifier::execute() rather than doing variable lookup manually and ASSERT()ing - Coerce value to number rather than ASSERT()ing - Make code DRY - Add tests
2020-04-21 23:27:11 +01:00
default:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
}
LibJS: Rename Reference methods to match the spec - get -> get_value (GetValue in the spec) - put -> put_value (PutValue in the spec) Also add spec links. :^)
2021-06-25 17:19:01 +02:00
reference.put_value(global_object, new_value);
LibJS: Support o.f++ :^) This patch teaches UpdateExpression how to use a Reference. Some other changes were necessary to keep tests working: A Reference can now also refer to a local or global variable. This is not fully aligned with the spec since we don't have a Record concept.
2020-04-28 14:44:48 +02:00
if (interpreter.exception())
return {};
LibJS: Improve UpdateExpression::execute() - Let undefined variables throw a ReferenceError by using Identifier::execute() rather than doing variable lookup manually and ASSERT()ing - Coerce value to number rather than ASSERT()ing - Make code DRY - Add tests
2020-04-21 23:27:11 +01:00
return m_prefixed ? new_value : old_value;
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
}
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
void AssignmentExpression::dump(int indent) const
{
const char* op_string = nullptr;
switch (m_op) {
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::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 21:13:55 +01:00
op_string = "=";
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::AdditionAssignment:
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
op_string = "+=";
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::SubtractionAssignment:
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
op_string = "-=";
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::MultiplicationAssignment:
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
op_string = "*=";
break;
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
case AssignmentOp::DivisionAssignment:
LibJS: Implement +=, -=, *=, and /= assignment operators
2020-03-12 23:09:15 +11:00
op_string = "/=";
break;
LibJS: Implement modulo assignment operator (%=)
2020-05-04 23:07:05 +01:00
case AssignmentOp::ModuloAssignment:
op_string = "%=";
break;
LibJS: Implement exponentiation assignment operator (**=)
2020-05-04 23:03:35 +01:00
case AssignmentOp::ExponentiationAssignment:
op_string = "**=";
break;
LibJS: Implement bitwise assignment operators (&=, |=, ^=)
2020-05-04 22:34:45 +01:00
case AssignmentOp::BitwiseAndAssignment:
op_string = "&=";
break;
case AssignmentOp::BitwiseOrAssignment:
op_string = "|=";
break;
case AssignmentOp::BitwiseXorAssignment:
op_string = "^=";
break;
LibJS: Implement bitwise left shift operator (<<)
2020-04-23 13:36:14 +01:00
case AssignmentOp::LeftShiftAssignment:
op_string = "<<=";
break;
LibJS: Implement bitwise right shift operator (>>)
2020-04-23 13:45:19 +01:00
case AssignmentOp::RightShiftAssignment:
op_string = ">>=";
break;
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
case AssignmentOp::UnsignedRightShiftAssignment:
op_string = ">>>=";
break;
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
case AssignmentOp::AndAssignment:
op_string = "&&=";
break;
case AssignmentOp::OrAssignment:
op_string = "||=";
break;
case AssignmentOp::NullishAssignment:
op_string = "\?\?=";
break;
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
}
ASTNode::dump(indent);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", op_string);
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
m_lhs.visit([&](auto& lhs) { lhs->dump(indent + 1); });
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
m_rhs->dump(indent + 1);
}
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
void UpdateExpression::dump(int indent) const
{
const char* op_string = nullptr;
switch (m_op) {
case UpdateOp::Increment:
op_string = "++";
break;
case UpdateOp::Decrement:
op_string = "--";
break;
}
ASTNode::dump(indent);
LibJS: Fix dump() indentation of UpdateExpression with suffix operator
2020-10-19 00:17:46 +01:00
if (m_prefixed) {
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", op_string);
LibJS: Fix dump() indentation of UpdateExpression with suffix operator
2020-10-19 00:17:46 +01:00
}
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
m_argument->dump(indent + 1);
LibJS/AST: Implement prefixed update expressions
2020-03-14 20:44:57 +02:00
if (!m_prefixed) {
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", op_string);
LibJS/AST: Implement prefixed update expressions
2020-03-14 20:44:57 +02:00
}
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value VariableDeclaration::execute(Interpreter& interpreter, GlobalObject& global_object) const
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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
for (auto& declarator : m_declarations) {
if (auto* init = declarator.init()) {
LibJS: Fix spelling mistake in VariableDeclaration::execute()
2021-06-21 19:23:06 +02:00
auto initializer_result = init->execute(interpreter, global_object);
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
if (interpreter.exception())
return {};
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
declarator.target().visit(
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
[&](NonnullRefPtr<Identifier> const& id) {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
auto variable_name = id->string();
if (is<ClassExpression>(*init))
LibJS: Fix spelling mistake in VariableDeclaration::execute()
2021-06-21 19:23:06 +02:00
update_function_name(initializer_result, variable_name);
interpreter.vm().set_variable(variable_name, initializer_result, global_object, true);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
},
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
[&](NonnullRefPtr<BindingPattern> const& pattern) {
LibJS: Fix spelling mistake in VariableDeclaration::execute()
2021-06-21 19:23:06 +02:00
interpreter.vm().assign(pattern, initializer_result, global_object, true);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
});
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
}
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
}
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
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 21:13:55 +01:00
}
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:45:22 +03:30
Value VariableDeclarator::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Handle return value in switch statement unwinding Fixes #3790.
2020-10-18 17:44:55 +01:00
// NOTE: VariableDeclarator execution is handled by VariableDeclaration.
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
}
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
void VariableDeclaration::dump(int indent) const
{
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 11:59:18 +02:00
const char* declaration_kind_string = nullptr;
switch (m_declaration_kind) {
case DeclarationKind::Let:
declaration_kind_string = "Let";
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
break;
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 11:59:18 +02:00
case DeclarationKind::Var:
declaration_kind_string = "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 14:24:34 +02:00
break;
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 11:59:18 +02:00
case DeclarationKind::Const:
declaration_kind_string = "Const";
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
break;
}
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
ASTNode::dump(indent);
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
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{}", declaration_kind_string);
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
for (auto& declarator : m_declarations)
declarator.dump(indent + 1);
}
void VariableDeclarator::dump(int indent) const
{
ASTNode::dump(indent);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
m_target.visit([indent](const auto& value) { value->dump(indent + 1); });
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
if (m_init)
m_init->dump(indent + 1);
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
}
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
void ObjectProperty::dump(int indent) const
{
ASTNode::dump(indent);
m_key->dump(indent + 1);
m_value->dump(indent + 1);
}
LibJS: Add a very simple ObjectExpression for "var x = {}" This allows us to allocate an empty new Object on the GC heap.
2020-03-09 21:28:31 +01:00
void ObjectExpression::dump(int indent) const
{
ASTNode::dump(indent);
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
for (auto& property : m_properties) {
property.dump(indent + 1);
LibJS: Parse object expressions
2020-03-21 02:29:00 +02:00
}
LibJS: Add a very simple ObjectExpression for "var x = {}" This allows us to allocate an empty new Object on the GC heap.
2020-03-09 21:28:31 +01:00
}
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
void ExpressionStatement::dump(int indent) const
{
ASTNode::dump(indent);
m_expression->dump(indent + 1);
}
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:45:22 +03:30
Value ObjectProperty::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
// NOTE: ObjectProperty execution is handled by ObjectExpression.
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ObjectExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add a very simple ObjectExpression for "var x = {}" This allows us to allocate an empty new Object on the GC heap.
2020-03-09 21:28:31 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Replace Object's create_empty() with create() taking a prototype This now matches the spec's OrdinaryObjectCreate() across the board: instead of implicitly setting the created object's prototype to %Object.prototype% and then in many cases setting it to a nullptr right away, it now has an 'Object* prototype' parameter with _no default value_. This makes the code easier to compare with the spec, very clear in terms of what prototype is being used as well as avoiding unnecessary shape transitions. Also fixes a couple of cases were we weren't setting the correct prototype. There's no reason to assume that the object would not be empty (as in having own properties), so let's follow our existing pattern of Type::create(...) and simply call it 'create'.
2021-06-16 20:52:30 +01:00
auto* object = Object::create(global_object, global_object.object_prototype());
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
for (auto& property : m_properties) {
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
auto key = property.key().execute(interpreter, global_object);
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
if (interpreter.exception())
return {};
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
if (property.type() == ObjectProperty::Type::Spread) {
LibJS: Remove Object::is_array() in favor of Value::is_array() and RTTI It's way too easy to get this wrong: for the IsArray abstract operation, Value::is_array() needs to be called. Since we have RTTI, the virtual Object::is_array() method is not needed anymore - if we need to know whether something is *actually* a JS::Array (we currently check in more cases than we should, I think) and not a Proxy with an Array target, we should do that in a way that doesn't look like an abstract operation.
2021-07-05 18:58:51 +01:00
if (key.is_object() && is<Array>(key.as_object())) {
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
auto& array_to_spread = static_cast<Array&>(key.as_object());
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
for (auto& entry : array_to_spread.indexed_properties()) {
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
auto value = array_to_spread.get(entry.index());
if (interpreter.exception())
return {};
object->indexed_properties().put(entry.index(), value);
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (interpreter.exception())
return {};
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
} else if (key.is_object()) {
auto& obj_to_spread = key.as_object();
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
LibJS: Implement correct object property ordering This commit introduces a way to get an object's own properties in the correct order. The "correct order" for JS object properties is first all array-like index properties (numeric keys) sorted by insertion order, followed by all string properties sorted by insertion order. Objects also now print correctly in the repl! Before this commit: courage ~/js-tests $ js > ({ foo: 1, bar: 2, baz: 3 }) { bar: 2, foo: 1, baz: 3 } After: courage ~/js-tests $ js > ({ foo: 1, bar: 2, baz: 3 }) { foo: 1, bar: 2, baz: 3 }
2020-04-28 19:19:31 -07:00
for (auto& it : obj_to_spread.shape().property_table_ordered()) {
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (it.value.attributes.is_enumerable()) {
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
object->define_direct_property(it.key, obj_to_spread.get(it.key), JS::default_attributes);
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter.exception())
return {};
}
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
} else if (key.is_string()) {
auto& str_to_spread = key.as_string().string();
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
for (size_t i = 0; i < str_to_spread.length(); i++) {
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
object->define_direct_property(i, js_string(interpreter.heap(), str_to_spread.substring(i, 1)), JS::default_attributes);
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter.exception())
return {};
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
}
}
continue;
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto value = property.value().execute(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07: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
if (value.is_function() && property.is_method())
LibJS: Move [[HomeObject]] to ECMAScriptFunctionObject
2021-09-24 23:49:24 +02:00
static_cast<ECMAScriptFunctionObject&>(value.as_function()).set_home_object(object);
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
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
String name = get_function_name(global_object, key);
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
if (property.type() == ObjectProperty::Type::Getter) {
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
name = String::formatted("get {}", name);
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
} else if (property.type() == ObjectProperty::Type::Setter) {
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
name = String::formatted("set {}", name);
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
}
update_function_name(value, name);
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
switch (property.type()) {
case ObjectProperty::Type::Getter:
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(value.is_function());
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
object->define_direct_accessor(PropertyName::from_value(global_object, key), &value.as_function(), nullptr, Attribute::Configurable | Attribute::Enumerable);
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
break;
case ObjectProperty::Type::Setter:
VERIFY(value.is_function());
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
object->define_direct_accessor(PropertyName::from_value(global_object, key), nullptr, &value.as_function(), Attribute::Configurable | Attribute::Enumerable);
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
break;
case ObjectProperty::Type::KeyValue:
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
object->define_direct_property(PropertyName::from_value(global_object, key), value, JS::default_attributes);
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
break;
case ObjectProperty::Type::Spread:
default:
VERIFY_NOT_REACHED();
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
}
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
if (interpreter.exception())
return {};
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
}
LibJS: Parse object expressions
2020-03-21 02:29:00 +02:00
return object;
LibJS: Add a very simple ObjectExpression for "var x = {}" This allows us to allocate an empty new Object on the GC heap.
2020-03-09 21:28:31 +01:00
}
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
void MemberExpression::dump(int indent) const
{
LibJS: Parse computed MemberExpressions MemberExpression comes in two flavors: computed: a[b] non-computed: a.b We can now parse both of the types. :^)
2020-03-20 20:51:03 +01:00
print_indent(indent);
LibJS: Remove stray '%' from MemberExpression AST dump
2021-04-24 13:49:43 +02:00
outln("{}(computed={})", class_name(), is_computed());
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
m_object->dump(indent + 1);
m_property->dump(indent + 1);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
PropertyName MemberExpression::computed_property_name(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Parse computed MemberExpressions MemberExpression comes in two flavors: computed: a[b] non-computed: a.b We can now parse both of the types. :^)
2020-03-20 20:51:03 +01:00
{
Userland: Replace VERIFY(is<T>) with verify_cast<T> Instead of doing a VERIFY(is<T>(x)) and *then* casting it to T, we can just do the cast right away with verify_cast<T>. :^)
2021-06-24 21:13:09 +02:00
if (!is_computed())
return verify_cast<Identifier>(*m_property).string();
LibJS: Use PropertyName::from_value() in MemberExpression::computed_property_name() No need for duplicating this logic.
2020-10-07 19:54:36 +01:00
auto value = m_property->execute(interpreter, global_object);
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
if (interpreter.exception())
return {};
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!value.is_empty());
LibJS: Use PropertyName::from_value() in MemberExpression::computed_property_name() No need for duplicating this logic.
2020-10-07 19:54:36 +01:00
return PropertyName::from_value(global_object, value);
LibJS: Parse computed MemberExpressions MemberExpression comes in two flavors: computed: a[b] non-computed: a.b We can now parse both of the types. :^)
2020-03-20 20:51:03 +01:00
}
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
String MemberExpression::to_string_approximation() const
{
String object_string = "<object>";
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (is<Identifier>(*m_object))
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
object_string = static_cast<Identifier const&>(*m_object).string();
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
if (is_computed())
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
return String::formatted("{}[<computed>]", object_string);
Userland: Replace VERIFY(is<T>) with verify_cast<T> Instead of doing a VERIFY(is<T>(x)) and *then* casting it to T, we can just do the cast right away with verify_cast<T>. :^)
2021-06-24 21:13:09 +02:00
return String::formatted("{}.{}", object_string, verify_cast<Identifier>(*m_property).string());
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value MemberExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Use reference in MemberExpression::execute() This was basically duplicated code.
2021-04-14 22:14:54 +02:00
auto reference = to_reference(interpreter, global_object);
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
if (interpreter.exception())
return {};
LibJS: Rename Reference methods to match the spec - get -> get_value (GetValue in the spec) - put -> put_value (PutValue in the spec) Also add spec links. :^)
2021-06-25 17:19:01 +02:00
return reference.get_value(global_object);
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
}
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
void OptionalChain::dump(int indent) const
{
print_indent(indent);
outln("{}", class_name());
m_base->dump(indent + 1);
for (auto& reference : m_references) {
reference.visit(
[&](Call const& call) {
print_indent(indent + 1);
outln("Call({})", call.mode == Mode::Optional ? "Optional" : "Not Optional");
for (auto& argument : call.arguments)
argument.value->dump(indent + 2);
},
[&](ComputedReference const& ref) {
print_indent(indent + 1);
outln("ComputedReference({})", ref.mode == Mode::Optional ? "Optional" : "Not Optional");
ref.expression->dump(indent + 2);
},
[&](MemberReference const& ref) {
print_indent(indent + 1);
outln("MemberReference({})", ref.mode == Mode::Optional ? "Optional" : "Not Optional");
ref.identifier->dump(indent + 2);
});
}
}
Optional<OptionalChain::ReferenceAndValue> OptionalChain::to_reference_and_value(JS::Interpreter& interpreter, JS::GlobalObject& global_object) const
{
// Note: This is wrapped in an optional to allow base_reference = ...
Optional<JS::Reference> base_reference = m_base->to_reference(interpreter, global_object);
auto base = base_reference->is_unresolvable() ? m_base->execute(interpreter, global_object) : base_reference->get_value(global_object);
if (interpreter.exception())
return {};
for (auto& reference : m_references) {
auto is_optional = reference.visit([](auto& ref) { return ref.mode; }) == Mode::Optional;
if (is_optional && base.is_nullish())
return ReferenceAndValue { {}, js_undefined() };
auto expression = reference.visit(
[&](Call const& call) -> NonnullRefPtr<Expression> {
return create_ast_node<CallExpression>(source_range(),
create_ast_node<SyntheticReferenceExpression>(source_range(), *base_reference, base),
call.arguments);
},
[&](ComputedReference const& ref) -> NonnullRefPtr<Expression> {
return create_ast_node<MemberExpression>(source_range(),
create_ast_node<SyntheticReferenceExpression>(source_range(), *base_reference, base),
ref.expression,
true);
},
[&](MemberReference const& ref) -> NonnullRefPtr<Expression> {
return create_ast_node<MemberExpression>(source_range(),
create_ast_node<SyntheticReferenceExpression>(source_range(), *base_reference, base),
ref.identifier,
false);
});
if (is<CallExpression>(*expression)) {
base_reference = JS::Reference {};
base = expression->execute(interpreter, global_object);
} else {
base_reference = expression->to_reference(interpreter, global_object);
base = base_reference->get_value(global_object);
}
if (interpreter.exception())
return {};
}
return ReferenceAndValue { base_reference.release_value(), base };
}
Value OptionalChain::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
InterpreterNodeScope node_scope { interpreter, *this };
if (auto result = to_reference_and_value(interpreter, global_object); result.has_value())
return result.release_value().value;
return {};
}
JS::Reference OptionalChain::to_reference(Interpreter& interpreter, GlobalObject& global_object) const
{
if (auto result = to_reference_and_value(interpreter, global_object); result.has_value())
return result.release_value().reference;
return {};
}
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
void MetaProperty::dump(int indent) const
{
String name;
if (m_type == MetaProperty::Type::NewTarget)
name = "new.target";
else if (m_type == MetaProperty::Type::ImportMeta)
name = "import.meta";
else
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("{} {}", class_name(), name);
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
}
Value MetaProperty::execute(Interpreter& interpreter, GlobalObject&) const
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
if (m_type == MetaProperty::Type::NewTarget)
return interpreter.vm().get_new_target().value_or(js_undefined());
if (m_type == MetaProperty::Type::ImportMeta)
TODO();
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value StringLiteral::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Remove js_string(Interpreter&, ...)
2020-09-27 20:03:42 +02:00
return js_string(interpreter.heap(), m_value);
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
}
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:45:22 +03:30
Value NumericLiteral::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
return Value(m_value);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value BigIntLiteral::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Add support for hex, octal & binary big integer literals
2021-06-14 02:19:23 +03:00
Crypto::SignedBigInteger integer;
if (m_value[0] == '0' && m_value.length() >= 3) {
if (m_value[1] == 'x' || m_value[1] == 'X') {
LibCrypto: Replace from_base{2,8,10,16}() & to_base10 with from_base(N) This allows us to support parsing and serializing BigIntegers to and from any base N (such that 2 <= N <= 36).
2021-06-29 17:51:52 +03:00
return js_bigint(interpreter.heap(), Crypto::SignedBigInteger::from_base(16, m_value.substring(2, m_value.length() - 3)));
LibJS: Add support for hex, octal & binary big integer literals
2021-06-14 02:19:23 +03:00
} else if (m_value[1] == 'o' || m_value[1] == 'O') {
LibCrypto: Replace from_base{2,8,10,16}() & to_base10 with from_base(N) This allows us to support parsing and serializing BigIntegers to and from any base N (such that 2 <= N <= 36).
2021-06-29 17:51:52 +03:00
return js_bigint(interpreter.heap(), Crypto::SignedBigInteger::from_base(8, m_value.substring(2, m_value.length() - 3)));
LibJS: Add support for hex, octal & binary big integer literals
2021-06-14 02:19:23 +03:00
} else if (m_value[1] == 'b' || m_value[1] == 'B') {
LibCrypto: Replace from_base{2,8,10,16}() & to_base10 with from_base(N) This allows us to support parsing and serializing BigIntegers to and from any base N (such that 2 <= N <= 36).
2021-06-29 17:51:52 +03:00
return js_bigint(interpreter.heap(), Crypto::SignedBigInteger::from_base(2, m_value.substring(2, m_value.length() - 3)));
LibJS: Add support for hex, octal & binary big integer literals
2021-06-14 02:19:23 +03:00
}
}
LibCrypto: Replace from_base{2,8,10,16}() & to_base10 with from_base(N) This allows us to support parsing and serializing BigIntegers to and from any base N (such that 2 <= N <= 36).
2021-06-29 17:51:52 +03:00
return js_bigint(interpreter.heap(), Crypto::SignedBigInteger::from_base(10, m_value.substring(0, m_value.length() - 1)));
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
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:45:22 +03:30
Value BooleanLiteral::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
return Value(m_value);
}
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:45:22 +03:30
Value NullLiteral::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Implement null and undefined literals
2020-03-15 23:32:34 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Implement null and undefined literals
2020-03-15 23:32:34 +02:00
return js_null();
}
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
void RegExpLiteral::dump(int indent) const
{
print_indent(indent);
LibJS: Rename RegExpLiteral m_content to m_pattern This is what we call it elsewhere, let's be consistent.
2021-05-10 11:56:08 +01:00
outln("{} (/{}/{})", class_name(), pattern(), flags());
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
}
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:45:22 +03:30
Value RegExpLiteral::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 10:34:37 -04:00
Regex<ECMA262> regex(parsed_regex(), parsed_pattern(), parsed_flags());
return RegExpObject::create(global_object, move(regex), pattern(), flags());
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
}
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
void ArrayExpression::dump(int indent) const
{
ASTNode::dump(indent);
for (auto& element : m_elements) {
LibJS: Support empty values in array expression
2020-04-15 20:09:06 +01:00
if (element) {
element->dump(indent + 1);
} else {
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("<empty>");
LibJS: Support empty values in array expression
2020-04-15 20:09:06 +01:00
}
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
}
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ArrayExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Bring ArrayCreate and ArrayConstructor closer to spec Specifically, this now explicitly takes the length, adds missing exceptions checks to calls with user-supplied lengths, takes and uses the prototype argument, and fixes some spec non-conformance in ArrayConstructor and its native functions around the use of ArrayCreate
2021-07-04 01:36:44 +03:00
auto* array = Array::create(global_object, 0);
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-06 03:29:52 +04:30
array->indexed_properties();
size_t index = 0;
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
for (auto& element : m_elements) {
LibJS: Support empty values in array expression
2020-04-15 20:09:06 +01:00
auto value = Value();
if (element) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
value = element->execute(interpreter, global_object);
LibJS: Support empty values in array expression
2020-04-15 20:09:06 +01:00
if (interpreter.exception())
return {};
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (is<SpreadExpression>(*element)) {
LibJS: get_iterator_values() should pass Value to callback (not Value&) Value& implies that the callback is expected/able to modify the value, which is not the case.
2020-09-08 14:15:13 +02:00
get_iterator_values(global_object, value, [&](Value iterator_value) {
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-06 03:29:52 +04:30
array->indexed_properties().put(index++, iterator_value, default_attributes);
LibJS: Integrate iterator protocol into language features Finally use Symbol.iterator protocol in language features :) currently only used in for-of loops and spread expressions, but will have more uses later (Maps, Sets, Array.from, etc).
2020-07-13 08:27:20 -07:00
return IterationDecision::Continue;
});
if (interpreter.exception())
return {};
continue;
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
}
LibJS: Support empty values in array expression
2020-04-15 20:09:06 +01:00
}
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-06 03:29:52 +04:30
array->indexed_properties().put(index++, value, default_attributes);
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
}
return array;
}
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
void TemplateLiteral::dump(int indent) const
{
ASTNode::dump(indent);
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
for (auto& expression : m_expressions)
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
expression.dump(indent + 1);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value TemplateLiteral::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
StringBuilder string_builder;
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
for (auto& expression : m_expressions) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto expr = expression.execute(interpreter, global_object);
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
if (interpreter.exception())
return {};
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
auto string = expr.to_string(global_object);
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
if (interpreter.exception())
return {};
string_builder.append(string);
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
}
LibJS: Remove js_string(Interpreter&, ...)
2020-09-27 20:03:42 +02:00
return js_string(interpreter.heap(), string_builder.build());
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
}
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
void TaggedTemplateLiteral::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Tag)");
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
m_tag->dump(indent + 2);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Template Literal)");
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
m_template_literal->dump(indent + 2);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value TaggedTemplateLiteral::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
auto& vm = interpreter.vm();
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto tag = m_tag->execute(interpreter, global_object);
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
if (vm.exception())
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
return {};
if (!tag.is_function()) {
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
vm.throw_exception<TypeError>(global_object, ErrorType::NotAFunction, tag.to_string_without_side_effects());
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
return {};
}
auto& tag_function = tag.as_function();
auto& expressions = m_template_literal->expressions();
LibJS: Bring ArrayCreate and ArrayConstructor closer to spec Specifically, this now explicitly takes the length, adds missing exceptions checks to calls with user-supplied lengths, takes and uses the prototype argument, and fixes some spec non-conformance in ArrayConstructor and its native functions around the use of ArrayCreate
2021-07-04 01:36:44 +03:00
auto* strings = Array::create(global_object, 0);
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
MarkedValueList arguments(vm.heap());
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
arguments.append(strings);
for (size_t i = 0; i < expressions.size(); ++i) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto value = expressions[i].execute(interpreter, global_object);
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
if (vm.exception())
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
return {};
// tag`${foo}` -> "", foo, "" -> tag(["", ""], foo)
// tag`foo${bar}baz${qux}` -> "foo", bar, "baz", qux, "" -> tag(["foo", "baz", ""], bar, qux)
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (i % 2 == 0) {
strings->indexed_properties().append(value);
} else {
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
arguments.append(value);
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
}
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
}
LibJS: Add raw strings to tagged template literals When calling a function with a tagged template, the first array that is passed in now contains a "raw" property with the raw, escaped strings.
2020-05-06 16:34:14 -07:00
LibJS: Bring ArrayCreate and ArrayConstructor closer to spec Specifically, this now explicitly takes the length, adds missing exceptions checks to calls with user-supplied lengths, takes and uses the prototype argument, and fixes some spec non-conformance in ArrayConstructor and its native functions around the use of ArrayCreate
2021-07-04 01:36:44 +03:00
auto* raw_strings = Array::create(global_object, 0);
LibJS: Add raw strings to tagged template literals When calling a function with a tagged template, the first array that is passed in now contains a "raw" property with the raw, escaped strings.
2020-05-06 16:34:14 -07:00
for (auto& raw_string : m_template_literal->raw_strings()) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto value = raw_string.execute(interpreter, global_object);
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
if (vm.exception())
LibJS: Add raw strings to tagged template literals When calling a function with a tagged template, the first array that is passed in now contains a "raw" property with the raw, escaped strings.
2020-05-06 16:34:14 -07:00
return {};
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
raw_strings->indexed_properties().append(value);
LibJS: Add raw strings to tagged template literals When calling a function with a tagged template, the first array that is passed in now contains a "raw" property with the raw, escaped strings.
2020-05-06 16:34:14 -07:00
}
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
strings->define_direct_property(vm.names.raw, raw_strings, 0);
LibJS: Convert Value::invoke and VM::call to ThrowCompletionOr
2021-09-23 20:56:28 +03:00
return TRY_OR_DISCARD(vm.call(tag_function, js_undefined(), move(arguments)));
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
}
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
void TryStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Block)");
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
block().dump(indent + 1);
if (handler()) {
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Handler)");
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
handler()->dump(indent + 1);
}
if (finalizer()) {
print_indent(indent);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Finalizer)");
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
finalizer()->dump(indent + 1);
}
}
void CatchClause::dump(int indent) const
{
print_indent(indent);
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 15:15:38 +04:30
m_parameter.visit(
[&](FlyString const& parameter) {
if (parameter.is_null())
outln("CatchClause");
else
outln("CatchClause ({})", parameter);
},
[&](NonnullRefPtr<BindingPattern> const& pattern) {
outln("CatchClause");
print_indent(indent);
outln("(Parameter)");
pattern->dump(indent + 2);
});
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
body().dump(indent + 1);
}
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
void ThrowStatement::dump(int indent) const
{
ASTNode::dump(indent);
argument().dump(indent + 1);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value TryStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Fix returning from try statement Not sure if this regressed at some point or just never worked, it definitely wasn't tested at all. We would always return undefined when returning from a try statement block, handler, or finalizer.
2021-04-03 14:56:54 +02:00
auto result = interpreter.execute_statement(global_object, m_block, ScopeType::Try);
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
if (auto* exception = interpreter.exception()) {
if (m_handler) {
LibJS: Move the current exception from Interpreter to VM This will allow us to throw exceptions even when there is no active interpreter in the VM.
2020-09-21 15:28:09 +02:00
interpreter.vm().clear_exception();
LibJS: Create lexical scope for "catch" on the spot when throwing
2020-12-08 18:12:39 +01:00
HashMap<FlyString, Variable> parameters;
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 15:15:38 +04:30
m_handler->parameter().visit(
[&](FlyString const& parameter) {
parameters.set(parameter, Variable { exception->value(), DeclarationKind::Var });
},
[&](NonnullRefPtr<BindingPattern> const& pattern) {
pattern->for_each_bound_name([&](auto& name) {
parameters.set(name, Variable { Value {}, DeclarationKind::Var });
});
});
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
auto* catch_scope = interpreter.heap().allocate<DeclarativeEnvironment>(global_object, move(parameters), interpreter.vm().running_execution_context().lexical_environment);
TemporaryChange<Environment*> scope_change(interpreter.vm().running_execution_context().lexical_environment, catch_scope);
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 15:15:38 +04:30
if (auto* pattern = m_handler->parameter().get_pointer<NonnullRefPtr<BindingPattern>>())
interpreter.vm().assign(*pattern, exception->value(), global_object, true);
if (interpreter.exception())
result = js_undefined();
else
result = interpreter.execute_statement(global_object, m_handler->body());
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
}
}
LibJS: Stop unwinding and reset exception for TryStatement finalizer This fixes two issues with running a TryStatement finalizer: - Temporarily store and clear the exception, if any, so we can run the finalizer block statement without it getting in our way, which could have unexpected side effects otherwise (and will likely return early somewhere). - Stop unwinding so more than one child node of the finalizer BlockStatement is executed if an exception has been thrown previously (which would have called unwind(ScopeType::Try)). Re-throwing as described above ensures we still unwind after the finalizer, if necessary. Also add some tests specifically for try/catch/finally blocks, we didn't have any!
2020-09-11 23:30:00 +01:00
if (m_finalizer) {
// Keep, if any, and then clear the current exception so we can
// execute() the finalizer without an exception in our way.
auto* previous_exception = interpreter.exception();
LibJS: Move the current exception from Interpreter to VM This will allow us to throw exceptions even when there is no active interpreter in the VM.
2020-09-21 15:28:09 +02:00
interpreter.vm().clear_exception();
LibJS: Fix return value of TryStatement with finalizer Previously we would always return the result of executing the finalizer, however the spec dictates the finalizer result must only be returned for a non-normal completion. I added some more comments along the way, which should make it more clear what's going on - the unwinding and exception flow isn't super straightforward here.
2021-04-13 00:57:17 +02:00
// Remember what scope type we were unwinding to, and temporarily
// clear it as well (e.g. return from handler).
auto unwind_until = interpreter.vm().unwind_until();
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
interpreter.vm().stop_unwind();
LibJS: Fix return value of TryStatement with finalizer Previously we would always return the result of executing the finalizer, however the spec dictates the finalizer result must only be returned for a non-normal completion. I added some more comments along the way, which should make it more clear what's going on - the unwinding and exception flow isn't super straightforward here.
2021-04-13 00:57:17 +02:00
auto finalizer_result = m_finalizer->execute(interpreter, global_object);
if (interpreter.vm().should_unwind()) {
// This was NOT a 'normal' completion (e.g. return from finalizer).
result = finalizer_result;
} else {
// Continue unwinding to whatever we found ourselves unwinding
// to when the finalizer was entered (e.g. return from handler,
// which is unaffected by normal completion from finalizer).
interpreter.vm().unwind(unwind_until);
// If we previously had an exception and the finalizer didn't
// throw a new one, restore the old one.
if (previous_exception && !interpreter.exception())
LibJS: Add set_exception() and change throw_exception() to take a reference Sometimes we just want to set m_exception to some value we stored previously, without really "throwing" it again - that's what set_exception() does now. Since we have clear_exception(), it does take a reference, i.e. you don't set_exception(nullptr). For consistency I updated throw_exception() to do the same.
2021-04-13 01:02:38 +02:00
interpreter.vm().set_exception(*previous_exception);
LibJS: Fix return value of TryStatement with finalizer Previously we would always return the result of executing the finalizer, however the spec dictates the finalizer result must only be returned for a non-normal completion. I added some more comments along the way, which should make it more clear what's going on - the unwinding and exception flow isn't super straightforward here.
2021-04-13 00:57:17 +02:00
}
LibJS: Stop unwinding and reset exception for TryStatement finalizer This fixes two issues with running a TryStatement finalizer: - Temporarily store and clear the exception, if any, so we can run the finalizer block statement without it getting in our way, which could have unexpected side effects otherwise (and will likely return early somewhere). - Stop unwinding so more than one child node of the finalizer BlockStatement is executed if an exception has been thrown previously (which would have called unwind(ScopeType::Try)). Re-throwing as described above ensures we still unwind after the finalizer, if necessary. Also add some tests specifically for try/catch/finally blocks, we didn't have any!
2020-09-11 23:30:00 +01: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 14:37:39 +01:00
LibJS: Update empty TryStatement result value to undefined It's what the spec wants us to do, although I'm not sure if it has an observable effect anywhere, as we don't expose empty values. Let's do it anyway.
2021-04-13 00:58:54 +02:00
return result.value_or(js_undefined());
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
}
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:45:22 +03:30
Value CatchClause::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
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
// NOTE: CatchClause execution is handled by TryStatement.
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
return {};
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ThrowStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
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: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto value = m_argument->execute(interpreter, global_object);
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
if (interpreter.vm().exception())
LibJS: Check for exceptions in a lot more places
2020-03-27 15:35:35 +01:00
return {};
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
interpreter.vm().throw_exception(global_object, value);
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value SwitchStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto discriminant_result = m_discriminant->execute(interpreter, global_object);
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
if (interpreter.exception())
return {};
bool falling_through = false;
LibJS: Make SwitchStatement::execute() return undefined for empty blocks Previously SwitchStatement::execute() would return <empty> when hitting break, continue or empty consequent block. This was not in line with the standard.
2021-06-06 20:58:10 +02:00
auto last_value = js_undefined();
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
for (auto& switch_case : m_cases) {
if (!falling_through && switch_case.test()) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto test_result = switch_case.test()->execute(interpreter, global_object);
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
if (interpreter.exception())
return {};
LibJS: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
if (!is_strictly_equal(discriminant_result, test_result))
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
continue;
}
falling_through = true;
for (auto& statement : switch_case.consequent()) {
LibJS: Make SwitchStatement::execute() return undefined for empty blocks Previously SwitchStatement::execute() would return <empty> when hitting break, continue or empty consequent block. This was not in line with the standard.
2021-06-06 20:58:10 +02:00
auto value = statement.execute(interpreter, global_object);
if (!value.is_empty())
last_value = value;
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
if (interpreter.exception())
return {};
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
if (interpreter.vm().should_unwind()) {
LibJS: Handle return value in switch statement unwinding Fixes #3790.
2020-10-18 17:44:55 +01:00
if (interpreter.vm().should_unwind_until(ScopeType::Continuable, m_label)) {
LibJS: Handle continue in switch statement unwinding
2020-10-18 18:01:12 +01:00
// No stop_unwind(), the outer loop will handle that - we just need to break out of the switch/case.
LibJS: Make SwitchStatement::execute() return undefined for empty blocks Previously SwitchStatement::execute() would return <empty> when hitting break, continue or empty consequent block. This was not in line with the standard.
2021-06-06 20:58:10 +02:00
return last_value;
LibJS: Handle return value in switch statement unwinding Fixes #3790.
2020-10-18 17:44:55 +01:00
} else if (interpreter.vm().should_unwind_until(ScopeType::Breakable, m_label)) {
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
interpreter.vm().stop_unwind();
LibJS: Make SwitchStatement::execute() return undefined for empty blocks Previously SwitchStatement::execute() would return <empty> when hitting break, continue or empty consequent block. This was not in line with the standard.
2021-06-06 20:58:10 +02:00
return last_value;
LibJS: Handle return value in switch statement unwinding Fixes #3790.
2020-10-18 17:44:55 +01:00
} else {
return last_value;
LibJS: Make "break" actually work inside "switch"
2020-04-05 00:09:48 +02:00
}
}
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
}
}
LibJS: Make SwitchStatement::execute() return undefined for empty blocks Previously SwitchStatement::execute() would return <empty> when hitting break, continue or empty consequent block. This was not in line with the standard.
2021-06-06 20:58:10 +02:00
return last_value;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
}
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:45:22 +03:30
Value SwitchCase::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Handle return value in switch statement unwinding Fixes #3790.
2020-10-18 17:44:55 +01:00
// NOTE: SwitchCase execution is handled by SwitchStatement.
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY_NOT_REACHED();
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
return {};
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value BreakStatement::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
interpreter.vm().unwind(ScopeType::Breakable, m_target_label);
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
return {};
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ContinueStatement::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
interpreter.vm().unwind(ScopeType::Continuable, m_target_label);
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
return {};
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
}
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
void SwitchStatement::dump(int indent) const
{
ASTNode::dump(indent);
m_discriminant->dump(indent + 1);
for (auto& switch_case : m_cases) {
switch_case.dump(indent + 1);
}
}
void SwitchCase::dump(int indent) const
{
ASTNode::dump(indent);
LibJS: Add indentation to sections in SwitchCase::dump() This now matches the output of Program (Variables) ... (Children) ... or FunctionDeclaration 'foo' (Parameters) ... (Body) ... etc. Also don't print each consequent statement index, it doesn't add any value.
2020-05-04 19:01:24 +01:00
print_indent(indent + 1);
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
if (m_test) {
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Test)");
LibJS: Add indentation to sections in SwitchCase::dump() This now matches the output of Program (Variables) ... (Children) ... or FunctionDeclaration 'foo' (Parameters) ... (Body) ... etc. Also don't print each consequent statement index, it doesn't add any value.
2020-05-04 19:01:24 +01:00
m_test->dump(indent + 2);
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
} else {
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Default)");
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
}
LibJS: Add indentation to sections in SwitchCase::dump() This now matches the output of Program (Variables) ... (Children) ... or FunctionDeclaration 'foo' (Parameters) ... (Body) ... etc. Also don't print each consequent statement index, it doesn't add any value.
2020-05-04 19:01:24 +01:00
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Consequent)");
LibJS: Add indentation to sections in SwitchCase::dump() This now matches the output of Program (Variables) ... (Children) ... or FunctionDeclaration 'foo' (Parameters) ... (Body) ... etc. Also don't print each consequent statement index, it doesn't add any value.
2020-05-04 19:01:24 +01:00
for (auto& statement : m_consequent)
statement.dump(indent + 2);
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
}
LibJS: Implement constructor/non-constructor function calls This adds Function::construct() for constructor function calls via `new` keyword. NativeFunction doesn't have constructor behaviour by default, ScriptFunction simply calls call() in construct()
2020-04-01 18:31:24 +01:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value ConditionalExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto test_result = m_test->execute(interpreter, global_object);
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
if (interpreter.exception())
return {};
Value result;
if (test_result.to_boolean()) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
result = m_consequent->execute(interpreter, global_object);
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
} else {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
result = m_alternate->execute(interpreter, global_object);
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
}
if (interpreter.exception())
return {};
return result;
}
void ConditionalExpression::dump(int indent) const
{
ASTNode::dump(indent);
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Test)");
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
m_test->dump(indent + 2);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Consequent)");
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
m_consequent->dump(indent + 2);
print_indent(indent + 1);
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
outln("(Alternate)");
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
m_alternate->dump(indent + 2);
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
}
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
void SequenceExpression::dump(int indent) const
{
ASTNode::dump(indent);
for (auto& expression : m_expressions)
expression.dump(indent + 1);
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value SequenceExpression::execute(Interpreter& interpreter, GlobalObject& global_object) const
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02: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 17:38:42 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
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:45:22 +03:30
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
Value last_value;
for (auto& expression : m_expressions) {
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
last_value = expression.execute(interpreter, global_object);
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
if (interpreter.exception())
return {};
}
return last_value;
}
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:45:22 +03:30
Value DebuggerStatement::execute(Interpreter& interpreter, GlobalObject&) const
LibJS: Implement (no-op) debugger statement
2020-04-30 17:26:27 +01:00
{
LibJS: Make an RAII helper for entering/exiting AST nodes
2021-03-16 10:51:55 +01:00
InterpreterNodeScope node_scope { interpreter, *this };
LibJS: Hide some debug output behind flags This hides some Object.cpp output, as well as removing the "debugger" debug output.
2020-07-03 22:46:12 -07:00
// Sorry, no JavaScript debugger available (yet)!
LibJS: Implement non-value-producing statements properly For various statements the spec states: Return NormalCompletion(empty). In those cases we have been returning undefined so far, which is incorrect. In other cases it states: Return Completion(UpdateEmpty(stmtCompletion, undefined)). Which essentially means a statement is evaluated and its completion value returned if non-empty, and undefined otherwise. While not actually noticeable in normal scripts as the VM's "last value" can't be accessed from JS code directly (with the exception of eval(), see below), it provided an inconsistent experience in the REPL: > if (true) 42; 42 > if (true) { 42; } undefined This also fixes the case where eval() would return undefined if the last executed statement is not a value-producing one: eval("1;;;;;") eval("1;{}") eval("1;var a;") As a consequence of the changes outlined above, these now all correctly return 1. See https://tc39.es/ecma262/#sec-block-runtime-semantics-evaluation, "NOTE 2". Fixes #3609.
2021-03-16 09:12:34 +01:00
return {};
LibJS: Implement (no-op) debugger statement
2020-04-30 17:26:27 +01: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 16:42:54 +02:00
void ScopeNode::add_variables(NonnullRefPtrVector<VariableDeclaration> variables)
{
AK: Rename Vector::append(Vector) => Vector::extend(Vector) Let's make it a bit more clear when we're appending the elements from one vector to the end of another vector.
2021-06-12 13:24:45 +02:00
m_variables.extend(move(variables));
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
}
LibJS: Hoist function declarations This patch adds function declaration hoisting. The mechanism is similar to var hoisting. Hoisted function declarations are to be put before the hoisted var declarations, hence they have to be treated separately.
2020-06-04 14:48:36 +02:00
void ScopeNode::add_functions(NonnullRefPtrVector<FunctionDeclaration> functions)
{
AK: Rename Vector::append(Vector) => Vector::extend(Vector) Let's make it a bit more clear when we're appending the elements from one vector to the end of another vector.
2021-06-12 13:24:45 +02:00
m_functions.extend(move(functions));
LibJS: Hoist function declarations This patch adds function declaration hoisting. The mechanism is similar to var hoisting. Hoisted function declarations are to be put before the hoisted var declarations, hence they have to be treated separately.
2020-06-04 14:48:36 +02:00
}
LibJS: Don't hoist functions under certain circumstances When a lexical declaration with the same name as a function exists, the function is not hoisted (annex B).
2021-07-05 21:45:34 +02:00
void ScopeNode::add_hoisted_function(NonnullRefPtr<FunctionDeclaration> hoisted_function)
LibJS: Improve function hoisting across blocks The parser now keeps track of a scope chain so that it can hoist function declarations to the closest function scope.
2021-07-04 03:15:52 +02:00
{
LibJS: Don't hoist functions under certain circumstances When a lexical declaration with the same name as a function exists, the function is not hoisted (annex B).
2021-07-05 21:45:34 +02:00
m_hoisted_functions.append(hoisted_function);
LibJS: Improve function hoisting across blocks The parser now keeps track of a scope chain so that it can hoist function declarations to the closest function scope.
2021-07-04 03:15:52 +02:00
}
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
Value ImportStatement::execute(Interpreter& interpreter, GlobalObject&) const
{
InterpreterNodeScope node_scope { interpreter, *this };
dbgln("Modules are not fully supported yet!");
TODO();
return {};
}
Value ExportStatement::execute(Interpreter& interpreter, GlobalObject& global_object) const
{
InterpreterNodeScope node_scope { interpreter, *this };
if (m_statement)
return m_statement->execute(interpreter, global_object);
return {};
}
void ExportStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent + 1);
outln("(ExportEntries)");
auto string_or_null = [](String const& string) -> String {
if (string.is_empty()) {
return "null";
}
return String::formatted("\"{}\"", string);
};
for (auto& entry : m_entries) {
print_indent(indent + 2);
outln("ModuleRequest: {}, ImportName: {}, LocalName: {}, ExportName: {}", string_or_null(entry.module_request), entry.kind == ExportEntry::ModuleRequest ? string_or_null(entry.local_or_import_name) : "null", entry.kind != ExportEntry::ModuleRequest ? string_or_null(entry.local_or_import_name) : "null", string_or_null(entry.export_name));
}
}
void ImportStatement::dump(int indent) const
{
ASTNode::dump(indent);
print_indent(indent + 1);
if (m_entries.is_empty()) {
// direct from "module" import
outln("Entire module '{}'", m_module_request);
} else {
outln("(ExportEntries) from {}", m_module_request);
for (auto& entry : m_entries) {
print_indent(indent + 2);
outln("ImportName: {}, LocalName: {}", entry.import_name, entry.local_name);
}
}
}
bool ExportStatement::has_export(StringView export_name) const
{
return any_of(m_entries.begin(), m_entries.end(), [&](auto& entry) {
return entry.export_name == export_name;
});
}
bool ImportStatement::has_bound_name(StringView name) const
{
return any_of(m_entries.begin(), m_entries.end(), [&](auto& entry) {
return entry.local_name == name;
});
}
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