beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 07:30:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Userland/Libraries/LibJS/AST.h

1592 lines
47 KiB
C
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
/*
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
Everywhere: Use linusg@serenityos.org for my copyright headers
2021-04-22 20:51:19 +00:00
* Copyright (c) 2020, Linus Groh <linusg@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
*/
#pragma once
LibJS: Implement "else" parsing We can now handle scripts with if/else in LibJS. Most of the changes are about fixing IfStatement to store the consequent and alternate node as Statements. Interpreter now also runs Statements, rather than running ScopeNodes.
2020-03-23 15:46:41 +00:00
#include <AK/FlyString.h>
LibJS: Parse object expressions
2020-03-21 00:29:00 +00:00
#include <AK/HashMap.h>
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
#include <AK/NonnullRefPtrVector.h>
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
#include <AK/OwnPtr.h>
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
#include <AK/RefPtr.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
#include <AK/String.h>
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
#include <AK/Variant.h>
LibJS: Allow functions to take arguments (#1405)
2020-03-12 11:22:13 +00:00
#include <AK/Vector.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
#include <LibJS/Forward.h>
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 15:08:23 +00:00
#include <LibJS/Runtime/PropertyName.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 13:20:30 +00:00
#include <LibJS/Runtime/Value.h>
LibJS: 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 17:15:22 +00:00
#include <LibJS/SourceRange.h>
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 14:34:37 +00:00
#include <LibRegex/Regex.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
namespace JS {
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 14:42:54 +00:00
class VariableDeclaration;
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 12:48:36 +00:00
class FunctionDeclaration;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
class Identifier;
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 14:42:54 +00:00
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-10 23:08:05 +00:00
enum class FunctionKind {
Generator,
Regular,
};
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
template<class T, class... Args>
static inline NonnullRefPtr<T>
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 17:15:22 +00:00
create_ast_node(SourceRange range, Args&&... args)
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
{
AK: Rename adopt() to adopt_ref() This makes it more symmetrical with adopt_own() (which is used to create a NonnullOwnPtr from the result of a naked new.)
2021-04-23 14:46:57 +00:00
return adopt_ref(*new T(range, forward<Args>(args)...));
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
}
class ASTNode : public RefCounted<ASTNode> {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
LibJS: run clang-format on all the files
2020-05-04 11:30:40 +00:00
virtual ~ASTNode() { }
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const = 0;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) 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 18:42:11 +00:00
virtual void dump(int indent) const;
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
SourceRange const& source_range() const { return m_source_range; }
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 17:15:22 +00:00
SourceRange& source_range() { return m_source_range; }
LibJS: Replace ASTNode::class_name() with RTTI This is only used for debugging anyway, so performance doesn't matter too much.
2021-01-17 08:21:15 +00:00
String class_name() const;
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
template<typename T>
bool fast_is() const = delete;
virtual bool is_new_expression() const { return false; }
virtual bool is_member_expression() const { return false; }
virtual bool is_super_expression() const { return false; }
virtual bool is_expression_statement() const { return false; }
virtual bool is_identifier() const { return false; }
virtual bool is_scope_node() const { return false; }
virtual bool is_program() const { return false; }
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
protected:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit ASTNode(SourceRange source_range)
: m_source_range(source_range)
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 17:15:22 +00: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 18:42:11 +00:00
private:
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 17:15:22 +00:00
SourceRange m_source_range;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
};
LibJS: 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 18:27:43 +00:00
class Statement : public ASTNode {
LibJS: Parse labelled statements All statements now have an optional label string that can be null.
2020-05-28 18:09:19 +00:00
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit Statement(SourceRange source_range)
: ASTNode(source_range)
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 17:15:22 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
FlyString const& label() const { return m_label; }
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
void set_label(FlyString string) { m_label = move(string); }
LibJS: Parse labelled statements All statements now have an optional label string that can be null.
2020-05-28 18:09:19 +00:00
protected:
FlyString m_label;
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 18:27:43 +00:00
};
LibJS: Support empty statements We already skipped random semicolons in Parser::parse_program(), but now they are properly matched and parsed as empty statements - and thus recognized as a valid body of an if / else / while / ... statement.
2020-05-03 09:59:00 +00:00
class EmptyStatement final : public Statement {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit EmptyStatement(SourceRange source_range)
: Statement(source_range)
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 17:15:22 +00: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 08:12:34 +00:00
Value execute(Interpreter&, GlobalObject&) const override { return {}; }
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Support empty statements We already skipped random semicolons in Parser::parse_program(), but now they are properly matched and parsed as empty statements - and thus recognized as a valid body of an if / else / while / ... statement.
2020-05-03 09:59:00 +00: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 18:27:43 +00:00
class ErrorStatement final : public Statement {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit ErrorStatement(SourceRange source_range)
: Statement(source_range)
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 17:15:22 +00: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 08:12:34 +00:00
Value execute(Interpreter&, GlobalObject&) const override { return {}; }
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 18:27:43 +00:00
};
class ExpressionStatement final : public Statement {
public:
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 17:15:22 +00:00
ExpressionStatement(SourceRange source_range, NonnullRefPtr<Expression> expression)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_expression(move(expression))
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 18:27:43 +00:00
{
}
LibJS: Fix "use strict" directive false positives By having the "is this a use strict directive?" logic in parse_string_literal() we would apply it to *any* string literal, which is incorrect and would lead to false positives - e.g.: "use strict" + 1 `"use strict"` "\123"; ({"use strict": ...}) Relevant part from the spec which is now implemented properly: [...] and where each ExpressionStatement in the sequence consists entirely of a StringLiteral token [...] I also got rid of UseStrictDirectiveState which is not needed anymore. Fixes #3903.
2020-11-01 21:49:25 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 18:27:43 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Fix "use strict" directive false positives By having the "is this a use strict directive?" logic in parse_string_literal() we would apply it to *any* string literal, which is incorrect and would lead to false positives - e.g.: "use strict" + 1 `"use strict"` "\123"; ({"use strict": ...}) Relevant part from the spec which is now implemented properly: [...] and where each ExpressionStatement in the sequence consists entirely of a StringLiteral token [...] I also got rid of UseStrictDirectiveState which is not needed anymore. Fixes #3903.
2020-11-01 21:49:25 +00:00
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& expression() const { return m_expression; };
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 18:27:43 +00:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
virtual bool is_expression_statement() const override { return true; }
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtr<Expression> m_expression;
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 18:27:43 +00:00
};
class ScopeNode : public Statement {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
template<typename T, typename... Args>
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 17:15:22 +00:00
T& append(SourceRange range, Args&&... args)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
{
LibJS: 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 17:15:22 +00:00
auto child = create_ast_node<T>(range, forward<Args>(args)...);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
m_children.append(move(child));
return static_cast<T&>(m_children.last());
}
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
void append(NonnullRefPtr<Statement> child)
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 18:27:43 +00:00
{
m_children.append(move(child));
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
NonnullRefPtrVector<Statement> const& children() const { return m_children; }
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 14:42:54 +00:00
void add_variables(NonnullRefPtrVector<VariableDeclaration>);
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 12:48:36 +00:00
void add_functions(NonnullRefPtrVector<FunctionDeclaration>);
LibJS: Don't hoist functions under certain circumstances When a lexical declaration with the same name as a function exists, the function is not hoisted (annex B).
2021-07-05 19:45:34 +00:00
void add_hoisted_function(NonnullRefPtr<FunctionDeclaration>);
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
NonnullRefPtrVector<VariableDeclaration> const& variables() const { return m_variables; }
NonnullRefPtrVector<FunctionDeclaration> const& functions() const { return m_functions; }
LibJS: Improve function hoisting across blocks The parser now keeps track of a scope chain so that it can hoist function declarations to the closest function scope.
2021-07-04 01:15:52 +00:00
NonnullRefPtrVector<FunctionDeclaration> const& hoisted_functions() const { return m_hoisted_functions; }
LibJS: Add strict mode Adds the ability for a scope (either a function or the entire program) to be in strict mode. Scopes default to non-strict mode. There are two ways to determine the strict-ness of the JS engine: 1. In the parser, this can be accessed with the parser_state variable m_is_strict_mode boolean. If true, the Parser is currently parsing in strict mode. This is done so that the Parser can generate syntax errors at parse time, which is required in some cases. 2. With Interpreter.is_strict_mode(). This allows strict mode checking at runtime as opposed to compile time. Additionally, in order to test this, a global isStrictMode() function has been added to the JS ReplObject under the test-mode flag.
2020-05-28 05:22:08 +00: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 18:42:11 +00:00
protected:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit ScopeNode(SourceRange source_range)
: Statement(source_range)
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 17:15:22 +00: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 18:42:11 +00:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
virtual bool is_scope_node() const final { return true; }
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtrVector<Statement> m_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 14:42:54 +00:00
NonnullRefPtrVector<VariableDeclaration> m_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 12:48:36 +00:00
NonnullRefPtrVector<FunctionDeclaration> m_functions;
LibJS: Improve function hoisting across blocks The parser now keeps track of a scope chain so that it can hoist function declarations to the closest function scope.
2021-07-04 01:15:52 +00:00
NonnullRefPtrVector<FunctionDeclaration> m_hoisted_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 18:42:11 +00:00
};
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 15:42:30 +00:00
class ImportStatement final : public Statement {
public:
struct ImportEntry {
String import_name;
String local_name;
};
explicit ImportStatement(SourceRange source_range, StringView from_module, Vector<ImportEntry> entries = {})
: Statement(source_range)
, m_module_request(from_module)
, m_entries(move(entries))
{
}
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
bool has_bound_name(StringView name) const;
private:
String m_module_request;
Vector<ImportEntry> m_entries;
};
class ExportStatement final : public Statement {
public:
struct ExportEntry {
enum Kind {
ModuleRequest,
LocalExport
} kind;
// Can always have
String export_name;
// Only if module request
String module_request;
// Has just one of ones below
String local_or_import_name;
ExportEntry(String export_name, String local_name)
: kind(LocalExport)
, export_name(export_name)
, local_or_import_name(local_name)
{
}
};
explicit ExportStatement(SourceRange source_range, RefPtr<ASTNode> statement, Vector<ExportEntry> entries)
: Statement(source_range)
, m_statement(move(statement))
, m_entries(move(entries))
{
}
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
bool has_export(StringView export_name) const;
private:
RefPtr<ASTNode> m_statement;
Vector<ExportEntry> m_entries;
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class Program final : public ScopeNode {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 15:30:37 +00:00
enum class Type {
Script,
Module
};
explicit Program(SourceRange source_range, Type program_type)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: ScopeNode(source_range)
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 15:30:37 +00:00
, m_type(program_type)
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 17:15:22 +00: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 18:42:11 +00: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-04 00:02:43 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
bool is_strict_mode() const { return m_is_strict_mode; }
void set_strict_mode() { m_is_strict_mode = true; }
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 15:30:37 +00:00
Type type() const { return m_type; }
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 15:42:30 +00:00
void append_import(NonnullRefPtr<ImportStatement> import_statement)
{
m_imports.append(import_statement);
append(import_statement);
}
void append_export(NonnullRefPtr<ExportStatement> export_statement)
{
m_exports.append(export_statement);
append(export_statement);
}
NonnullRefPtrVector<ImportStatement> const& imports() const { return m_imports; }
NonnullRefPtrVector<ExportStatement> const& exports() const { return m_exports; }
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
virtual bool is_program() const override { return true; }
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-04 00:02:43 +00:00
bool m_is_strict_mode { false };
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 15:30:37 +00:00
Type m_type { Type::Script };
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 15:42:30 +00:00
NonnullRefPtrVector<ImportStatement> m_imports;
NonnullRefPtrVector<ExportStatement> m_exports;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class BlockStatement final : public ScopeNode {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit BlockStatement(SourceRange source_range)
: ScopeNode(source_range)
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 17:15:22 +00: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 18:42:11 +00: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 10:12:08 +00:00
class Expression : public ASTNode {
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 10:10:16 +00:00
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit Expression(SourceRange source_range)
: ASTNode(source_range)
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 17:15:22 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Reference to_reference(Interpreter&, GlobalObject&) 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 10:12:08 +00:00
};
LibJS: Add Declaration class to the AST This is just here to make the AST class hierarchy more spec-like.
2020-04-04 19:32:10 +00:00
class Declaration : public Statement {
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 17:15:22 +00:00
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit Declaration(SourceRange source_range)
: Statement(source_range)
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 17:15:22 +00:00
{
}
LibJS: Add Declaration class to the AST This is just here to make the AST class hierarchy more spec-like.
2020-04-04 19:32:10 +00:00
};
LibJS: Distinguish between statement and declaration This separates matching/parsing of statements and declarations and fixes a few edge cases where the parser would incorrectly accept a declaration where only a statement is allowed - for example: if (foo) const a = 1; for (var bar;;) function b() {} while (baz) class c {}
2020-10-22 22:30:07 +00:00
class ErrorDeclaration final : public Declaration {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit ErrorDeclaration(SourceRange source_range)
: Declaration(source_range)
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 17:15:22 +00: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 08:12:34 +00:00
Value execute(Interpreter&, GlobalObject&) const override { return {}; }
LibJS: Distinguish between statement and declaration This separates matching/parsing of statements and declarations and fixes a few edge cases where the parser would incorrectly accept a declaration where only a statement is allowed - for example: if (foo) const a = 1; for (var bar;;) function b() {} while (baz) class c {}
2020-10-22 22:30:07 +00:00
};
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
struct BindingPattern : RefCounted<BindingPattern> {
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
// This covers both BindingProperty and BindingElement, hence the more generic name
struct BindingEntry {
// If this entry represents a BindingElement, then name will be Empty
Variant<NonnullRefPtr<Identifier>, NonnullRefPtr<Expression>, Empty> name { Empty {} };
Variant<NonnullRefPtr<Identifier>, NonnullRefPtr<BindingPattern>, Empty> alias { Empty {} };
RefPtr<Expression> initializer {};
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
bool is_rest { false };
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
bool is_elision() const { return name.has<Empty>() && alias.has<Empty>(); }
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
};
enum class Kind {
Array,
Object,
};
void dump(int indent) const;
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
template<typename C>
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
void for_each_bound_name(C&& callback) const;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
Vector<BindingEntry> entries;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
Kind kind { Kind::Object };
};
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 10:12:08 +00:00
class FunctionNode {
public:
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 18:46:39 +00:00
struct Parameter {
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
Variant<FlyString, NonnullRefPtr<BindingPattern>> binding;
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 18:46:39 +00:00
RefPtr<Expression> default_value;
LibJS: Implement rest parameters
2020-05-04 15:05:13 +00:00
bool is_rest { false };
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 18:46:39 +00:00
};
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
FlyString const& name() const { return m_name; }
Statement const& body() const { return *m_body; }
Vector<Parameter> const& parameters() const { return m_parameters; };
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 12:48:36 +00:00
i32 function_length() const { return m_function_length; }
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-04 00:02:43 +00:00
bool is_strict_mode() const { return m_is_strict_mode; }
LibJS: Move is_arrow_function() from FunctionExpression to FunctionNode This will make it easier to write bytecode generation for function expressions in just a moment.
2021-06-11 08:45:49 +00:00
bool is_arrow_function() const { return m_is_arrow_function; }
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-10 23:08:05 +00:00
FunctionKind kind() const { return m_kind; }
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 10:12:08 +00:00
protected:
LibJS: Remove variables from FunctionNode They weren't consumed anywhere outside the AST and went against the usual concept of having declaration in ScopeNode.
2021-07-04 01:12:27 +00:00
FunctionNode(FlyString name, NonnullRefPtr<Statement> body, Vector<Parameter> parameters, i32 function_length, FunctionKind kind, bool is_strict_mode, bool is_arrow_function)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: m_name(move(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 18:42:11 +00:00
, m_body(move(body))
LibJS: Allow functions to take arguments (#1405)
2020-03-12 11:22:13 +00:00
, m_parameters(move(parameters))
LibJS: Function.length respects default and rest parameters "[Function.length is] the number of formal parameters. This number excludes the rest parameter and only includes parameters before the first one with a default value." - MDN
2020-05-06 03:02:14 +00:00
, m_function_length(function_length)
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-10 23:08:05 +00:00
, m_kind(kind)
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-04 00:02:43 +00:00
, m_is_strict_mode(is_strict_mode)
LibJS: Move is_arrow_function() from FunctionExpression to FunctionNode This will make it easier to write bytecode generation for function expressions in just a moment.
2021-06-11 08:45:49 +00:00
, m_is_arrow_function(is_arrow_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 18:42:11 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
void dump(int indent, String const& class_name) 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 10:12:08 +00:00
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 11:44:07 +00:00
protected:
void set_name(FlyString name)
{
VERIFY(m_name.is_empty());
m_name = move(name);
}
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 10:12:08 +00:00
private:
LibJS: Use FlyString for identifiers This makes variable and property lookups a lot faster since comparing two FlyStrings is O(1).
2020-03-22 10:07:55 +00:00
FlyString m_name;
AK: Stop allowing implicit downcast with RefPtr and NonnullRefPtr We were allowing this dangerous kind of thing: RefPtr<Base> base; RefPtr<Derived> derived = base; This patch changes the {Nonnull,}RefPtr constructors so this is no longer possible. To downcast one of these pointers, there is now static_ptr_cast<T>: RefPtr<Derived> derived = static_ptr_cast<Derived>(base); Fixing this exposed a ton of cowboy-downcasts in various places, which we're now forced to fix. :^)
2020-04-05 09:11:07 +00:00
NonnullRefPtr<Statement> m_body;
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Vector<Parameter> const m_parameters;
LibJS: Function.length respects default and rest parameters "[Function.length is] the number of formal parameters. This number excludes the rest parameter and only includes parameters before the first one with a default value." - MDN
2020-05-06 03:02:14 +00:00
const i32 m_function_length;
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-10 23:08:05 +00:00
FunctionKind m_kind;
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-04 00:02:43 +00:00
bool m_is_strict_mode;
LibJS: Move is_arrow_function() from FunctionExpression to FunctionNode This will make it easier to write bytecode generation for function expressions in just a moment.
2021-06-11 08:45:49 +00:00
bool m_is_arrow_function { false };
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 10:12:08 +00:00
};
class FunctionDeclaration final
LibJS: Add Declaration class to the AST This is just here to make the AST class hierarchy more spec-like.
2020-04-04 19:32:10 +00:00
: public Declaration
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 10:12:08 +00:00
, public FunctionNode {
public:
LibJS: Parse FunctionExpressions FunctionExpression is mostly like FunctionDeclaration, except the name is optional. Share the parsing logic in parse_function_node<NodeType>. This allows us to do nice things like: document.addEventListener("DOMContentLoaded", function() { alert("Hello friends!"); });
2020-03-19 10:52:56 +00:00
static bool must_have_name() { return true; }
LibJS: Remove variables from FunctionNode They weren't consumed anywhere outside the AST and went against the usual concept of having declaration in ScopeNode.
2021-07-04 01:12:27 +00:00
FunctionDeclaration(SourceRange source_range, FlyString const& name, NonnullRefPtr<Statement> body, Vector<Parameter> parameters, i32 function_length, FunctionKind kind, bool is_strict_mode = false)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Declaration(source_range)
LibJS: Remove variables from FunctionNode They weren't consumed anywhere outside the AST and went against the usual concept of having declaration in ScopeNode.
2021-07-04 01:12:27 +00:00
, FunctionNode(name, move(body), move(parameters), function_length, kind, is_strict_mode, false)
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 10:12:08 +00: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 18:42:11 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
};
LibJS: Fix style inconsistencies in AST.h (#2403) Our current configuration clang-format allows both of these styles: ------------------ class A : B , C { ----------------- class A : B , C { ------------------ I was not able to find a setting of clang-format to only allow the latter style (or disallow the first style), but let's at least be consistent with the style within a file.
2020-05-26 17:52:03 +00:00
class FunctionExpression final
: public Expression
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 10:12:08 +00:00
, public FunctionNode {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
LibJS: Parse FunctionExpressions FunctionExpression is mostly like FunctionDeclaration, except the name is optional. Share the parsing logic in parse_function_node<NodeType>. This allows us to do nice things like: document.addEventListener("DOMContentLoaded", function() { alert("Hello friends!"); });
2020-03-19 10:52:56 +00:00
static bool must_have_name() { return false; }
LibJS: Remove variables from FunctionNode They weren't consumed anywhere outside the AST and went against the usual concept of having declaration in ScopeNode.
2021-07-04 01:12:27 +00:00
FunctionExpression(SourceRange source_range, FlyString const& name, NonnullRefPtr<Statement> body, Vector<Parameter> parameters, i32 function_length, FunctionKind kind, bool is_strict_mode, bool is_arrow_function = false)
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 11:44:07 +00:00
: Expression(source_range)
LibJS: Remove variables from FunctionNode They weren't consumed anywhere outside the AST and went against the usual concept of having declaration in ScopeNode.
2021-07-04 01:12:27 +00:00
, FunctionNode(name, move(body), move(parameters), function_length, kind, is_strict_mode, 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 10:12:08 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 10:12:08 +00:00
virtual void dump(int indent) const override;
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 11:44:07 +00:00
void set_name_if_possible(FlyString new_name)
{
if (m_cannot_auto_rename)
return;
m_cannot_auto_rename = true;
LibJS: Make FunctionExpression more spec-compliant
2021-07-07 20:53:32 +00:00
if (name().is_empty()) {
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 11:44:07 +00:00
set_name(move(new_name));
LibJS: Make FunctionExpression more spec-compliant
2021-07-07 20:53:32 +00:00
m_is_auto_renamed = true;
}
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 11:44:07 +00:00
}
bool cannot_auto_rename() const { return m_cannot_auto_rename; }
LibJS: Make FunctionExpression more spec-compliant
2021-07-07 20:53:32 +00:00
bool is_auto_renamed() const { return m_is_auto_renamed; }
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 11:44:07 +00:00
void set_cannot_auto_rename() { m_cannot_auto_rename = true; }
LibJS: Add bytecode generation for FunctionExpression :^)
2021-06-11 08:46:46 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 10:12:08 +00:00
private:
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 11:44:07 +00:00
bool m_cannot_auto_rename { false };
LibJS: Make FunctionExpression more spec-compliant
2021-07-07 20:53:32 +00:00
bool m_is_auto_renamed { false };
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00: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 18:27:43 +00:00
class ErrorExpression final : public Expression {
public:
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 17:15:22 +00:00
explicit ErrorExpression(SourceRange source_range)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00: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 08:12:34 +00:00
Value execute(Interpreter&, GlobalObject&) const override { return {}; }
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 18:27:43 +00:00
};
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
class YieldExpression final : public Expression {
public:
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 11:16:41 +00:00
explicit YieldExpression(SourceRange source_range, RefPtr<Expression> argument, bool is_yield_from)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
, m_argument(move(argument))
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 11:16:41 +00:00
, m_is_yield_from(is_yield_from)
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const* argument() const { return m_argument; }
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 11:16:41 +00:00
bool is_yield_from() const { return m_is_yield_from; }
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
virtual void generate_bytecode(Bytecode::Generator&) const override;
private:
RefPtr<Expression> m_argument;
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 11:16:41 +00:00
bool m_is_yield_from { false };
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class ReturnStatement final : public Statement {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
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 17:15:22 +00:00
explicit ReturnStatement(SourceRange source_range, RefPtr<Expression> argument)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_argument(move(argument))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const* argument() const { return m_argument; }
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
private:
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
RefPtr<Expression> m_argument;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class IfStatement final : public Statement {
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 05:58:58 +00:00
public:
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 17:15:22 +00:00
IfStatement(SourceRange source_range, NonnullRefPtr<Expression> predicate, NonnullRefPtr<Statement> consequent, RefPtr<Statement> alternate)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_predicate(move(predicate))
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 05:58:58 +00:00
, m_consequent(move(consequent))
, m_alternate(move(alternate))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& predicate() const { return *m_predicate; }
Statement const& consequent() const { return *m_consequent; }
Statement const* alternate() const { return m_alternate; }
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 05:58:58 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 05:58:58 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 05:58:58 +00:00
private:
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtr<Expression> m_predicate;
LibJS: Implement "else" parsing We can now handle scripts with if/else in LibJS. Most of the changes are about fixing IfStatement to store the consequent and alternate node as Statements. Interpreter now also runs Statements, rather than running ScopeNodes.
2020-03-23 15:46:41 +00:00
NonnullRefPtr<Statement> m_consequent;
RefPtr<Statement> m_alternate;
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 05:58:58 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class WhileStatement final : public Statement {
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
public:
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 17:15:22 +00:00
WhileStatement(SourceRange source_range, NonnullRefPtr<Expression> test, NonnullRefPtr<Statement> body)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_test(move(test))
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& test() const { return *m_test; }
Statement const& body() const { return *m_body; }
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
private:
LibJS: Rename WhileStatement::predicate() => body() This name matches other parsers.
2020-04-04 19:21:19 +00:00
NonnullRefPtr<Expression> m_test;
AK: Stop allowing implicit downcast with RefPtr and NonnullRefPtr We were allowing this dangerous kind of thing: RefPtr<Base> base; RefPtr<Derived> derived = base; This patch changes the {Nonnull,}RefPtr constructors so this is no longer possible. To downcast one of these pointers, there is now static_ptr_cast<T>: RefPtr<Derived> derived = static_ptr_cast<Derived>(base); Fixing this exposed a ton of cowboy-downcasts in various places, which we're now forced to fix. :^)
2020-04-05 09:11:07 +00:00
NonnullRefPtr<Statement> m_body;
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class DoWhileStatement final : public Statement {
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
public:
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 17:15:22 +00:00
DoWhileStatement(SourceRange source_range, NonnullRefPtr<Expression> test, NonnullRefPtr<Statement> body)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_test(move(test))
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& test() const { return *m_test; }
Statement const& body() const { return *m_body; }
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
private:
NonnullRefPtr<Expression> m_test;
AK: Stop allowing implicit downcast with RefPtr and NonnullRefPtr We were allowing this dangerous kind of thing: RefPtr<Base> base; RefPtr<Derived> derived = base; This patch changes the {Nonnull,}RefPtr constructors so this is no longer possible. To downcast one of these pointers, there is now static_ptr_cast<T>: RefPtr<Derived> derived = static_ptr_cast<Derived>(base); Fixing this exposed a ton of cowboy-downcasts in various places, which we're now forced to fix. :^)
2020-04-05 09:11:07 +00:00
NonnullRefPtr<Statement> m_body;
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
};
LibJS: Parse "with" statements :^)
2020-11-28 14:05:57 +00:00
class WithStatement final : public Statement {
public:
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 17:15:22 +00:00
WithStatement(SourceRange source_range, NonnullRefPtr<Expression> object, NonnullRefPtr<Statement> body)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_object(move(object))
LibJS: Parse "with" statements :^)
2020-11-28 14:05:57 +00:00
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& object() const { return *m_object; }
Statement const& body() const { return *m_body; }
LibJS: Parse "with" statements :^)
2020-11-28 14:05:57 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
private:
NonnullRefPtr<Expression> m_object;
NonnullRefPtr<Statement> m_body;
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class ForStatement final : public Statement {
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
public:
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 17:15:22 +00:00
ForStatement(SourceRange source_range, RefPtr<ASTNode> init, RefPtr<Expression> test, RefPtr<Expression> update, NonnullRefPtr<Statement> body)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_init(move(init))
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
, m_test(move(test))
, m_update(move(update))
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
ASTNode const* init() const { return m_init; }
Expression const* test() const { return m_test; }
Expression const* update() const { return m_update; }
Statement const& body() const { return *m_body; }
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
private:
LibJS: Consume semicolon at the end of a statement A bunch of code was relying on this not happenind, in particular the parsing of "for" statements. Reorganized things so they work again.
2020-03-23 18:08:32 +00:00
RefPtr<ASTNode> m_init;
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
RefPtr<Expression> m_test;
RefPtr<Expression> m_update;
AK: Stop allowing implicit downcast with RefPtr and NonnullRefPtr We were allowing this dangerous kind of thing: RefPtr<Base> base; RefPtr<Derived> derived = base; This patch changes the {Nonnull,}RefPtr constructors so this is no longer possible. To downcast one of these pointers, there is now static_ptr_cast<T>: RefPtr<Derived> derived = static_ptr_cast<Derived>(base); Fixing this exposed a ton of cowboy-downcasts in various places, which we're now forced to fix. :^)
2020-04-05 09:11:07 +00:00
NonnullRefPtr<Statement> m_body;
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class ForInStatement final : public Statement {
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
public:
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 17:15:22 +00:00
ForInStatement(SourceRange source_range, NonnullRefPtr<ASTNode> lhs, NonnullRefPtr<Expression> rhs, NonnullRefPtr<Statement> body)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_lhs(move(lhs))
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
, m_rhs(move(rhs))
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
ASTNode const& lhs() const { return *m_lhs; }
Expression const& rhs() const { return *m_rhs; }
Statement const& body() const { return *m_body; }
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
virtual void dump(int indent) const override;
private:
NonnullRefPtr<ASTNode> m_lhs;
NonnullRefPtr<Expression> m_rhs;
NonnullRefPtr<Statement> m_body;
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class ForOfStatement final : public Statement {
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
public:
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 17:15:22 +00:00
ForOfStatement(SourceRange source_range, NonnullRefPtr<ASTNode> lhs, NonnullRefPtr<Expression> rhs, NonnullRefPtr<Statement> body)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_lhs(move(lhs))
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
, m_rhs(move(rhs))
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
ASTNode const& lhs() const { return *m_lhs; }
Expression const& rhs() const { return *m_rhs; }
Statement const& body() const { return *m_body; }
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
virtual void dump(int indent) const override;
private:
NonnullRefPtr<ASTNode> m_lhs;
NonnullRefPtr<Expression> m_rhs;
NonnullRefPtr<Statement> m_body;
};
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
enum class BinaryOp {
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 11:56:53 +00:00
Addition,
Subtraction,
Multiplication,
Division,
LibJS: Add basic support for modulo (%) in binary expressions
2020-04-04 19:17:34 +00:00
Modulo,
LibJS: Implement exponentiation (** operator)
2020-04-05 12:40:00 +00:00
Exponentiation,
LibJS: Add typed comparison operator The `===` operator allows us to compare two values while taking their type into consideration.
2020-03-08 05:53:02 +00:00
TypedEquals,
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 21:27:18 +00:00
TypedInequals,
LibJS: Implement abstract equality and inequality
2020-03-15 22:23:38 +00:00
AbstractEquals,
AbstractInequals,
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 10:35:05 +00:00
GreaterThan,
LibJS: Implement <= and >= binary operators
2020-03-12 12:07:08 +00:00
GreaterThanEquals,
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 10:35:05 +00:00
LessThan,
LibJS: Implement <= and >= binary operators
2020-03-12 12:07:08 +00:00
LessThanEquals,
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 10:35:05 +00:00
BitwiseAnd,
BitwiseOr,
BitwiseXor,
LeftShift,
RightShift,
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 14:43:10 +00:00
UnsignedRightShift,
LibJS: Implement 'in' operator
2020-04-23 15:06:01 +00:00
In,
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 15:56:54 +00:00
InstanceOf,
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class BinaryExpression final : public Expression {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
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 17:15:22 +00:00
BinaryExpression(SourceRange source_range, BinaryOp op, NonnullRefPtr<Expression> lhs, NonnullRefPtr<Expression> rhs)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_op(op)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
private:
BinaryOp m_op;
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtr<Expression> m_lhs;
NonnullRefPtr<Expression> m_rhs;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
};
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 05:55:44 +00:00
enum class LogicalOp {
And,
Or,
LibJS: Implement nullish coalescing operator (??)
2020-04-17 23:49:11 +00:00
NullishCoalescing,
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 05:55:44 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class LogicalExpression final : public Expression {
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 05:55:44 +00:00
public:
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 17:15:22 +00:00
LogicalExpression(SourceRange source_range, LogicalOp op, NonnullRefPtr<Expression> lhs, NonnullRefPtr<Expression> rhs)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_op(op)
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 05:55:44 +00:00
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 05:55:44 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 05:55:44 +00:00
private:
LogicalOp m_op;
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtr<Expression> m_lhs;
NonnullRefPtr<Expression> m_rhs;
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 05:55:44 +00:00
};
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 21:27:18 +00:00
enum class UnaryOp {
LibJS: Rename BitNot -> BitwiseNot to match other bitwise operators
2020-03-14 18:43:35 +00:00
BitwiseNot,
LibJS: Move logical not operator to new unary expression class
2020-03-09 17:04:44 +00:00
Not,
LibJS: Implement unary plus / minus
2020-04-02 16:58:39 +00:00
Plus,
Minus,
LibJS: Implement typeof operator
2020-03-17 19:33:32 +00:00
Typeof,
LibJS: Implement void operator
2020-04-15 16:55:03 +00:00
Void,
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 11:53:40 +00:00
Delete,
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 21:27:18 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class UnaryExpression final : public Expression {
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 21:27:18 +00:00
public:
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 17:15:22 +00:00
UnaryExpression(SourceRange source_range, UnaryOp op, NonnullRefPtr<Expression> lhs)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_op(op)
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 21:27:18 +00:00
, m_lhs(move(lhs))
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 21:27:18 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 21:27:18 +00:00
private:
UnaryOp m_op;
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtr<Expression> m_lhs;
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 21:27:18 +00: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 13:11:05 +00:00
class SequenceExpression final : public Expression {
public:
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 17:15:22 +00:00
SequenceExpression(SourceRange source_range, NonnullRefPtrVector<Expression> expressions)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_expressions(move(expressions))
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 13:11:05 +00:00
{
LibJS: Ensure SequenceExpression has two or more expressions Just a sanity check, as we should be able to make this assumption elsewhere - this way we can catch silly mistakes early.
2021-03-16 21:03:31 +00:00
VERIFY(m_expressions.size() >= 2);
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 13:11:05 +00:00
}
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 13:11:05 +00:00
private:
NonnullRefPtrVector<Expression> m_expressions;
};
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
class Literal : public Expression {
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 11:19:11 +00:00
protected:
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 17:15:22 +00:00
explicit Literal(SourceRange source_range)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00: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 11:19:11 +00:00
};
class BooleanLiteral final : public Literal {
public:
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 17:15:22 +00:00
explicit BooleanLiteral(SourceRange source_range, bool value)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Literal(source_range)
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 17:15:22 +00:00
, m_value(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 11:19:11 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 11:19:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 11:19:11 +00:00
private:
bool m_value { false };
};
class NumericLiteral final : public Literal {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
public:
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 17:15:22 +00:00
explicit NumericLiteral(SourceRange source_range, double value)
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 17:03:00 +00:00
: Literal(source_range)
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 17:15:22 +00:00
, m_value(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 11:19:11 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 11:19:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 11:19:11 +00:00
private:
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 17:03:00 +00:00
Value 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 11:19:11 +00:00
};
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
class BigIntLiteral final : public Literal {
public:
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 17:15:22 +00:00
explicit BigIntLiteral(SourceRange source_range, String value)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Literal(source_range)
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 17:15:22 +00:00
, m_value(move(value))
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Add BigInt
2020-06-06 00:14:10 +00:00
private:
String 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 11:19:11 +00:00
class StringLiteral final : public Literal {
public:
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 17:15:22 +00:00
explicit StringLiteral(SourceRange source_range, String value, bool is_use_strict_directive = false)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Literal(source_range)
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 17:15:22 +00:00
, m_value(move(value))
LibJS: Fix "use strict" directive false positives By having the "is this a use strict directive?" logic in parse_string_literal() we would apply it to *any* string literal, which is incorrect and would lead to false positives - e.g.: "use strict" + 1 `"use strict"` "\123"; ({"use strict": ...}) Relevant part from the spec which is now implemented properly: [...] and where each ExpressionStatement in the sequence consists entirely of a StringLiteral token [...] I also got rid of UseStrictDirectiveState which is not needed anymore. Fixes #3903.
2020-11-01 21:49:25 +00:00
, m_is_use_strict_directive(is_use_strict_directive)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Fix "use strict" directive false positives By having the "is this a use strict directive?" logic in parse_string_literal() we would apply it to *any* string literal, which is incorrect and would lead to false positives - e.g.: "use strict" + 1 `"use strict"` "\123"; ({"use strict": ...}) Relevant part from the spec which is now implemented properly: [...] and where each ExpressionStatement in the sequence consists entirely of a StringLiteral token [...] I also got rid of UseStrictDirectiveState which is not needed anymore. Fixes #3903.
2020-11-01 21:49:25 +00:00
StringView value() const { return m_value; }
bool is_use_strict_directive() const { return m_is_use_strict_directive; };
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
private:
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 11:19:11 +00:00
String m_value;
LibJS: Fix "use strict" directive false positives By having the "is this a use strict directive?" logic in parse_string_literal() we would apply it to *any* string literal, which is incorrect and would lead to false positives - e.g.: "use strict" + 1 `"use strict"` "\123"; ({"use strict": ...}) Relevant part from the spec which is now implemented properly: [...] and where each ExpressionStatement in the sequence consists entirely of a StringLiteral token [...] I also got rid of UseStrictDirectiveState which is not needed anymore. Fixes #3903.
2020-11-01 21:49:25 +00:00
bool m_is_use_strict_directive;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
};
LibJS: Implement null and undefined literals
2020-03-15 21:32:34 +00:00
class NullLiteral final : public Literal {
public:
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 17:15:22 +00:00
explicit NullLiteral(SourceRange source_range)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Literal(source_range)
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 17:15:22 +00:00
{
}
LibJS: Implement null and undefined literals
2020-03-15 21:32:34 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement null and undefined literals
2020-03-15 21:32:34 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Implement null and undefined literals
2020-03-15 21:32:34 +00:00
};
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 23:05:49 +00:00
class RegExpLiteral final : public Literal {
public:
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 14:34:37 +00:00
RegExpLiteral(SourceRange source_range, regex::Parser::Result parsed_regex, String parsed_pattern, regex::RegexOptions<ECMAScriptFlags> parsed_flags, String pattern, String flags)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Literal(source_range)
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 14:34:37 +00:00
, m_parsed_regex(move(parsed_regex))
, m_parsed_pattern(move(parsed_pattern))
, m_parsed_flags(move(parsed_flags))
LibJS: Rename RegExpLiteral m_content to m_pattern This is what we call it elsewhere, let's be consistent.
2021-05-10 10:56:08 +00:00
, m_pattern(move(pattern))
, m_flags(move(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 23:05:49 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 23:05:49 +00:00
virtual void dump(int indent) const override;
LibJS: Add bytecode support for regexp literals
2021-06-20 00:17:40 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 23:05:49 +00:00
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 14:34:37 +00:00
regex::Parser::Result const& parsed_regex() const { return m_parsed_regex; }
String const& parsed_pattern() const { return m_parsed_pattern; }
regex::RegexOptions<ECMAScriptFlags> const& parsed_flags() const { return m_parsed_flags; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
String const& pattern() const { return m_pattern; }
String const& flags() const { return m_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 23:05:49 +00:00
private:
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 14:34:37 +00:00
regex::Parser::Result m_parsed_regex;
String m_parsed_pattern;
regex::RegexOptions<ECMAScriptFlags> m_parsed_flags;
LibJS: Rename RegExpLiteral m_content to m_pattern This is what we call it elsewhere, let's be consistent.
2021-05-10 10:56:08 +00:00
String m_pattern;
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 23:05:49 +00:00
String m_flags;
};
LibJS: Let's say that Identifier is an Expression for now This allows us to tighten typing in various other classes.
2020-03-10 10:48:49 +00:00
class Identifier final : public Expression {
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
public:
LibJS: Remove direct argument loading since it was buggy The parser doesn't always track lexical scopes correctly, so let's not rely on that for direct argument loading. This reverts the LoadArguments bytecode instruction as well. We can bring these things back when the parser can reliably tell us that a given Identifier is indeed a function argument.
2021-06-22 20:20:17 +00:00
explicit Identifier(SourceRange source_range, FlyString string)
LibJS: Track which Identifier nodes refer to function arguments This patch adds an "argument index" field to Identifier AST nodes. If the Identifier refers to a function parameter in the currently open function scope, we stash the index of the parameter here. This will allow us to implement much faster direct access to function argument variables.
2021-06-14 07:30:43 +00:00
: Expression(source_range)
, m_string(move(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 20:13:55 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
FlyString const& string() const { return 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 20:13:55 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Reference to_reference(Interpreter&, GlobalObject&) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
virtual bool is_identifier() const override { return true; }
LibJS: Use FlyString for identifiers This makes variable and property lookups a lot faster since comparing two FlyStrings is O(1).
2020-03-22 10:07:55 +00:00
FlyString 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 20:13:55 +00: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 18:31:21 +00:00
class ClassMethod final : public ASTNode {
public:
enum class Kind {
Method,
Getter,
Setter,
};
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 17:15:22 +00:00
ClassMethod(SourceRange source_range, NonnullRefPtr<Expression> key, NonnullRefPtr<FunctionExpression> function, Kind kind, bool is_static)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: ASTNode(source_range)
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 17:15:22 +00:00
, m_key(move(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 18:31:21 +00:00
, m_function(move(function))
, m_kind(kind)
, m_is_static(is_static)
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& key() const { return *m_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 18:31:21 +00:00
Kind kind() const { return m_kind; }
bool is_static() const { return m_is_static; }
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
private:
NonnullRefPtr<Expression> m_key;
NonnullRefPtr<FunctionExpression> m_function;
Kind m_kind;
bool m_is_static;
};
class SuperExpression final : public Expression {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit SuperExpression(SourceRange source_range)
: Expression(source_range)
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 17:15:22 +00: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 18:31:21 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
virtual bool is_super_expression() const override { return true; }
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 18:31:21 +00:00
};
class ClassExpression final : public Expression {
public:
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 17:15:22 +00:00
ClassExpression(SourceRange source_range, String name, RefPtr<FunctionExpression> constructor, RefPtr<Expression> super_class, NonnullRefPtrVector<ClassMethod> methods)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_name(move(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 18:31:21 +00:00
, m_constructor(move(constructor))
, m_super_class(move(super_class))
, m_methods(move(methods))
{
}
StringView name() const { return m_name; }
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 18:42:13 +00:00
RefPtr<FunctionExpression> constructor() const { return m_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 18:31:21 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
private:
String m_name;
RefPtr<FunctionExpression> m_constructor;
RefPtr<Expression> m_super_class;
NonnullRefPtrVector<ClassMethod> m_methods;
};
class ClassDeclaration final : public Declaration {
public:
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 17:15:22 +00:00
ClassDeclaration(SourceRange source_range, NonnullRefPtr<ClassExpression> class_expression)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Declaration(source_range)
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 17:15:22 +00:00
, m_class_expression(move(class_expression))
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 18:31:21 +00:00
{
}
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 18:42:13 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 18:31:21 +00:00
private:
NonnullRefPtr<ClassExpression> m_class_expression;
};
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-27 06:05:37 +00:00
class SpreadExpression final : public Expression {
public:
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 17:15:22 +00:00
explicit SpreadExpression(SourceRange source_range, NonnullRefPtr<Expression> target)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
, m_target(move(target))
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-27 06:05:37 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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-27 06:05:37 +00:00
virtual void dump(int indent) const override;
private:
NonnullRefPtr<Expression> m_target;
};
LibJS: Parse "this" as ThisExpression
2020-04-12 22:42:14 +00:00
class ThisExpression final : public Expression {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit ThisExpression(SourceRange source_range)
: Expression(source_range)
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 17:15:22 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Parse "this" as ThisExpression
2020-04-12 22:42:14 +00:00
virtual void dump(int indent) const override;
};
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
class CallExpression : public Expression {
public:
LibJS: Add function call spreading Adds support for the following syntax: myFunction(...x, ...[1, 2, 3], ...o.foo, ...'abcd')
2020-05-06 05:36:24 +00:00
struct Argument {
NonnullRefPtr<Expression> value;
bool is_spread;
};
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 17:15:22 +00:00
CallExpression(SourceRange source_range, NonnullRefPtr<Expression> callee, Vector<Argument> arguments = {})
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_callee(move(callee))
LibJS: Allow functions to take arguments (#1405)
2020-03-12 11:22:13 +00:00
, m_arguments(move(arguments))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 16:25:32 +00:00
Expression const& callee() const { return m_callee; }
protected:
void throw_type_error_for_callee(Interpreter&, GlobalObject&, Value callee_value, StringView call_type) const;
LibJS: NewExpression doesn't need compute_this_and_callee() Now that NewExpression is separated from CallExpression, it doesn't have to use the ad-hoc compute_this_and_callee() logic.
2021-07-02 16:43:25 +00:00
NonnullRefPtr<Expression> m_callee;
Vector<Argument> const m_arguments;
private:
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 16:51:27 +00:00
struct ThisAndCallee {
Value this_value;
Value callee;
};
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 16:25:32 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
ThisAndCallee compute_this_and_callee(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 18:42:11 +00:00
};
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 15:33:52 +00:00
class NewExpression final : public CallExpression {
public:
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 17:15:22 +00:00
NewExpression(SourceRange source_range, NonnullRefPtr<Expression> callee, Vector<Argument> arguments = {})
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: CallExpression(source_range, move(callee), move(arguments))
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 15:33:52 +00:00
{
}
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 16:25:32 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
virtual bool is_new_expression() const override { return true; }
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 15:33:52 +00:00
};
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 17:30:38 +00:00
class SuperCall final : public Expression {
public:
SuperCall(SourceRange source_range, Vector<CallExpression::Argument> arguments)
: Expression(source_range)
, m_arguments(move(arguments))
{
}
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
private:
Vector<CallExpression::Argument> const m_arguments;
};
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
enum class AssignmentOp {
LibJS: Tweak AssignmentOp names
2020-03-12 12:54:56 +00:00
Assignment,
AdditionAssignment,
SubtractionAssignment,
MultiplicationAssignment,
DivisionAssignment,
LibJS: Implement modulo assignment operator (%=)
2020-05-04 22:07:05 +00:00
ModuloAssignment,
LibJS: Implement exponentiation assignment operator (**=)
2020-05-04 22:03:35 +00:00
ExponentiationAssignment,
LibJS: Implement bitwise assignment operators (&=, |=, ^=)
2020-05-04 21:34:45 +00:00
BitwiseAndAssignment,
BitwiseOrAssignment,
BitwiseXorAssignment,
LibJS: Implement bitwise left shift operator (<<)
2020-04-23 12:36:14 +00:00
LeftShiftAssignment,
LibJS: Implement bitwise right shift operator (>>)
2020-04-23 12:45:19 +00:00
RightShiftAssignment,
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 14:43:10 +00:00
UnsignedRightShiftAssignment,
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 15:49:43 +00:00
AndAssignment,
OrAssignment,
NullishAssignment,
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class AssignmentExpression final : public Expression {
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
public:
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 17:15:22 +00:00
AssignmentExpression(SourceRange source_range, AssignmentOp op, NonnullRefPtr<Expression> lhs, NonnullRefPtr<Expression> rhs)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_op(op)
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-10 20:46:17 +00:00
AssignmentExpression(SourceRange source_range, AssignmentOp op, NonnullRefPtr<BindingPattern> lhs, NonnullRefPtr<Expression> rhs)
: Expression(source_range)
, m_op(op)
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
private:
AssignmentOp m_op;
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-10 20:46:17 +00:00
Variant<NonnullRefPtr<Expression>, NonnullRefPtr<BindingPattern>> m_lhs;
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtr<Expression> m_rhs;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
};
LibJS: 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 11:45:45 +00:00
enum class UpdateOp {
Increment,
Decrement,
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class UpdateExpression final : public Expression {
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 11:45:45 +00:00
public:
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 17:15:22 +00:00
UpdateExpression(SourceRange source_range, UpdateOp op, NonnullRefPtr<Expression> argument, bool prefixed = false)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_op(op)
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 11:45:45 +00:00
, m_argument(move(argument))
LibJS/AST: Implement prefixed update expressions
2020-03-14 18:44:57 +00:00
, m_prefixed(prefixed)
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 11:45:45 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 11:45:45 +00:00
virtual void dump(int indent) const override;
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 09:40:38 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 11:45:45 +00:00
private:
UpdateOp m_op;
AK: Stop allowing implicit downcast with RefPtr and NonnullRefPtr We were allowing this dangerous kind of thing: RefPtr<Base> base; RefPtr<Derived> derived = base; This patch changes the {Nonnull,}RefPtr constructors so this is no longer possible. To downcast one of these pointers, there is now static_ptr_cast<T>: RefPtr<Derived> derived = static_ptr_cast<Derived>(base); Fixing this exposed a ton of cowboy-downcasts in various places, which we're now forced to fix. :^)
2020-04-05 09:11:07 +00:00
NonnullRefPtr<Expression> m_argument;
LibJS/AST: Implement prefixed update expressions
2020-03-14 18:44:57 +00:00
bool m_prefixed;
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 11:45:45 +00:00
};
LibJS: rename JS::DeclarationType => JS::DeclarationKind Many other parsers call it with this name. Also Type can be confusing in this context since the DeclarationType is not the type (number, string, etc.) of the variables that are being declared by the VariableDeclaration.
2020-04-08 09:59:18 +00:00
enum class DeclarationKind {
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 19:09:20 +00:00
Var,
Let,
LibJS: Implement const variable declarations This also tightens the means of redeclaration of a variable by proxy, since we now have a way of knowing how a variable was initially declared, we can check if it was declared using `let` or `const` and not tolerate redeclaration like we did previously.
2020-03-12 12:24:34 +00:00
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 19:09:20 +00:00
};
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 19:46:25 +00:00
class VariableDeclarator final : public ASTNode {
public:
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 17:15:22 +00:00
VariableDeclarator(SourceRange source_range, NonnullRefPtr<Identifier> id)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: ASTNode(source_range)
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
, m_target(move(id))
LibJS: Implement basic for..in and for..of loops
2020-04-21 18:21:26 +00:00
{
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
VariableDeclarator(SourceRange source_range, NonnullRefPtr<Identifier> target, RefPtr<Expression> init)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: ASTNode(source_range)
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
, m_target(move(target))
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 19:46:25 +00:00
, m_init(move(init))
{
}
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
VariableDeclarator(SourceRange source_range, Variant<NonnullRefPtr<Identifier>, NonnullRefPtr<BindingPattern>> target, RefPtr<Expression> init)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: ASTNode(source_range)
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
, m_target(move(target))
, m_init(move(init))
{
}
auto& target() const { return m_target; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const* init() const { return m_init; }
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 19:46:25 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 19:46:25 +00:00
virtual void dump(int indent) const override;
private:
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
Variant<NonnullRefPtr<Identifier>, NonnullRefPtr<BindingPattern>> m_target;
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 19:46:25 +00:00
RefPtr<Expression> m_init;
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class VariableDeclaration final : public Declaration {
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
public:
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 17:15:22 +00:00
VariableDeclaration(SourceRange source_range, DeclarationKind declaration_kind, NonnullRefPtrVector<VariableDeclarator> declarations)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Declaration(source_range)
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 17:15:22 +00:00
, m_declaration_kind(declaration_kind)
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 19:46:25 +00:00
, m_declarations(move(declarations))
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
{
}
LibJS: rename JS::DeclarationType => JS::DeclarationKind Many other parsers call it with this name. Also Type can be confusing in this context since the DeclarationType is not the type (number, string, etc.) of the variables that are being declared by the VariableDeclaration.
2020-04-08 09:59:18 +00:00
DeclarationKind declaration_kind() const { return m_declaration_kind; }
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
virtual void dump(int indent) const override;
LibJS: Add empty bytecode generation for VariableDeclaration These will be partly handled by the relevant ScopeNode due to hoisting, same basic idea as function declarations. VariableDeclaration needs to do some work, but let's stub it out first and start empty.
2021-06-09 22:29:17 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
NonnullRefPtrVector<VariableDeclarator> const& declarations() const { return m_declarations; }
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 14:42:54 +00:00
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
private:
LibJS: rename JS::DeclarationType => JS::DeclarationKind Many other parsers call it with this name. Also Type can be confusing in this context since the DeclarationType is not the type (number, string, etc.) of the variables that are being declared by the VariableDeclaration.
2020-04-08 09:59:18 +00:00
DeclarationKind m_declaration_kind;
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 19:46:25 +00:00
NonnullRefPtrVector<VariableDeclarator> m_declarations;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
};
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
class ObjectProperty final : public ASTNode {
public:
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-22 00:28:28 +00:00
enum class Type {
KeyValue,
Getter,
Setter,
Spread,
};
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 17:15:22 +00:00
ObjectProperty(SourceRange source_range, NonnullRefPtr<Expression> key, RefPtr<Expression> value, Type property_type, bool is_method)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: ASTNode(source_range)
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 17:15:22 +00:00
, m_key(move(key))
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
, m_value(move(value))
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-22 00:28:28 +00:00
, m_property_type(property_type)
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 18:31:21 +00:00
, m_is_method(is_method)
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& key() const { return m_key; }
Expression const& value() const
LibJS: Rewrite Parser.parse_object_expression() This rewrite drastically increases the accuracy of object literals. Additionally, an "assertIsSyntaxError" function has been added to test-common.js to assist in testing syntax errors.
2020-05-29 05:50:06 +00: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 19:42:32 +00:00
VERIFY(m_value);
LibJS: Rewrite Parser.parse_object_expression() This rewrite drastically increases the accuracy of object literals. Additionally, an "assertIsSyntaxError" function has been added to test-common.js to assist in testing syntax errors.
2020-05-29 05:50:06 +00:00
return *m_value;
}
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-22 00:28:28 +00:00
Type type() const { return m_property_type; }
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 18:31:21 +00:00
bool is_method() const { return m_is_method; }
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-28 04:52:47 +00:00
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
private:
NonnullRefPtr<Expression> m_key;
LibJS: Rewrite Parser.parse_object_expression() This rewrite drastically increases the accuracy of object literals. Additionally, an "assertIsSyntaxError" function has been added to test-common.js to assist in testing syntax errors.
2020-05-29 05:50:06 +00:00
RefPtr<Expression> m_value;
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-22 00:28:28 +00:00
Type m_property_type;
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 18:31:21 +00:00
bool m_is_method { false };
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class ObjectExpression final : public Expression {
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 20:28:31 +00:00
public:
LibJS: Allow 'name = value' in object literals as the spec does Currently, these are _always_ a syntax error, future commits will make it valid in certain contexts.
2021-07-11 10:18:30 +00:00
explicit ObjectExpression(SourceRange source_range, NonnullRefPtrVector<ObjectProperty> properties = {}, Optional<SourceRange> first_invalid_property_range = {})
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_properties(move(properties))
LibJS: Allow 'name = value' in object literals as the spec does Currently, these are _always_ a syntax error, future commits will make it valid in certain contexts.
2021-07-11 10:18:30 +00:00
, m_first_invalid_property_range(move(first_invalid_property_range))
LibJS: Parse object expressions
2020-03-21 00:29:00 +00: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 20:28:31 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 20:28:31 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 20:28:31 +00:00
LibJS: Allow 'name = value' in object literals as the spec does Currently, these are _always_ a syntax error, future commits will make it valid in certain contexts.
2021-07-11 10:18:30 +00:00
Optional<SourceRange> const& invalid_property_range() const { return m_first_invalid_property_range; }
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 20:28:31 +00:00
private:
LibJS: Implement computed properties in object expressions
2020-04-23 18:37:53 +00:00
NonnullRefPtrVector<ObjectProperty> m_properties;
LibJS: Allow 'name = value' in object literals as the spec does Currently, these are _always_ a syntax error, future commits will make it valid in certain contexts.
2021-07-11 10:18:30 +00:00
Optional<SourceRange> m_first_invalid_property_range;
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 20:28:31 +00:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 18:13:32 +00:00
class ArrayExpression final : public Expression {
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
public:
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 17:15:22 +00:00
ArrayExpression(SourceRange source_range, Vector<RefPtr<Expression>> elements)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_elements(move(elements))
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Vector<RefPtr<Expression>> const& elements() const { return m_elements; }
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
virtual void dump(int indent) const override;
LibJS: Generate bytecode for array expressions
2021-06-08 21:06:52 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
private:
LibJS: Support empty values in array expression
2020-04-15 19:09:06 +00:00
Vector<RefPtr<Expression>> m_elements;
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
};
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 22:41:14 +00:00
class TemplateLiteral final : public Expression {
public:
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 17:15:22 +00:00
TemplateLiteral(SourceRange source_range, NonnullRefPtrVector<Expression> expressions)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_expressions(move(expressions))
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 23:34:14 +00: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 17:15:22 +00:00
TemplateLiteral(SourceRange source_range, NonnullRefPtrVector<Expression> expressions, NonnullRefPtrVector<Expression> raw_strings)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_expressions(move(expressions))
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 23:34:14 +00:00
, m_raw_strings(move(raw_strings))
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 22:41:14 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 22:41:14 +00:00
virtual void dump(int indent) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 22:41:14 +00:00
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
NonnullRefPtrVector<Expression> const& expressions() const { return m_expressions; }
NonnullRefPtrVector<Expression> const& raw_strings() const { return m_raw_strings; }
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 22:41:14 +00:00
private:
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
NonnullRefPtrVector<Expression> const m_expressions;
NonnullRefPtrVector<Expression> const m_raw_strings;
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 22:41:14 +00: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 09:17:35 +00:00
class TaggedTemplateLiteral final : public Expression {
public:
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 17:15:22 +00:00
TaggedTemplateLiteral(SourceRange source_range, NonnullRefPtr<Expression> tag, NonnullRefPtr<TemplateLiteral> template_literal)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_tag(move(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 09:17:35 +00:00
, m_template_literal(move(template_literal))
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 09:17:35 +00:00
virtual void dump(int indent) const override;
LibJS: Generate bytecode for tagged template literals
2021-06-09 19:02:24 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 09:17:35 +00:00
private:
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
NonnullRefPtr<Expression> const m_tag;
NonnullRefPtr<TemplateLiteral> const m_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 09:17:35 +00: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 17:58:19 +00:00
class MemberExpression final : public Expression {
public:
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 17:15:22 +00:00
MemberExpression(SourceRange source_range, NonnullRefPtr<Expression> object, NonnullRefPtr<Expression> property, bool computed = false)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_object(move(object))
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 17:58:19 +00:00
, m_property(move(property))
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 19:51:03 +00:00
, m_computed(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 17:58:19 +00:00
{
}
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
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 17:58:19 +00:00
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Reference to_reference(Interpreter&, GlobalObject&) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
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 17:58:19 +00:00
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 19:51:03 +00:00
bool is_computed() const { return m_computed; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& object() const { return *m_object; }
Expression const& property() const { return *m_property; }
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 14:01:10 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
PropertyName computed_property_name(Interpreter&, GlobalObject&) 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 19:51:03 +00:00
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 00:12:51 +00:00
String to_string_approximation() 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 17:58:19 +00:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
virtual bool is_member_expression() const override { return true; }
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 10:23:53 +00:00
NonnullRefPtr<Expression> m_object;
NonnullRefPtr<Expression> m_property;
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 19:51:03 +00:00
bool m_computed { false };
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 17:58:19 +00: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
class MetaProperty final : public Expression {
public:
enum class Type {
NewTarget,
ImportMeta,
};
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 17:15:22 +00:00
MetaProperty(SourceRange source_range, Type type)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_type(type)
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
{
}
virtual Value execute(Interpreter&, GlobalObject&) const override;
virtual void dump(int indent) const override;
private:
Type m_type;
};
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 10:14:28 +00:00
class ConditionalExpression final : public Expression {
public:
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 17:15:22 +00:00
ConditionalExpression(SourceRange source_range, NonnullRefPtr<Expression> test, NonnullRefPtr<Expression> consequent, NonnullRefPtr<Expression> alternate)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Expression(source_range)
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 17:15:22 +00:00
, m_test(move(test))
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 10:14:28 +00:00
, m_consequent(move(consequent))
, m_alternate(move(alternate))
{
}
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 10:14:28 +00:00
private:
NonnullRefPtr<Expression> m_test;
NonnullRefPtr<Expression> m_consequent;
NonnullRefPtr<Expression> m_alternate;
};
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
class CatchClause final : public ASTNode {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
CatchClause(SourceRange source_range, FlyString parameter, NonnullRefPtr<BlockStatement> body)
: ASTNode(source_range)
, m_parameter(move(parameter))
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
, m_body(move(body))
{
}
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 10:45:38 +00:00
CatchClause(SourceRange source_range, NonnullRefPtr<BindingPattern> parameter, NonnullRefPtr<BlockStatement> body)
: ASTNode(source_range)
, m_parameter(move(parameter))
, m_body(move(body))
{
}
auto& parameter() const { return m_parameter; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
BlockStatement const& body() const { return m_body; }
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
private:
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 10:45:38 +00:00
Variant<FlyString, NonnullRefPtr<BindingPattern>> m_parameter;
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
NonnullRefPtr<BlockStatement> m_body;
};
class TryStatement final : public Statement {
public:
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 17:15:22 +00:00
TryStatement(SourceRange source_range, NonnullRefPtr<BlockStatement> block, RefPtr<CatchClause> handler, RefPtr<BlockStatement> finalizer)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_block(move(block))
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
, m_handler(move(handler))
, m_finalizer(move(finalizer))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
BlockStatement const& block() const { return m_block; }
CatchClause const* handler() const { return m_handler; }
BlockStatement const* finalizer() const { return m_finalizer; }
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 13:04:38 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 13:03:55 +00:00
private:
NonnullRefPtr<BlockStatement> m_block;
RefPtr<CatchClause> m_handler;
RefPtr<BlockStatement> m_finalizer;
};
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 21:03:50 +00:00
class ThrowStatement final : public Statement {
public:
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 17:15:22 +00:00
explicit ThrowStatement(SourceRange source_range, NonnullRefPtr<Expression> argument)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_argument(move(argument))
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 21:03:50 +00:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const& argument() const { return m_argument; }
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 21:03:50 +00:00
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Generate bytecode for throw statements
2021-06-09 16:18:56 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 21:03:50 +00:00
private:
NonnullRefPtr<Expression> m_argument;
};
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
class SwitchCase final : public ASTNode {
public:
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 17:15:22 +00:00
SwitchCase(SourceRange source_range, RefPtr<Expression> test, NonnullRefPtrVector<Statement> consequent)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: ASTNode(source_range)
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 17:15:22 +00:00
, m_test(move(test))
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
, m_consequent(move(consequent))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
Expression const* test() const { return m_test; }
NonnullRefPtrVector<Statement> const& consequent() const { return m_consequent; }
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 12:34:25 +00:00
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
private:
RefPtr<Expression> m_test;
NonnullRefPtrVector<Statement> m_consequent;
};
class SwitchStatement final : public Statement {
public:
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 17:15:22 +00:00
SwitchStatement(SourceRange source_range, NonnullRefPtr<Expression> discriminant, NonnullRefPtrVector<SwitchCase> cases)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
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 17:15:22 +00:00
, m_discriminant(move(discriminant))
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
, m_cases(move(cases))
{
}
virtual void dump(int indent) const override;
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Implement bytecode generation for switch
2021-06-10 22:36:16 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
private:
NonnullRefPtr<Expression> m_discriminant;
NonnullRefPtrVector<SwitchCase> m_cases;
};
class BreakStatement final : public Statement {
public:
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 17:15:22 +00:00
BreakStatement(SourceRange source_range, FlyString target_label)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
, m_target_label(move(target_label))
LibJS: Parse labels in continue and break statements
2020-05-28 19:02:32 +00:00
{
}
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
FlyString const& target_label() const { return m_target_label; }
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 12:28:43 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Parse labels in continue and break statements
2020-05-28 19:02:32 +00:00
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
private:
LibJS: Parse labels in continue and break statements
2020-05-28 19:02:32 +00:00
FlyString m_target_label;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
};
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-04 22:22:42 +00:00
class ContinueStatement final : public Statement {
public:
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 17:15:22 +00:00
ContinueStatement(SourceRange source_range, FlyString target_label)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
: Statement(source_range)
, m_target_label(move(target_label))
LibJS: Parse labels in continue and break statements
2020-05-28 19:02:32 +00:00
{
}
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-04 22:22:42 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-04 22:22:42 +00:00
LibJS: Switch AST.{h,cpp} to east const
2021-06-10 21:43:06 +00:00
FlyString const& target_label() const { return m_target_label; }
LibJS: Parse labels in continue and break statements
2020-05-28 19:02:32 +00:00
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-04 22:22:42 +00:00
private:
LibJS: Parse labels in continue and break statements
2020-05-28 19:02:32 +00:00
FlyString m_target_label;
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-04 22:22:42 +00:00
};
LibJS: Implement (no-op) debugger statement
2020-04-30 16:26:27 +00:00
class DebuggerStatement final : public Statement {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 11:38:21 +00:00
explicit DebuggerStatement(SourceRange source_range)
: Statement(source_range)
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 17:15:22 +00:00
{
}
LibJS: Implement (no-op) debugger statement
2020-04-30 16:26:27 +00:00
LibJS: Pass GlobalObject& to AST node execute() functions More work towards supporting multiple global objects.
2020-06-08 18:57:54 +00:00
virtual Value execute(Interpreter&, GlobalObject&) const override;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-08 03:58:36 +00:00
virtual void generate_bytecode(Bytecode::Generator&) const override;
LibJS: Implement (no-op) debugger statement
2020-04-30 16:26:27 +00:00
};
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
template<typename C>
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
void BindingPattern::for_each_bound_name(C&& callback) const
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
{
LibJS: Restructure and fully implement BindingPatterns
2021-06-13 01:04:28 +00:00
for (auto& entry : entries) {
auto& alias = entry.alias;
if (alias.has<NonnullRefPtr<Identifier>>()) {
callback(alias.get<NonnullRefPtr<Identifier>>()->string());
} else if (alias.has<NonnullRefPtr<BindingPattern>>()) {
alias.get<NonnullRefPtr<BindingPattern>>()->for_each_bound_name(forward<C>(callback));
LibJS: Rework Identifier parsing to match the spec more closely
2021-07-11 11:04:55 +00:00
} else {
auto& name = entry.name;
if (name.has<NonnullRefPtr<Identifier>>())
callback(name.get<NonnullRefPtr<Identifier>>()->string());
LibJS: Implement destructuring assignments and function parameters
2021-05-29 11:33:19 +00:00
}
}
}
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 09:23:23 +00:00
template<>
inline bool ASTNode::fast_is<NewExpression>() const { return is_new_expression(); }
template<>
inline bool ASTNode::fast_is<MemberExpression>() const { return is_member_expression(); }
template<>
inline bool ASTNode::fast_is<SuperExpression>() const { return is_super_expression(); }
template<>
inline bool ASTNode::fast_is<Identifier>() const { return is_identifier(); }
template<>
inline bool ASTNode::fast_is<ExpressionStatement>() const { return is_expression_statement(); }
template<>
inline bool ASTNode::fast_is<ScopeNode>() const { return is_scope_node(); }
template<>
inline bool ASTNode::fast_is<Program>() const { return is_program(); }
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
}
Reference in a new issue Copy permalink