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/Libraries/LibJS/AST.h

871 lines
24 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
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#pragma once
LibJS: Implement "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>
#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: 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: 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: 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>
create_ast_node(Args&&... args)
{
return adopt(*new T(forward<Args>(args)...));
}
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:
virtual ~ASTNode() {}
virtual const char* class_name() const = 0;
virtual Value execute(Interpreter&) const = 0;
virtual void dump(int indent) const;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 20:13:55 +00:00
virtual bool is_identifier() const { return false; }
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 16:39:13 +00:00
virtual bool is_member_expression() const { return false; }
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
virtual bool is_scope_node() const { return false; }
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
virtual bool is_program() const { return false; }
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
virtual bool is_variable_declaration() const { return false; }
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
virtual bool is_new_expression() 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:
ASTNode() {}
private:
};
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 {
};
class ErrorStatement final : public Statement {
public:
LibJS: Specify overridden functions with 'override'
2020-03-15 21:33:38 +00:00
Value execute(Interpreter&) const override { return js_undefined(); }
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
const char* class_name() const override { return "ErrorStatement"; }
};
class ExpressionStatement final : public Statement {
public:
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
ExpressionStatement(NonnullRefPtr<Expression> 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
: m_expression(move(expression))
{
}
Value execute(Interpreter&) const override;
const char* class_name() const override { return "ExpressionStatement"; }
virtual void dump(int indent) const override;
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_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>
T& append(Args&&... args)
{
LibJS: Fix reference leak in ASTNode::append() Using make<T> like this would create an unadopted object whose refcount would never reach zero.
2020-03-19 10:02:20 +00:00
auto child = create_ast_node<T>(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: 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
const NonnullRefPtrVector<Statement>& children() const { return m_children; }
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 Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
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>);
const NonnullRefPtrVector<VariableDeclaration>& variables() const { return m_variables; }
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:
ScopeNode() {}
private:
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
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: 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 Program : public ScopeNode {
public:
Program() {}
private:
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
virtual bool is_program() const override { return true; }
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 const char* class_name() const override { return "Program"; }
};
class BlockStatement : public ScopeNode {
public:
BlockStatement() {}
private:
virtual const char* class_name() const override { return "BlockStatement"; }
};
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 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: 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: 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
const FlyString& name() const { return 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
const Statement& body() const { return *m_body; }
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
const Vector<FlyString>& parameters() const { return m_parameters; };
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: 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
FunctionNode(const FlyString& name, NonnullRefPtr<Statement> body, Vector<FlyString> parameters, NonnullRefPtrVector<VariableDeclaration> variables)
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
: m_name(name)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 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: 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
, m_variables(move(variables))
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
void dump(int indent, const char* class_name) const;
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
const NonnullRefPtrVector<VariableDeclaration>& variables() const { return m_variables; }
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: 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
const Vector<FlyString> m_parameters;
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: 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: 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
FunctionDeclaration(const FlyString& name, NonnullRefPtr<Statement> body, Vector<FlyString> parameters, NonnullRefPtrVector<VariableDeclaration> variables)
: FunctionNode(name, move(body), move(parameters), move(variables))
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
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "FunctionDeclaration"; }
};
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 FunctionExpression final : public Expression
, 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: 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
FunctionExpression(const FlyString& name, NonnullRefPtr<Statement> body, Vector<FlyString> parameters, NonnullRefPtrVector<VariableDeclaration> variables)
: FunctionNode(name, move(body), move(parameters), move(variables))
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 Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "FunctionExpression"; }
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: Specify overridden functions with 'override'
2020-03-15 21:33:38 +00:00
Value execute(Interpreter&) const override { return js_undefined(); }
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
const char* class_name() const override { return "ErrorExpression"; }
};
class ReturnStatement : 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: 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
explicit ReturnStatement(RefPtr<Expression> 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
: m_argument(move(argument))
{
}
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
const Expression* 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
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "ReturnStatement"; }
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: 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 IfStatement : 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: 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
IfStatement(NonnullRefPtr<Expression> predicate, NonnullRefPtr<Statement> consequent, RefPtr<Statement> 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
: m_predicate(move(predicate))
, m_consequent(move(consequent))
, m_alternate(move(alternate))
{
}
const Expression& predicate() const { return *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
const Statement& consequent() const { return *m_consequent; }
const Statement* 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
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "IfStatement"; }
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: 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 WhileStatement : public Statement {
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
public:
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
WhileStatement(NonnullRefPtr<Expression> test, NonnullRefPtr<Statement> body)
LibJS: Rename WhileStatement::predicate() => body() This name matches other parsers.
2020-04-04 19:21:19 +00:00
: m_test(move(test))
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
, m_body(move(body))
{
}
LibJS: Rename WhileStatement::predicate() => body() This name matches other parsers.
2020-04-04 19:21:19 +00:00
const Expression& test() const { return *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
const Statement& body() const { return *m_body; }
LibJS: Implement While statements
2020-03-08 19:22:21 +00:00
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "WhileStatement"; }
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: Add support for do..while statements
2020-04-04 19:29:23 +00:00
class DoWhileStatement : public Statement {
public:
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
DoWhileStatement(NonnullRefPtr<Expression> test, NonnullRefPtr<Statement> body)
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
: m_test(move(test))
, m_body(move(body))
{
}
const Expression& test() const { return *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
const Statement& body() const { return *m_body; }
LibJS: Add support for do..while statements
2020-04-04 19:29:23 +00:00
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "DoWhileStatement"; }
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: Implement for statement
2020-03-12 12:12:12 +00:00
class ForStatement : public Statement {
public:
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
ForStatement(RefPtr<ASTNode> init, RefPtr<Expression> test, RefPtr<Expression> update, NonnullRefPtr<Statement> body)
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
: m_init(move(init))
, m_test(move(test))
, m_update(move(update))
, m_body(move(body))
{
}
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
const ASTNode* init() const { return m_init; }
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
const Expression* test() const { return m_test; }
const Expression* update() const { return 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
const Statement& body() const { return *m_body; }
LibJS: Implement for statement
2020-03-12 12:12:12 +00:00
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "ForStatement"; }
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: 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 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
};
class BinaryExpression : public Expression {
public:
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
BinaryExpression(BinaryOp op, NonnullRefPtr<Expression> lhs, NonnullRefPtr<Expression> 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
: m_op(op)
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "BinaryExpression"; }
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
};
class LogicalExpression : public Expression {
public:
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
LogicalExpression(LogicalOp op, NonnullRefPtr<Expression> lhs, NonnullRefPtr<Expression> 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
: m_op(op)
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "LogicalExpression"; }
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: 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
};
class UnaryExpression : public Expression {
public:
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
UnaryExpression(UnaryOp op, NonnullRefPtr<Expression> 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
: m_op(op)
, m_lhs(move(lhs))
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "UnaryExpression"; }
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:
SequenceExpression(NonnullRefPtrVector<Expression> expressions)
: m_expressions(move(expressions))
{
}
virtual void dump(int indent) const override;
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "SequenceExpression"; }
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:
explicit Literal() {}
};
class BooleanLiteral final : public Literal {
public:
explicit BooleanLiteral(bool value)
: m_value(value)
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "BooleanLiteral"; }
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: 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
explicit NumericLiteral(double value)
: m_value(value)
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "NumericLiteral"; }
double m_value { 0 };
};
class StringLiteral final : public Literal {
public:
explicit StringLiteral(String value)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 18:42:11 +00:00
: m_value(move(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
virtual Value execute(Interpreter&) 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;
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
virtual const char* class_name() const override { return "StringLiteral"; }
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: 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: 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: 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
explicit NullLiteral() {}
LibJS: Implement null and undefined literals
2020-03-15 21:32:34 +00:00
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "NullLiteral"; }
};
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: 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
explicit Identifier(const FlyString& string)
: m_string(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: 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
const FlyString& 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
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
virtual bool is_identifier() const override { return true; }
private:
virtual const char* class_name() const override { return "Identifier"; }
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: Parse "this" as ThisExpression
2020-04-12 22:42:14 +00:00
class ThisExpression final : public Expression {
public:
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "ThisExpression"; }
};
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: 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
CallExpression(NonnullRefPtr<Expression> callee, NonnullRefPtrVector<Expression> arguments = {})
LibJS: Add operator precedence parsing Obey precedence and associativity rules when parsing expressions with chained operators.
2020-03-12 22:02:41 +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
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "CallExpression"; }
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;
};
ThisAndCallee compute_this_and_callee(Interpreter&) const;
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_callee;
const NonnullRefPtrVector<Expression> m_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: 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:
NewExpression(NonnullRefPtr<Expression> callee, NonnullRefPtrVector<Expression> arguments = {})
: CallExpression(move(callee), move(arguments))
{
}
private:
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
virtual const char* class_name() const override { return "NewExpression"; }
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
virtual bool is_new_expression() const override { return true; }
};
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: 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
};
class AssignmentExpression : public Expression {
public:
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
AssignmentExpression(AssignmentOp op, NonnullRefPtr<ASTNode> lhs, NonnullRefPtr<Expression> 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
: m_op(op)
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "AssignmentExpression"; }
AssignmentOp 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<ASTNode> m_lhs;
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,
};
class UpdateExpression : public Expression {
public:
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
UpdateExpression(UpdateOp op, NonnullRefPtr<Expression> argument, bool prefixed = false)
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_op(op)
, 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
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "UpdateExpression"; }
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:
VariableDeclarator(NonnullRefPtr<Identifier> id, RefPtr<Expression> init)
: m_id(move(id))
, m_init(move(init))
{
}
const Identifier& id() const { return m_id; }
const Expression* init() const { return m_init; }
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "VariableDeclarator"; }
NonnullRefPtr<Identifier> m_id;
RefPtr<Expression> m_init;
};
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 VariableDeclaration : 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: 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
VariableDeclaration(DeclarationKind declaration_kind, NonnullRefPtrVector<VariableDeclarator> declarations)
: 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: Evaluate for statements in their own scope if necessary We now evaluate for loops in their own scope if their init statement is a lexical declaration. Evaluating for loops in their own scope allow us to obtain expected behaviour, which means for example, that the block-scoped variables declared in a for statement will be limited to the scope of the for loop's body and statement and not to that of the current scope (i.e the one where the for statement was made)
2020-03-14 11:56:49 +00:00
virtual bool is_variable_declaration() const override { return true; }
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
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
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
const NonnullRefPtrVector<VariableDeclarator>& declarations() const { return 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
private:
virtual const char* class_name() const override { return "VariableDeclaration"; }
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: 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
class ObjectExpression : public Expression {
public:
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
ObjectExpression(HashMap<FlyString, NonnullRefPtr<Expression>> properties = {})
LibJS: Some optimizations for ObjectExpression - move() the property map when constructing ObjectExpression instead of making a copy. - Use key+value iterators to traverse the property map in the execute() and dump() functions.
2020-03-21 12:05:43 +00:00
: m_properties(move(properties))
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
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "ObjectExpression"; }
LibJS: Parse object expressions
2020-03-21 00:29:00 +00:00
LibJS: Use FlyString for identifiers This makes variable and property lookups a lot faster since comparing two FlyStrings is O(1).
2020-03-22 10:07:55 +00:00
HashMap<FlyString, NonnullRefPtr<Expression>> m_properties;
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: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
class ArrayExpression : public Expression {
public:
LibJS: Support empty values in array expression
2020-04-15 19:09:06 +00:00
ArrayExpression(Vector<RefPtr<Expression>> 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
: m_elements(move(elements))
{
}
LibJS: Support empty values in array expression
2020-04-15 19:09:06 +00:00
const Vector<RefPtr<Expression>>& 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
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
private:
virtual const char* class_name() const override { return "ArrayExpression"; }
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: 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: 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
MemberExpression(NonnullRefPtr<Expression> object, NonnullRefPtr<Expression> property, bool 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
: m_object(move(object))
, 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
{
}
virtual Value execute(Interpreter&) const override;
virtual void dump(int indent) const override;
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: 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
const Expression& object() const { return *m_object; }
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 16:39:13 +00:00
const Expression& 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: 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
PropertyName computed_property_name(Interpreter&) 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: 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 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
virtual bool is_member_expression() const override { return true; }
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 const char* class_name() const override { return "MemberExpression"; }
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 ConditionalExpression (ternary "?:" operator)
2020-04-03 10:14:28 +00:00
class ConditionalExpression final : public Expression {
public:
ConditionalExpression(NonnullRefPtr<Expression> test, NonnullRefPtr<Expression> consequent, NonnullRefPtr<Expression> alternate)
: m_test(move(test))
, m_consequent(move(consequent))
, m_alternate(move(alternate))
{
}
virtual void dump(int indent) const override;
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "ConditionalExpression"; }
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:
CatchClause(const FlyString& parameter, NonnullRefPtr<BlockStatement> body)
: m_parameter(parameter)
, m_body(move(body))
{
}
const FlyString& parameter() const { return m_parameter; }
const BlockStatement& body() const { return m_body; }
virtual void dump(int indent) const override;
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "CatchClause"; }
FlyString m_parameter;
NonnullRefPtr<BlockStatement> m_body;
};
class TryStatement final : public Statement {
public:
TryStatement(NonnullRefPtr<BlockStatement> block, RefPtr<CatchClause> handler, RefPtr<BlockStatement> finalizer)
: m_block(move(block))
, m_handler(move(handler))
, m_finalizer(move(finalizer))
{
}
const BlockStatement& block() const { return m_block; }
const CatchClause* handler() const { return m_handler; }
const BlockStatement* finalizer() const { return m_finalizer; }
virtual void dump(int indent) const override;
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "TryStatement"; }
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:
explicit ThrowStatement(NonnullRefPtr<Expression> argument)
: m_argument(move(argument))
{
}
const Expression& argument() const { return m_argument; }
virtual void dump(int indent) const override;
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "ThrowStatement"; }
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:
SwitchCase(RefPtr<Expression> test, NonnullRefPtrVector<Statement> consequent)
: m_test(move(test))
, m_consequent(move(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
const Expression* test() const { return m_test; }
const NonnullRefPtrVector<Statement>& consequent() const { return m_consequent; }
LibJS: Lexer and parser support for "switch" statements
2020-03-29 11:09:54 +00:00
virtual void dump(int indent) const override;
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "SwitchCase"; }
RefPtr<Expression> m_test;
NonnullRefPtrVector<Statement> m_consequent;
};
class SwitchStatement final : public Statement {
public:
SwitchStatement(NonnullRefPtr<Expression> discriminant, NonnullRefPtrVector<SwitchCase> cases)
: m_discriminant(move(discriminant))
, m_cases(move(cases))
{
}
virtual void dump(int indent) const override;
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "SwitchStatement"; }
NonnullRefPtr<Expression> m_discriminant;
NonnullRefPtrVector<SwitchCase> m_cases;
};
class BreakStatement final : public Statement {
public:
BreakStatement() {}
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "BreakStatement"; }
};
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-04 22:22:42 +00:00
class ContinueStatement final : public Statement {
public:
ContinueStatement() {}
virtual Value execute(Interpreter&) const override;
private:
virtual const char* class_name() const override { return "ContinueStatement"; }
};
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