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

2173 lines
70 KiB
C++
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
LibJS: 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
* Copyright (c) 2020-2021, Linus Groh <mail@linusgroh.de>
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
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
LibJS: 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: 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: 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: 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: 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 "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/ScriptFunction.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: 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 <LibJS/Runtime/WithScope.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:
InterpreterNodeScope(Interpreter& interpreter, const ASTNode& node)
: 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: 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.vm().call_frame().current_node = &node;
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: Use IndexedProperties::for_each_value() in update_function_name() This allows us to get rid of IndexedProperties::values_unordered().
2020-12-08 15:08:49 +01:00
static void update_function_name(Value value, const FlyString& 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();
if (is<ScriptFunction>(function) && function.name().is_empty())
static_cast<ScriptFunction&>(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: 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: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
return ScriptFunction::create(global_object, name(), body(), parameters(), function_length(), interpreter.current_scope(), is_strict_mode() || interpreter.vm().in_strict_mode(), m_is_arrow_function);
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
CallExpression::ThisAndCallee CallExpression::compute_this_and_callee(Interpreter& interpreter, GlobalObject& global_object) 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: 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: 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
// Computing |this| is irrelevant for "new" expression.
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
return { js_undefined(), m_callee->execute(interpreter, 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: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (is<SuperExpression>(*m_callee)) {
Everywhere: Fix typos Mostly in comments, but sprintf() now prints "August" instead of "Auguest" so that's something.
2020-10-02 09:59:28 -04:00
// If we are calling super, |this| has not been initialized yet, and would not be meaningful to provide.
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
auto new_target = vm.get_new_target();
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(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
return { js_undefined(), new_target };
}
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (is<MemberExpression>(*m_callee)) {
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
auto& member_expression = static_cast<const MemberExpression&>(*m_callee);
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
bool is_super_property_lookup = is<SuperExpression>(member_expression.object());
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
auto lookup_target = is_super_property_lookup ? interpreter.current_environment()->get_super_base() : member_expression.object().execute(interpreter, global_object);
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
if (vm.exception())
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 {};
LibJS: Add Value::is_nullish()
2020-10-02 16:00:15 +02:00
if (is_super_property_lookup && lookup_target.is_nullish()) {
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
vm.throw_exception<TypeError>(global_object, ErrorType::ObjectPrototypeNullOrUndefinedOnSuperPropertyAccess, lookup_target.to_string_without_side_effects());
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 {};
}
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* this_value = is_super_property_lookup ? &vm.this_value(global_object).as_object() : lookup_target.to_object(global_object);
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
if (vm.exception())
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 {};
LibJS: Check validity of computed_property_name() result before using it This fixes two cases obj[expr] and obj[expr]() (MemberExpression and CallExpression respectively) when expr throws an exception and results in an empty value, causing a crash by passing the invalid PropertyName created by computed_property_name() to Object::get() without checking it first. Fixes #3459.
2020-09-12 10:22:36 +01:00
auto property_name = member_expression.computed_property_name(interpreter, global_object);
if (!property_name.is_valid())
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 callee = lookup_target.to_object(global_object)->get(property_name).value_or(js_undefined());
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: Remove some more use of Interpreter::global_object() Let's do some more work towards supporting multiple global objects.
2020-06-20 12:47:19 +02:00
return { &global_object, m_callee->execute(interpreter, 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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
Value CallExpression::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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto [this_value, callee] = compute_this_and_callee(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 {};
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(!callee.is_empty());
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: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
if (!callee.is_function()
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
|| (is<NewExpression>(*this) && (is<NativeFunction>(callee.as_object()) && !static_cast<NativeFunction&>(callee.as_object()).has_constructor()))) {
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
String error_message;
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
auto call_type = is<NewExpression>(*this) ? "constructor" : "function";
if (is<Identifier>(*m_callee) || is<MemberExpression>(*m_callee)) {
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
String expression_string;
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_callee)) {
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
expression_string = static_cast<const Identifier&>(*m_callee).string();
LibJS: Consolidate error messages into ErrorTypes.h Now, exceptions can be thrown with interpreter.throw_exception<T>(ErrorType:TYPE, "format", "args", "here").
2020-06-09 22:48:01 -07:00
} else {
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
expression_string = static_cast<const MemberExpression&>(*m_callee).to_string_approximation();
LibJS: Consolidate error messages into ErrorTypes.h Now, exceptions can be thrown with interpreter.throw_exception<T>(ErrorType:TYPE, "format", "args", "here").
2020-06-09 22:48:01 -07:00
}
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
vm.throw_exception<TypeError>(global_object, ErrorType::IsNotAEvaluatedFrom, callee.to_string_without_side_effects(), call_type, expression_string);
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
} else {
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
vm.throw_exception<TypeError>(global_object, ErrorType::IsNotA, callee.to_string_without_side_effects(), call_type);
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
}
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 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: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
auto& function = callee.as_function();
LibJS: Add NativeFunction, a callable wrapper around a C++ lambda This can be used to implement arbitrary functionality, callable from JavaScript. To make this work, I had to change the way CallExpression passes arguments to the callee. Instead of a HashMap<String, Value>, we now pass an ordered list of Argument { String name; Value value; }. This patch includes a native "print(argument)" function. :^)
2020-03-12 19:53:31 +01:00
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
MarkedValueList arguments(vm.heap());
arguments.ensure_capacity(m_arguments.size());
LibJS: Implement Function.prototype.bind()
2020-04-19 15:03:02 -05:00
LibJS: Fix a handful of clang-tidy complaints in AST.cpp
2021-03-03 22:07:10 +01:00
for (auto& argument : m_arguments) {
auto value = argument.value->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: Fix a handful of clang-tidy complaints in AST.cpp
2021-03-03 22:07:10 +01:00
if (argument.is_spread) {
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) {
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
if (vm.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;
arguments.append(iterator_value);
return IterationDecision::Continue;
});
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
if (vm.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 {};
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
} else {
arguments.append(value);
}
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: Allow functions to take arguments (#1405)
2020-03-12 19:22:13 +08:00
LibJS: Move AST node stack from VM to Interpreter
2021-03-21 12:18:56 +01:00
vm.call_frame().current_node = interpreter.current_node();
LibJS: Implement basic support for the "new" keyword NewExpression mostly piggybacks on the existing CallExpression. The big difference is that "new" creates a new Object and passes it as |this| to the callee.
2020-03-28 16:33:52 +01:00
Object* new_object = nullptr;
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
Value result;
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: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
result = vm.construct(function, function, move(arguments), global_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
if (result.is_object())
new_object = &result.as_object();
LibJS: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
} else if (is<SuperExpression>(*m_callee)) {
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
auto* super_constructor = interpreter.current_environment()->current_function()->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
// FIXME: Functions should track their constructor kind.
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 || !super_constructor->is_function()) {
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
vm.throw_exception<TypeError>(global_object, ErrorType::NotAConstructor, "Super constructor");
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: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
result = vm.construct(static_cast<Function&>(*super_constructor), function, move(arguments), global_object);
if (vm.exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07: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: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
interpreter.current_environment()->bind_this_value(global_object, result);
LibJS: Implement basic support for the "new" keyword NewExpression mostly piggybacks on the existing CallExpression. The big difference is that "new" creates a new Object and passes it as |this| to the callee.
2020-03-28 16:33:52 +01:00
} else {
LibJS: Tidy up CallExpression::execute() a little bit
2020-10-13 19:00:37 +02:00
result = vm.call(function, this_value, move(arguments));
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: 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: 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: 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: Implement basic support for the "new" keyword NewExpression mostly piggybacks on the existing CallExpression. The big difference is that "new" creates a new Object and passes it as |this| to the callee.
2020-03-28 16:33:52 +01:00
if (result.is_object())
return result;
return new_object;
}
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: 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: 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: 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
auto object_value = m_object->execute(interpreter, global_object);
if (interpreter.exception())
return {};
auto* object = object_value.to_object(global_object);
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(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
auto* with_scope = interpreter.heap().allocate<WithScope>(global_object, *object, interpreter.vm().call_frame().scope);
TemporaryChange<ScopeObject*> scope_change(interpreter.vm().call_frame().scope, with_scope);
interpreter.execute_statement(global_object, m_body);
return {};
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: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
if (m_init && is<VariableDeclaration>(*m_init) && static_cast<const VariableDeclaration&>(*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;
decls.append(*static_cast<const VariableDeclaration*>(m_init.ptr()));
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: Remove hand-rolled type information in JS AST in favor of RTTI
2021-01-01 19:34:07 +01:00
static FlyString variable_from_for_declaration(Interpreter& interpreter, GlobalObject& global_object, const ASTNode& node, RefPtr<BlockStatement> wrapper)
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
{
FlyString variable_name;
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)) {
auto& variable_declaration = static_cast<const VariableDeclaration&>(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);
variable_name = variable_declaration.declarations().first().id().string();
} else if (is<Identifier>(node)) {
variable_name = static_cast<const Identifier&>(node).string();
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
} 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 basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
}
return variable_name;
}
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto variable_name = 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: 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: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
auto property_names = object->get_own_properties(*object, Object::PropertyKind::Key, true);
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& property_name : property_names.as_object().indexed_properties()) {
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
interpreter.vm().set_variable(variable_name, property_name.value_and_attributes(object).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
}
}
}
object = object->prototype();
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto variable_name = 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: 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
interpreter.vm().set_variable(variable_name, 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: 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
case BinaryOp::TypedEquals:
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(strict_eq(lhs_result, rhs_result));
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
case BinaryOp::TypedInequals:
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(!strict_eq(lhs_result, rhs_result));
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
case BinaryOp::AbstractEquals:
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 Value(abstract_eq(global_object, lhs_result, rhs_result));
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
case BinaryOp::AbstractInequals:
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 Value(!abstract_eq(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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +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: Move most of Interpreter into VM This patch moves the exception state, call stack and scope stack from Interpreter to VM. I'm doing this to help myself discover what the split between Interpreter and VM should be, by shuffling things around and seeing what falls where. With these changes, we no longer have a persistent lexical environment for the current global object on the Interpreter's call stack. Instead, we push/pop that environment on Interpreter::run() enter/exit. Since it should only be used to find the global "this", and not for variable storage (that goes directly into the global object instead!), I had to insert some short-circuiting when walking the environment parent chain during variable lookup. Note that this is a "stepping stone" commit, not a final design.
2020-09-27 15:18:55 +02:00
return interpreter.vm().get_reference(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: 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: 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())
return {};
LibJS: Throw in strict mode when assigning property to primitive value
2020-05-28 17:48:25 +01:00
return { object_value, property_name };
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: 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 (reference.is_unresolvable())
return Value(true);
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
// FIXME: Support deleting locals
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(!reference.is_local_variable());
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 (reference.is_global_variable())
LibJS: Remove some more use of Interpreter::global_object() Let's do some more work towards supporting multiple global objects.
2020-06-20 12:47:19 +02:00
return global_object.delete_property(reference.name());
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* base_object = reference.base().to_object(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 (!base_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
return {};
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 base_object->delete_property(reference.name());
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 {};
}
// FIXME: standard recommends checking with is_unresolvable but it ALWAYS return false here
if (reference.is_local_variable() || reference.is_global_variable()) {
LibJS: Fix a handful of clang-tidy complaints in AST.cpp
2021-03-03 22:07:10 +01:00
const auto& name = reference.name();
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
lhs_result = interpreter.vm().get_variable(name.to_string(), global_object).value_or(js_undefined());
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 {};
}
} 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: 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 SuperExpression::execute(Interpreter& 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 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
// The semantics for SuperExpressions are handled in CallExpression::compute_this_and_callee()
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);
}
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);
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(class_constructor_value.is_function() && is<ScriptFunction>(class_constructor_value.as_function()));
LibJS: Fix a handful of clang-tidy complaints in AST.cpp
2021-03-03 22:07:10 +01:00
auto* class_constructor = static_cast<ScriptFunction*>(&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: 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
class_constructor->set_constructor_kind(Function::ConstructorKind::Derived);
LibJS: Simplify Cell::initialize() Remove the Interpreter& argument and pass only GlobalObject&. We can find everything we need via the global object anyway.
2020-07-22 17:50:18 +02:00
Object* prototype = Object::create_empty(global_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
Object* super_constructor_prototype = nullptr;
if (!super_constructor.is_null()) {
LibJS: Fix crash when printing error for missing class extends value prototype If it's missing we get an empty value, but we can't use that with to_string_without_side_effects() so we have to use undefined as the default. Fixes #5142.
2021-01-28 10:20:52 +01:00
auto super_constructor_prototype_value = super_constructor.as_object().get(vm.names.prototype).value_or(js_undefined());
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
}
prototype->set_prototype(super_constructor_prototype);
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
prototype->define_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: Constructor function's "prototype" property should be writable This matches other engines.
2020-11-29 18:01:59 +01:00
class_constructor->define_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 {};
class_constructor->set_prototype(super_constructor.is_null() ? global_object.function_prototype() : &super_constructor.as_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
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: 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 (const auto& method : m_methods) {
auto method_value = method.execute(interpreter, global_object);
if (interpreter.exception())
return {};
auto& method_function = method_value.as_function();
auto key = method.key().execute(interpreter, global_object);
if (interpreter.exception())
return {};
auto& target = method.is_static() ? *class_constructor : class_prototype.as_object();
method_function.set_home_object(&target);
if (method.kind() == ClassMethod::Kind::Method) {
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
target.define_property(StringOrSymbol::from_value(global_object, key), method_value);
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
} else {
String accessor_name = [&] {
switch (method.kind()) {
case ClassMethod::Kind::Getter:
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
return String::formatted("get {}", get_function_name(global_object, 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
case ClassMethod::Kind::Setter:
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
return String::formatted("set {}", get_function_name(global_object, 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
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: 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
}
}();
update_function_name(method_value, accessor_name);
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
target.define_accessor(StringOrSymbol::from_value(global_object, key), method_function, method.kind() == ClassMethod::Kind::Getter, Attribute::Configurable | Attribute::Enumerable);
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 {};
}
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: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
interpreter.current_scope()->put_to_scope(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: 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
case BinaryOp::TypedEquals:
op_string = "===";
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
case BinaryOp::TypedInequals:
op_string = "!==";
break;
LibJS: Implement abstract equality and inequality
2020-03-16 00:23:38 +02:00
case BinaryOp::AbstractEquals:
op_string = "==";
break;
case BinaryOp::AbstractInequals:
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: 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);
}
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: 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: 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
void FunctionNode::dump(int indent, const String& 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 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: 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);
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("(Parameters)\n");
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("...");
outln("{}", parameter.name);
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
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: 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& variable : m_variables)
variable.dump(indent + 2);
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: 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: 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: Use String::formatted() for throw_exception() message
2020-10-04 13:55:20 +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: 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("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: Reduce use of Interpreter in LexicalEnvironment
2020-09-29 16:41:28 +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: 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 { \
lhs_result = m_lhs->execute(interpreter, global_object); \
if (interpreter.exception()) \
return {}; \
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:
lhs_result = m_lhs->execute(interpreter, global_object);
if (interpreter.exception())
return {};
if (!lhs_result.to_boolean())
return lhs_result;
rhs_result = m_rhs->execute(interpreter, global_object);
break;
case AssignmentOp::OrAssignment:
lhs_result = m_lhs->execute(interpreter, global_object);
if (interpreter.exception())
return {};
if (lhs_result.to_boolean())
return lhs_result;
rhs_result = m_rhs->execute(interpreter, global_object);
break;
case AssignmentOp::NullishAssignment:
lhs_result = m_lhs->execute(interpreter, global_object);
if (interpreter.exception())
return {};
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: 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 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
if (interpreter.exception())
return {};
LibJS: Evaluate AssignmentExpression LHS before RHS according to the spec Fixes #3689.
2020-10-05 12:30:08 +01:00
if (m_op == AssignmentOp::Assignment) {
rhs_result = m_rhs->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 (reference.is_unresolvable()) {
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<ReferenceError>(global_object, ErrorType::InvalidLeftHandAssignment);
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: 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: Reduce use of Interpreter in Reference
2020-09-29 16:45:24 +02:00
reference.put(global_object, rhs_result);
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
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: 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
return rhs_result;
}
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: 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: Reduce use of Interpreter in Reference
2020-09-29 16:45:24 +02:00
auto old_value = reference.get(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: Reduce use of Interpreter in Reference
2020-09-29 16:45:24 +02:00
reference.put(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: 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_lhs->dump(indent + 1);
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto initalizer_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: Set name of anonymous functions during assignment
2020-05-02 20:28:48 +01:00
auto variable_name = declarator.id().string();
Only apply auto-naming of function expressions based on syntax The auto naming of function expressions is a purely syntactic decision, so shouldn't be decided based on the dynamic type of an assignment. This moves the decision making into the parser. One icky hack is that we add a field to FunctionExpression to indicate whether we can autoname. The real solution is to actually generate a CompoundExpression node so that the parser can make the correct decision, however this would have a potentially significant run time cost. This does not correct the behaviour for class expressions. Patch from Anonymous.
2021-03-22 12:44:07 +01:00
if (is<ClassExpression>(*init))
update_function_name(initalizer_result, variable_name);
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().set_variable(variable_name, initalizer_result, global_object, true);
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);
m_id->dump(indent + 1);
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: Simplify Cell::initialize() Remove the Interpreter& argument and pass only GlobalObject&. We can find everything we need via the global object anyway.
2020-07-22 17:50:18 +02:00
auto* object = Object::create_empty(global_object);
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: 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 (key.is_array()) {
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: Use element index as key for array spread in object This fixes spreading of arrays with holes in object literals where the inserted keys are not consecutive numbers. Fixes #3967.
2020-11-06 22:49:36 +00:00
object->indexed_properties().put(object, entry.index(), entry.value_and_attributes(&array_to_spread).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: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
object->define_property(it.key, obj_to_spread.get(it.key));
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: Remove js_string(Interpreter&, ...)
2020-09-27 20:03:42 +02:00
object->define_property(i, js_string(interpreter.heap(), str_to_spread.substring(i, 1)));
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())
value.as_function().set_home_object(object);
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);
if (property.type() == ObjectProperty::Type::Getter || property.type() == ObjectProperty::Type::Setter) {
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: 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
object->define_accessor(PropertyName::from_value(global_object, key), value.as_function(), property.type() == ObjectProperty::Type::Getter, Attribute::Configurable | Attribute::Enumerable);
LibJS: Add Object::define_accessor() This is a helper function based on the getter/setter definition logic from ObjectExpression::execute() to look up an Accessor property if it already exists, define a new Accessor property if it doesn't exist, and set the getter or setter function on the Accessor.
2020-06-13 21:23:33 -05: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
} else {
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
object->define_property(PropertyName::from_value(global_object, key), value);
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07: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: 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: 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("%{}(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
{
if (!is_computed()) {
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(is<Identifier>(*m_property));
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return static_cast<const Identifier&>(*m_property).string();
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: 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: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
object_string = static_cast<const Identifier&>(*m_object).string();
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);
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(is<Identifier>(*m_property));
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
return String::formatted("{}.{}", object_string, static_cast<const 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: 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: 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
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* object_result = object_value.to_object(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 validity of computed_property_name() result before using it This fixes two cases obj[expr] and obj[expr]() (MemberExpression and CallExpression respectively) when expr throws an exception and results in an empty value, causing a crash by passing the invalid PropertyName created by computed_property_name() to Object::get() without checking it first. Fixes #3459.
2020-09-12 10:22:36 +01:00
auto property_name = computed_property_name(interpreter, global_object);
if (!property_name.is_valid())
return {};
return object_result->get(property_name).value_or(js_undefined());
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 '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: Remove js_bigint(Interpreter&, ...)
2020-09-27 20:00:38 +02:00
return js_bigint(interpreter.heap(), Crypto::SignedBigInteger::from_base10(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: 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(), content(), 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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
return RegExpObject::create(global_object, content(), 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: Remove some more use of Interpreter::global_object() Let's do some more work towards supporting multiple global objects.
2020-06-20 12:47:19 +02:00
auto* array = Array::create(global_object);
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) {
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
array->indexed_properties().append(iterator_value);
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
}
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
array->indexed_properties().append(value);
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: Remove some more use of Interpreter::global_object() Let's do some more work towards supporting multiple global objects.
2020-06-20 12:47:19 +02:00
auto* strings = Array::create(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
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: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 20:57:54 +02:00
auto* raw_strings = Array::create(global_object);
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: 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
strings->define_property(vm.names.raw, raw_strings, 0);
return 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: 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
if (m_parameter.is_null())
outln("CatchClause");
else
outln("CatchClause ({})", m_parameter);
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;
parameters.set(m_handler->parameter(), Variable { exception->value(), DeclarationKind::Var });
auto* catch_scope = interpreter.heap().allocate<LexicalEnvironment>(global_object, move(parameters), interpreter.vm().call_frame().scope);
TemporaryChange<ScopeObject*> scope_change(interpreter.vm().call_frame().scope, catch_scope);
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
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: 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 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
result = m_finalizer->execute(interpreter, global_object);
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 we previously had an exception and the finalizer didn't
// throw a new one, restore the old one.
// FIXME: This will print debug output in throw_exception() for
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
// a second time with m_should_log_exceptions enabled.
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 (previous_exception && !interpreter.exception())
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(previous_exception);
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: 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
return result;
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;
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: 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
if (!strict_eq(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: Handle return value in switch statement unwinding Fixes #3790.
2020-10-18 17:44:55 +01:00
auto last_value = statement.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: 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.
return {};
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 "break" actually work inside "switch"
2020-04-05 00:09:48 +02:00
return {};
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: 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: 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)
{
m_variables.append(move(variables));
}
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)
{
m_functions.append(move(functions));
}
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