Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/AST.h

2241 lines
81 KiB
C
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
/*
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
* Copyright (c) 2020-2024, Andreas Kling <kling@serenityos.org>
LibJS: Update AST to use completions :^) This is another major milestone on our journey towards removing global VM exception state :^) Does pretty much exactly what it says on the tin: updating ASTNode::execute() to return a Completion instead of a plain value. This will *also* allow us to eventually remove the non-standard unwinding mechanism and purely rely on the various completion types.
2022-01-02 21:37:50 +01:00
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
* Copyright (c) 2021-2022, David Tuin <davidot@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*/
#pragma once
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
#include <AK/ByteString.h>
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
#include <AK/DeprecatedFlyString.h>
LibJS: Parse object expressions
2020-03-21 02:29:00 +02:00
#include <AK/HashMap.h>
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
#include <AK/OwnPtr.h>
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 11:23:53 +01:00
#include <AK/RefPtr.h>
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
#include <AK/Variant.h>
LibJS: Allow functions to take arguments (#1405)
2020-03-12 19:22:13 +08:00
#include <AK/Vector.h>
LibJS: Make ASTNode::generate_bytecode() fallible Instead of crashing on the spot, return a descriptive error that will eventually continue its days as a javascript "InternalError" exception. This should make random crashes with BC less likely.
2022-02-12 19:54:08 +03:30
#include <LibJS/Bytecode/CodeGenerationError.h>
LibJS: Cache bytecode executables on the corresponding AST nodes This greatly reduces the number of compilations necessary when functions declaring local functions are re-executed. For example Octane/typescript.js goes from 58080 bytecode executables to 960.
2023-11-10 17:55:34 +01:00
#include <LibJS/Bytecode/Executable.h>
LibJS: Use the IdentifierTable for NewFunction and NewClass lhs names This makes them trivially copyable, which is an assumption multiple optimizations use when rebuilding the instruction stream. This fixes most optimized crashes in the test262 suite.
2023-06-28 18:17:13 +02:00
#include <LibJS/Bytecode/IdentifierTable.h>
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
#include <LibJS/Bytecode/Operand.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
#include <LibJS/Forward.h>
LibJS: Keep handles on internal function while creating a class It seems the stack search does not find all functions because they are kept in variants and other structs. This meant some function could be cleaned up while we were evaluating a class meaning it would fail/crash when attempting to run the functions.
2022-02-04 16:22:29 +01:00
#include <LibJS/Heap/Handle.h>
LibJS: De-duplicate ClassFieldDefinition Records This was defined twice, despite being the very same thing: - ClassElement::ClassFieldDefinition - ECMAScriptFunctionObject::InstanceField Move the former to a new header and use it everywhere. Also update the define_field() AO to take a single field instead of separate name and initializer arguments.
2022-04-20 00:06:45 +02:00
#include <LibJS/Runtime/ClassFieldDefinition.h>
LibJS: Update AST to use completions :^) This is another major milestone on our journey towards removing global VM exception state :^) Does pretty much exactly what it says on the tin: updating ASTNode::execute() to return a Completion instead of a plain value. This will *also* allow us to eventually remove the non-standard unwinding mechanism and purely rely on the various completion types.
2022-01-02 21:37:50 +01:00
#include <LibJS/Runtime/Completion.h>
LibJS: Fast non-local variable access :^) This patch introduces the "environment coordinate" concept, which encodes the distance from a variable access to the binding it ends up resolving to. EnvironmentCoordinate has two fields: - hops: The number of hops up the lexical environment chain we have to make before getting to the resolved binding. - index: The index of the resolved binding within its declarative environment record. Whenever a variable lookup resolves somewhere inside a declarative environment, we now cache the coordinates and reuse them in subsequent lookups. This is achieved via a coordinate cache in JS::Identifier. Note that non-strict direct eval() breaks this optimization and so it will not be performed if the resolved environment has been permanently screwed by eval(). This makes variable access *significantly* faster. :^)
2021-10-07 01:06:21 +02:00
#include <LibJS/Runtime/EnvironmentCoordinate.h>
LibJS: Implement async functions as generator functions in BC mode This applies a simple transformation, and adds a simple wrapper that translates the generator interface to the async function interface.
2021-11-11 00:46:07 +03:30
#include <LibJS/Runtime/FunctionKind.h>
LibJS+LibWeb: Move JS::ModuleRequest to its own header file This allows us to not include LibJS/AST.h in a couple more places.
2022-11-23 14:18:38 +01:00
#include <LibJS/Runtime/ModuleRequest.h>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
#include <LibJS/Runtime/PropertyKey.h>
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
#include <LibJS/Runtime/Reference.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.h>
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
#include <LibJS/SourceRange.h>
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 10:34:37 -04:00
#include <LibRegex/Regex.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
namespace JS {
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
class Declaration;
class ClassDeclaration;
LibJS: Hoist function declarations This patch adds function declaration hoisting. The mechanism is similar to var hoisting. Hoisted function declarations are to be put before the hoisted var declarations, hence they have to be treated separately.
2020-06-04 14:48:36 +02:00
class FunctionDeclaration;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
class Identifier;
LibJS: Allow member expressions in binding patterns Also allows literal string and numbers as property names in object binding patterns.
2021-09-18 01:11:32 +02:00
class MemberExpression;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
class VariableDeclaration;
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 11:23:53 +01:00
template<class T, class... Args>
static inline NonnullRefPtr<T>
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
create_ast_node(SourceRange range, Args&&... args)
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 11:23:53 +01:00
{
LibJS: Use move() on the SourceRange in create_ast_node()
2022-11-27 12:32:05 +01:00
return adopt_ref(*new T(move(range), forward<Args>(args)...));
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 11:23:53 +01:00
}
class ASTNode : public RefCounted<ASTNode> {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
public:
Libraries: Use default constructors/destructors in LibJS https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 10:25:06 -06:00
virtual ~ASTNode() = default;
LibJS: Add ASTNodeWithTailArray template to pack AST node + array This template allows us to allocate an AST node and an array of some arbitrary type T with one allocation instead of two. This can save a lot of memory in some cases. Thanks to Jonathan Müller for suggesting this technique! :^)
2022-11-27 12:33:02 +01:00
// NOTE: This is here to stop ASAN complaining about mismatch between new/delete sizes in ASTNodeWithTailArray.
void operator delete(void* ptr) { ::operator delete(ptr); }
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
virtual void dump(int indent) const;
LibJS: Avoid unnecessary SourceRange construction in parse_program() This takes `test-js` runtime from 4.3 sec to 4.1 sec on my machine.
2022-11-24 15:38:52 +01:00
[[nodiscard]] SourceRange source_range() const;
LibJS: Capture UnrealizedSourceRanges in ExecutionContext, not ASTNodes This loosens the connection to the AST interpreter and will allow us to generate SourceRanges for the Bytecode interpreter in the future as well Moves UnrealizedSourceRanges from TracebackFrame to the JS namespace for this
2023-07-27 14:40:01 +02:00
UnrealizedSourceRange unrealized_source_range() const
{
return { m_source_code, m_start_offset, m_end_offset };
}
LibJS: Use the source offset to sort imports in module Using source offsets directly means we don't have to synthesize any SourceRanges and circumvents that SourceRange returns invalid values for the last range of a file.
2022-11-27 01:15:37 +01:00
u32 start_offset() const { return m_start_offset; }
LibJS: Make Error stack traces lazier Instead of eagerly populating the stack trace with a textual representation of every call frame, just store the raw source code range (code, start offset, end offset). From that, we can generate the full rich backtrace when requested, and save ourselves the trouble otherwise. This makes test-wasm take ~7 seconds on my machine instead of ~60. :^)
2023-05-28 08:28:43 +02:00
u32 end_offset() const { return m_end_offset; }
SourceCode const& source_code() const { return *m_source_code; }
LibJS: Avoid unnecessary SourceRange construction in parse_program() This takes `test-js` runtime from 4.3 sec to 4.1 sec on my machine.
2022-11-24 15:38:52 +01:00
void set_end_offset(Badge<Parser>, u32 end_offset) { m_end_offset = end_offset; }
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString class_name() const;
LibJS: Replace ASTNode::class_name() with RTTI This is only used for debugging anyway, so performance doesn't matter too much.
2021-01-17 09:21:15 +01:00
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
template<typename T>
bool fast_is() const = delete;
virtual bool is_new_expression() const { return false; }
virtual bool is_member_expression() const { return false; }
virtual bool is_super_expression() const { return false; }
LibJS: Add fast_is<T>() for FunctionExpression and ClassExpression Spotted RTTI for these two above 1% in a profile.
2021-10-07 12:05:13 +02:00
virtual bool is_function_expression() const { return false; }
virtual bool is_class_expression() const { return false; }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_expression_statement() const { return false; }
virtual bool is_identifier() const { return false; }
LibJS: Add fast_is<PrivateIdentifier>()
2022-03-05 23:49:37 +01:00
virtual bool is_private_identifier() const { return false; }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_scope_node() const { return false; }
virtual bool is_program() const { return false; }
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_class_declaration() const { return false; }
LibJS: Add fast_is<T>() for FunctionDeclaration
2021-10-07 23:07:52 +02:00
virtual bool is_function_declaration() const { return false; }
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_variable_declaration() const { return false; }
virtual bool is_import_call() const { return false; }
virtual bool is_array_expression() const { return false; }
virtual bool is_object_expression() const { return false; }
virtual bool is_string_literal() const { return false; }
virtual bool is_update_expression() const { return false; }
virtual bool is_call_expression() const { return false; }
virtual bool is_labelled_statement() const { return false; }
virtual bool is_iteration_statement() const { return false; }
virtual bool is_class_method() const { return false; }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
protected:
LibJS: Reduce AST memory usage by shrink-wrapping source range info Before this change, each AST node had a 64-byte SourceRange member. This SourceRange had the following layout: filename: StringView (16 bytes) start: Position (24 bytes) end: Position (24 bytes) The Position structs have { line, column, offset }, all members size_t. To reduce memory consumption, AST nodes now only store the following: source_code: NonnullRefPtr<SourceCode> (8 bytes) start_offset: u32 (4 bytes) end_offset: u32 (4 bytes) SourceCode is a new ref-counted data structure that keeps the filename and original parsed source code in a single location, and all AST nodes have a pointer to it. The start_offset and end_offset can be turned into (line, column) when necessary by calling SourceCode::range_from_offsets(). This will walk the source code string and compute line/column numbers on the fly, so it's not necessarily fast, but it should be rare since this information is primarily used for diagnostics and exception stack traces. With this, ASTNode shrinks from 80 bytes to 32 bytes. This gives us a ~23% reduction in memory usage when loading twitter.com/awesomekling (330 MiB before, 253 MiB after!) :^)
2022-11-21 17:37:38 +01:00
explicit ASTNode(SourceRange);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
private:
LibJS: Rearrange ASTNode members so there's a padding hole at the end ASTNode inherits from RefCounted, which has a single 32-bit member. This means that there's a 32-bit padding hole after RefCounted, where we are free to put something (or it will go to waste!) This patch moves ASTNode::m_start_offset into that padding hole, and we now have a 32-bit padding hole at the end of ASTNode instead. This will allow ASTNode subclasses to put things in the ASTNode hole by moving them to the head of the member list.
2022-11-26 19:01:55 +01:00
// NOTE: These members are carefully ordered so that `m_start_offset` is packed with the padding after RefCounted::m_ref_count.
// This creates a 4-byte padding hole after `m_end_offset` which is used to pack subclasses better.
LibJS: Reduce AST memory usage by shrink-wrapping source range info Before this change, each AST node had a 64-byte SourceRange member. This SourceRange had the following layout: filename: StringView (16 bytes) start: Position (24 bytes) end: Position (24 bytes) The Position structs have { line, column, offset }, all members size_t. To reduce memory consumption, AST nodes now only store the following: source_code: NonnullRefPtr<SourceCode> (8 bytes) start_offset: u32 (4 bytes) end_offset: u32 (4 bytes) SourceCode is a new ref-counted data structure that keeps the filename and original parsed source code in a single location, and all AST nodes have a pointer to it. The start_offset and end_offset can be turned into (line, column) when necessary by calling SourceCode::range_from_offsets(). This will walk the source code string and compute line/column numbers on the fly, so it's not necessarily fast, but it should be rare since this information is primarily used for diagnostics and exception stack traces. With this, ASTNode shrinks from 80 bytes to 32 bytes. This gives us a ~23% reduction in memory usage when loading twitter.com/awesomekling (330 MiB before, 253 MiB after!) :^)
2022-11-21 17:37:38 +01:00
u32 m_start_offset { 0 };
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<SourceCode const> m_source_code;
LibJS: Reduce AST memory usage by shrink-wrapping source range info Before this change, each AST node had a 64-byte SourceRange member. This SourceRange had the following layout: filename: StringView (16 bytes) start: Position (24 bytes) end: Position (24 bytes) The Position structs have { line, column, offset }, all members size_t. To reduce memory consumption, AST nodes now only store the following: source_code: NonnullRefPtr<SourceCode> (8 bytes) start_offset: u32 (4 bytes) end_offset: u32 (4 bytes) SourceCode is a new ref-counted data structure that keeps the filename and original parsed source code in a single location, and all AST nodes have a pointer to it. The start_offset and end_offset can be turned into (line, column) when necessary by calling SourceCode::range_from_offsets(). This will walk the source code string and compute line/column numbers on the fly, so it's not necessarily fast, but it should be rare since this information is primarily used for diagnostics and exception stack traces. With this, ASTNode shrinks from 80 bytes to 32 bytes. This gives us a ~23% reduction in memory usage when loading twitter.com/awesomekling (330 MiB before, 253 MiB after!) :^)
2022-11-21 17:37:38 +01:00
u32 m_end_offset { 0 };
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
};
LibJS: Add ASTNodeWithTailArray template to pack AST node + array This template allows us to allocate an AST node and an array of some arbitrary type T with one allocation instead of two. This can save a lot of memory in some cases. Thanks to Jonathan Müller for suggesting this technique! :^)
2022-11-27 12:33:02 +01:00
// This is a helper class that packs an array of T after the AST node, all in the same allocation.
template<typename Derived, typename Base, typename T>
class ASTNodeWithTailArray : public Base {
public:
virtual ~ASTNodeWithTailArray() override
{
for (auto& value : tail_span())
value.~T();
}
Everywhere: Use ReadonlySpan<T> instead of Span<T const>
2023-02-05 19:02:54 +00:00
ReadonlySpan<T> tail_span() const { return { tail_data(), tail_size() }; }
LibJS: Add ASTNodeWithTailArray template to pack AST node + array This template allows us to allocate an AST node and an array of some arbitrary type T with one allocation instead of two. This can save a lot of memory in some cases. Thanks to Jonathan Müller for suggesting this technique! :^)
2022-11-27 12:33:02 +01:00
T const* tail_data() const { return reinterpret_cast<T const*>(reinterpret_cast<uintptr_t>(this) + sizeof(Derived)); }
size_t tail_size() const { return m_tail_size; }
protected:
template<typename ActualDerived = Derived, typename... Args>
static NonnullRefPtr<ActualDerived> create(size_t tail_size, SourceRange source_range, Args&&... args)
{
static_assert(sizeof(ActualDerived) == sizeof(Derived), "This leaf class cannot add more members");
static_assert(alignof(ActualDerived) % alignof(T) == 0, "Need padding for tail array");
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
auto* memory = ::operator new(sizeof(ActualDerived) + tail_size * sizeof(T));
LibJS: Add ASTNodeWithTailArray template to pack AST node + array This template allows us to allocate an AST node and an array of some arbitrary type T with one allocation instead of two. This can save a lot of memory in some cases. Thanks to Jonathan Müller for suggesting this technique! :^)
2022-11-27 12:33:02 +01:00
return adopt_ref(*::new (memory) ActualDerived(move(source_range), forward<Args>(args)...));
}
Everywhere: Use ReadonlySpan<T> instead of Span<T const>
2023-02-05 19:02:54 +00:00
ASTNodeWithTailArray(SourceRange source_range, ReadonlySpan<T> values)
LibJS: Add ASTNodeWithTailArray template to pack AST node + array This template allows us to allocate an AST node and an array of some arbitrary type T with one allocation instead of two. This can save a lot of memory in some cases. Thanks to Jonathan Müller for suggesting this technique! :^)
2022-11-27 12:33:02 +01:00
: Base(move(source_range))
, m_tail_size(values.size())
{
VERIFY(values.size() <= NumericLimits<u32>::max());
for (size_t i = 0; i < values.size(); ++i)
new (&tail_data()[i]) T(values[i]);
}
private:
T* tail_data() { return reinterpret_cast<T*>(reinterpret_cast<uintptr_t>(this) + sizeof(Derived)); }
u32 m_tail_size { 0 };
};
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
class Statement : public ASTNode {
LibJS: Parse labelled statements All statements now have an optional label string that can be null.
2020-05-28 11:09:19 -07:00
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit Statement(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Cache bytecode executables on the corresponding AST nodes This greatly reduces the number of compilations necessary when functions declaring local functions are re-executed. For example Octane/typescript.js goes from 58080 bytecode executables to 960.
2023-11-10 17:55:34 +01:00
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
Bytecode::Executable* bytecode_executable() const { return m_bytecode_executable; }
void set_bytecode_executable(Bytecode::Executable* bytecode_executable) { m_bytecode_executable = make_handle(bytecode_executable); }
LibJS: Cache bytecode executables on the corresponding AST nodes This greatly reduces the number of compilations necessary when functions declaring local functions are re-executed. For example Octane/typescript.js goes from 58080 bytecode executables to 960.
2023-11-10 17:55:34 +01:00
private:
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
Handle<Bytecode::Executable> m_bytecode_executable;
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
};
LibJS: Implement LabelledStatement & LabelledEvaluation semantics Instead of slapping 0..N labels on a statement like the current LabelableStatement does, we need the spec's LabelledStatement for a proper implementation of control flow using only completions - it always has one label and one labelled statement - what appears to be 'multiple labels' on the same statement is actually nested LabelledStatements. Note that this is unused yet and will fully replace LabelableStatement in the next commit.
2022-01-05 18:54:25 +01:00
// 14.13 Labelled Statements, https://tc39.es/ecma262/#sec-labelled-statements
LibJS: Mark classes and virtual functions `final` where possible These cases were found with GCC's `-Wsuggest-final-{types,methods}` warnings, which catch calls that could have been devirtualized had we declared the functions `final` in the source. To reproduce, Link Time Optimization needs to be enabled. The easiest way to achieve this is to set the `CMAKE_INTERPROCEDURAL_OPTIMIZATION` cache variable to `ON`. The `.incbin` directive in LibCompress' Brotli decompressor might needs to be changed to an absolute path for this to work. This commit also removes a pair of unused virtual functions.
2023-08-13 12:53:46 +02:00
class LabelledStatement final : public Statement {
LibJS: Implement LabelledStatement & LabelledEvaluation semantics Instead of slapping 0..N labels on a statement like the current LabelableStatement does, we need the spec's LabelledStatement for a proper implementation of control flow using only completions - it always has one label and one labelled statement - what appears to be 'multiple labels' on the same statement is actually nested LabelledStatements. Note that this is unused yet and will fully replace LabelableStatement in the next commit.
2022-01-05 18:54:25 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
LabelledStatement(SourceRange source_range, DeprecatedFlyString label, NonnullRefPtr<Statement const> labelled_item)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Implement LabelledStatement & LabelledEvaluation semantics Instead of slapping 0..N labels on a statement like the current LabelableStatement does, we need the spec's LabelledStatement for a proper implementation of control flow using only completions - it always has one label and one labelled statement - what appears to be 'multiple labels' on the same statement is actually nested LabelledStatements. Note that this is unused yet and will fully replace LabelableStatement in the next commit.
2022-01-05 18:54:25 +01:00
, m_label(move(label))
, m_labelled_item(move(labelled_item))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const;
LibJS: Implement LabelledStatement & LabelledEvaluation semantics Instead of slapping 0..N labels on a statement like the current LabelableStatement does, we need the spec's LabelledStatement for a proper implementation of control flow using only completions - it always has one label and one labelled statement - what appears to be 'multiple labels' on the same statement is actually nested LabelledStatements. Note that this is unused yet and will fully replace LabelableStatement in the next commit.
2022-01-05 18:54:25 +01:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString const& label() const { return m_label; }
DeprecatedFlyString& label() { return m_label; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Statement const> const& labelled_item() const { return m_labelled_item; }
LibJS: Implement LabelledStatement & LabelledEvaluation semantics Instead of slapping 0..N labels on a statement like the current LabelableStatement does, we need the spec's LabelledStatement for a proper implementation of control flow using only completions - it always has one label and one labelled statement - what appears to be 'multiple labels' on the same statement is actually nested LabelledStatements. Note that this is unused yet and will fully replace LabelableStatement in the next commit.
2022-01-05 18:54:25 +01:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_labelled_statement() const final { return true; }
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString m_label;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Statement const> m_labelled_item;
LibJS: Implement LabelledStatement & LabelledEvaluation semantics Instead of slapping 0..N labels on a statement like the current LabelableStatement does, we need the spec's LabelledStatement for a proper implementation of control flow using only completions - it always has one label and one labelled statement - what appears to be 'multiple labels' on the same statement is actually nested LabelledStatements. Note that this is unused yet and will fully replace LabelableStatement in the next commit.
2022-01-05 18:54:25 +01:00
};
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
class LabelableStatement : public Statement {
public:
using Statement::Statement;
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
Vector<DeprecatedFlyString> const& labels() const { return m_labels; }
virtual void add_label(DeprecatedFlyString string) { m_labels.append(move(string)); }
LibJS: Parse labelled statements All statements now have an optional label string that can be null.
2020-05-28 11:09:19 -07:00
protected:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
Vector<DeprecatedFlyString> m_labels;
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
};
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01:00
class IterationStatement : public Statement {
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
public:
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01:00
using Statement::Statement;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const;
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
private:
virtual bool is_iteration_statement() const final { return true; }
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
};
LibJS: Support empty statements We already skipped random semicolons in Parser::parse_program(), but now they are properly matched and parsed as empty statements - and thus recognized as a valid body of an if / else / while / ... statement.
2020-05-03 10:59:00 +01:00
class EmptyStatement final : public Statement {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit EmptyStatement(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Support empty statements We already skipped random semicolons in Parser::parse_program(), but now they are properly matched and parsed as empty statements - and thus recognized as a valid body of an if / else / while / ... statement.
2020-05-03 10:59:00 +01:00
};
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
class ErrorStatement final : public Statement {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit ErrorStatement(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
};
class ExpressionStatement final : public Statement {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ExpressionStatement(SourceRange source_range, NonnullRefPtr<Expression const> expression)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_expression(move(expression))
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Fix "use strict" directive false positives By having the "is this a use strict directive?" logic in parse_string_literal() we would apply it to *any* string literal, which is incorrect and would lead to false positives - e.g.: "use strict" + 1 `"use strict"` "\123"; ({"use strict": ...}) Relevant part from the spec which is now implemented properly: [...] and where each ExpressionStatement in the sequence consists entirely of a StringLiteral token [...] I also got rid of UseStrictDirectiveState which is not needed anymore. Fixes #3903.
2020-11-01 21:49:25 +00:00
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
Expression const& expression() const { return m_expression; }
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_expression_statement() const override { return true; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> 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 19:27:43 +01:00
};
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
template<typename Func, typename... Args>
Everywhere: Run clang-format
2022-10-17 00:06:11 +02:00
concept ThrowCompletionOrVoidFunction = requires(Func func, Args... args) {
Everywhere: Run clang-format The following command was used to clang-format these files: clang-format-16 -i $(find . \ -not \( -path "./\.*" -prune \) \ -not \( -path "./Base/*" -prune \) \ -not \( -path "./Build/*" -prune \) \ -not \( -path "./Toolchain/*" -prune \) \ -not \( -path "./Ports/*" -prune \) \ -type f -name "*.cpp" -o -name "*.h")
2023-07-07 22:44:33 -04:00
{
func(args...)
}
-> SameAs<ThrowCompletionOr<void>>;
};
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
template<typename... Args>
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
class ThrowCompletionOrVoidCallback : public Function<ThrowCompletionOr<void>(Args...)> {
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
public:
template<typename CallableType>
Everywhere: Run clang-format
2022-10-17 00:06:11 +02:00
ThrowCompletionOrVoidCallback(CallableType&& callable)
requires(VoidFunction<CallableType, Args...>)
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
: Function<ThrowCompletionOr<void>(Args...)>([callable = forward<CallableType>(callable)](Args... args) {
LibJS: Fix improper usages of forward as flagged by SonarCloud
2021-10-03 13:58:52 +02:00
callable(args...);
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
return ThrowCompletionOr<void> {};
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
})
{
}
template<typename CallableType>
Everywhere: Run clang-format
2022-10-17 00:06:11 +02:00
ThrowCompletionOrVoidCallback(CallableType&& callable)
requires(ThrowCompletionOrVoidFunction<CallableType, Args...>)
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
: Function<ThrowCompletionOr<void>(Args...)>(forward<CallableType>(callable))
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
{
}
};
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01: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 19:42:11 +01:00
public:
template<typename T, typename... Args>
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
T& append(SourceRange range, Args&&... args)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
auto child = create_ast_node<T>(range, forward<Args>(args)...);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
m_children.append(move(child));
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
return static_cast<T&>(*m_children.last());
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
void append(NonnullRefPtr<Statement const> 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 19:27:43 +01: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 19:42:11 +01:00
LibJS: Call shrink_to_fit() on various Vectors created during parse Vectors that stick around in the AST were wasting a fair bit of memory due to the growth padding we keep by default. This patch goes after some of these vectors with the shrink_to_fit() stick to reduce waste. Since the AST can stay around for a long time, it is worth making an effort to shrink it down when we have a chance.
2022-11-26 20:45:06 +01:00
void shrink_to_fit()
{
m_children.shrink_to_fit();
m_lexical_declarations.shrink_to_fit();
m_var_declarations.shrink_to_fit();
m_functions_hoistable_with_annexB_extension.shrink_to_fit();
}
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<Statement const>> const& 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 19:42:11 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) 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 19:42:11 +01:00
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
void add_var_scoped_declaration(NonnullRefPtr<Declaration const> variables);
void add_lexical_declaration(NonnullRefPtr<Declaration const> variables);
void add_hoisted_function(NonnullRefPtr<FunctionDeclaration const> declaration);
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Skip declarative env in block statement without lexical decls The idea here is simple: If the block statement doesn't contain any lexical declarations, we don't need to allocate, initialize and eventually garbage collect a new declarative environment. This even makes lookups across nested blocks slightly faster as we don't have to traverse a chain of empty environments anymore - instead, the execution context just stores the outermost non-empty one. This doesn't speed up test-js considerably, but has a noticeable effect on test262 and real-world web content :^)
2021-10-05 12:59:04 +01:00
[[nodiscard]] bool has_lexical_declarations() const { return !m_lexical_declarations.is_empty(); }
[[nodiscard]] bool has_var_declarations() const { return !m_var_declarations.is_empty(); }
LibJS: Add ScopeNode accessors for declaration counts
2021-10-08 02:22:02 +02:00
[[nodiscard]] size_t var_declaration_count() const { return m_var_declarations.size(); }
[[nodiscard]] size_t lexical_declaration_count() const { return m_lexical_declarations.size(); }
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
ThrowCompletionOr<void> for_each_lexically_scoped_declaration(ThrowCompletionOrVoidCallback<Declaration const&>&& callback) const;
LibJS: Use Identifier to represent FunctionParameter name Using identifier instead of string allows to store supplemental information about whether it can be represented as local variable.
2023-07-06 17:49:38 +02:00
ThrowCompletionOr<void> for_each_lexically_declared_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&& callback) const;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Add ScopeNode::for_each_var_declared_identifier() The same as for_each_var_declared_name but for identifiers.
2023-07-05 02:10:40 +02:00
ThrowCompletionOr<void> for_each_var_declared_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&& callback) const;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
ThrowCompletionOr<void> for_each_var_function_declaration_in_reverse_order(ThrowCompletionOrVoidCallback<FunctionDeclaration const&>&& callback) const;
ThrowCompletionOr<void> for_each_var_scoped_variable_declaration(ThrowCompletionOrVoidCallback<VariableDeclaration const&>&& callback) const;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Make BlockDeclarationInstantiation take a VM& There's no need for this to require an AST Interpreter.
2023-06-16 16:12:11 +02:00
void block_declaration_instantiation(VM&, Environment*) const;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Convert ScopeNode declaration functions to ThrowCompletionOr This removes a number of vm.exception() checks which are now caught directly by TRY. Make use of these checks in {Global, Eval}DeclarationInstantiation and while we're here add spec comments.
2022-02-07 13:31:01 +01:00
ThrowCompletionOr<void> for_each_function_hoistable_with_annexB_extension(ThrowCompletionOrVoidCallback<FunctionDeclaration&>&& callback) const;
LibJS: Add strict mode Adds the ability for a scope (either a function or the entire program) to be in strict mode. Scopes default to non-strict mode. There are two ways to determine the strict-ness of the JS engine: 1. In the parser, this can be accessed with the parser_state variable m_is_strict_mode boolean. If true, the Parser is currently parsing in strict mode. This is done so that the Parser can generate syntax errors at parse time, which is required in some cases. 2. With Interpreter.is_strict_mode(). This allows strict mode checking at runtime as opposed to compile time. Additionally, in order to test this, a global isStrictMode() function has been added to the JS ReplObject under the test-mode flag.
2020-05-27 22:22:08 -07:00
LibJS: Update parser to detect if identifier refer a "local" variable This modification enables the parser to determine whether an identifier used within a function refers to a local variable or not. In this context, a local identifier means that it is not captured by any nested function declaration which means it modified only from inside a function. The information about whether identifier is local is stored inside Identifier AST node and also contains information about the index of local variable inside a function and information about total number of local variables used by a function is stored in function nodes.
2023-07-05 00:14:41 +02:00
Vector<DeprecatedFlyString> const& local_variables_names() const { return m_local_variables_names; }
size_t add_local_variable(DeprecatedFlyString name)
{
auto index = m_local_variables_names.size();
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
m_local_variables_names.append(move(name));
LibJS: Update parser to detect if identifier refer a "local" variable This modification enables the parser to determine whether an identifier used within a function refers to a local variable or not. In this context, a local identifier means that it is not captured by any nested function declaration which means it modified only from inside a function. The information about whether identifier is local is stored inside Identifier AST node and also contains information about the index of local variable inside a function and information about total number of local variables used by a function is stored in function nodes.
2023-07-05 00:14:41 +02:00
return index;
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
protected:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit ScopeNode(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_scope_node() const final { return true; }
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<Statement const>> m_children;
Vector<NonnullRefPtr<Declaration const>> m_lexical_declarations;
Vector<NonnullRefPtr<Declaration const>> m_var_declarations;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<FunctionDeclaration const>> m_functions_hoistable_with_annexB_extension;
LibJS: Update parser to detect if identifier refer a "local" variable This modification enables the parser to determine whether an identifier used within a function refers to a local variable or not. In this context, a local identifier means that it is not captured by any nested function declaration which means it modified only from inside a function. The information about whether identifier is local is stored inside Identifier AST node and also contains information about the index of local variable inside a function and information about total number of local variables used by a function is stored in function nodes.
2023-07-05 00:14:41 +02:00
Vector<DeprecatedFlyString> m_local_variables_names;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
};
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
// ImportEntry Record, https://tc39.es/ecma262/#table-importentry-record-fields
struct ImportEntry {
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString import_name; // [[ImportName]] if a String
DeprecatedFlyString local_name; // [[LocalName]]
bool is_namespace { false }; // [[ImportName]] if `namespace-object`
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
ImportEntry(DeprecatedFlyString import_name_, DeprecatedFlyString local_name_, bool is_namespace_ = false)
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
: import_name(move(import_name_))
, local_name(move(local_name_))
, is_namespace(is_namespace_)
{
VERIFY(!is_namespace || import_name.is_null());
}
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
ModuleRequest const& module_request() const
{
VERIFY(m_module_request);
return *m_module_request;
}
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
private:
friend class ImportStatement;
ModuleRequest* m_module_request; // [[ModuleRequest]]
};
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
class ImportStatement final : public Statement {
public:
LibJS: Parse assert clauses of in- and export statements Based on proposal: https://tc39.es/proposal-import-assertions Since imports are not supported yet this is not functional.
2021-12-20 15:29:25 +01:00
explicit ImportStatement(SourceRange source_range, ModuleRequest from_module, Vector<ImportEntry> entries = {})
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Parse assert clauses of in- and export statements Based on proposal: https://tc39.es/proposal-import-assertions Since imports are not supported yet this is not functional.
2021-12-20 15:29:25 +01:00
, m_module_request(move(from_module))
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
, m_entries(move(entries))
{
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
for (auto& entry : m_entries)
entry.m_module_request = &m_module_request;
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS/Bytecode: Handle ImportStatement in codegen There is nothing to do here at runtime as imports are handled in `Interpreter::run`.
2023-06-27 20:46:41 +02:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
bool has_bound_name(DeprecatedFlyString const& name) const;
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
Vector<ImportEntry> const& entries() const { return m_entries; }
ModuleRequest const& module_request() const { return m_module_request; }
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
private:
LibJS: Parse assert clauses of in- and export statements Based on proposal: https://tc39.es/proposal-import-assertions Since imports are not supported yet this is not functional.
2021-12-20 15:29:25 +01:00
ModuleRequest m_module_request;
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
Vector<ImportEntry> m_entries;
};
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
// ExportEntry Record, https://tc39.es/ecma262/#table-exportentry-records
struct ExportEntry {
enum class Kind {
NamedExport,
ModuleRequestAll,
ModuleRequestAllButDefault,
// EmptyNamedExport is a special type for export {} from "module",
// which should import the module without getting any of the exports
// however we don't want give it a fake export name which may get
// duplicates
EmptyNamedExport,
} kind;
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString export_name; // [[ExportName]]
DeprecatedFlyString local_or_import_name; // Either [[ImportName]] or [[LocalName]]
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
ExportEntry(Kind export_kind, DeprecatedFlyString export_name_, DeprecatedFlyString local_or_import_name_)
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
: kind(export_kind)
, export_name(move(export_name_))
, local_or_import_name(move(local_or_import_name_))
{
}
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
bool is_module_request() const
{
return m_module_request != nullptr;
}
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
static ExportEntry indirect_export_entry(ModuleRequest const& module_request, DeprecatedFlyString export_name, DeprecatedFlyString import_name)
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
{
ExportEntry entry { Kind::NamedExport, move(export_name), move(import_name) };
entry.m_module_request = &module_request;
return entry;
}
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
ModuleRequest const& module_request() const
{
VERIFY(m_module_request);
return *m_module_request;
}
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
private:
ModuleRequest const* m_module_request { nullptr }; // [[ModuleRequest]]
friend class ExportStatement;
LibJS: Follow the spec with storing im- and export entries Because we can have arbitrary in- and export names with strings we can have '*' and '' which means using '*' as an indicating namespace imports failed / behaved incorrectly for string imports '*'. We now use more specific types to indicate these special states instead of these 'magic' string values. Do note that 'default' is not actually a magic string value but one specified by the spec. And you can in fact export the default value by doing: `export { 1 as default }`.
2022-01-27 01:54:47 +01:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
public:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
static ExportEntry named_export(DeprecatedFlyString export_name, DeprecatedFlyString local_name)
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
{
return ExportEntry { Kind::NamedExport, move(export_name), move(local_name) };
}
LibJS: Follow the spec with storing im- and export entries Because we can have arbitrary in- and export names with strings we can have '*' and '' which means using '*' as an indicating namespace imports failed / behaved incorrectly for string imports '*'. We now use more specific types to indicate these special states instead of these 'magic' string values. Do note that 'default' is not actually a magic string value but one specified by the spec. And you can in fact export the default value by doing: `export { 1 as default }`.
2022-01-27 01:54:47 +01:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
static ExportEntry all_but_default_entry()
{
return ExportEntry { Kind::ModuleRequestAllButDefault, {}, {} };
}
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
static ExportEntry all_module_request(DeprecatedFlyString export_name)
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
{
return ExportEntry { Kind::ModuleRequestAll, move(export_name), {} };
}
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
static ExportEntry empty_named_export()
{
return ExportEntry { Kind::EmptyNamedExport, {}, {} };
}
};
LibJS: Handle empty named export This is an export which looks like `export {} from "module"`, and although it doesn't have any real export entries it should still add "module" to the required modules to load.
2022-08-29 22:12:25 +02:00
LibJS: Move {Import,Export}Entry out of {Import,Export}Statement By making these be standalone instead of nested structs, we can forward declare them. This will allow us to stop including AST.h in some places.
2022-11-23 12:16:51 +01:00
class ExportStatement final : public Statement {
public:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
static DeprecatedFlyString local_name_for_default;
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ExportStatement(SourceRange source_range, RefPtr<ASTNode const> statement, Vector<ExportEntry> entries, bool is_default_export, ModuleRequest module_request)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
, m_statement(move(statement))
, m_entries(move(entries))
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
, m_is_default_export(is_default_export)
LibJS: Follow the spec with storing im- and export entries Because we can have arbitrary in- and export names with strings we can have '*' and '' which means using '*' as an indicating namespace imports failed / behaved incorrectly for string imports '*'. We now use more specific types to indicate these special states instead of these 'magic' string values. Do note that 'default' is not actually a magic string value but one specified by the spec. And you can in fact export the default value by doing: `export { 1 as default }`.
2022-01-27 01:54:47 +01:00
, m_module_request(move(module_request))
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
{
LibJS: Follow the spec with storing im- and export entries Because we can have arbitrary in- and export names with strings we can have '*' and '' which means using '*' as an indicating namespace imports failed / behaved incorrectly for string imports '*'. We now use more specific types to indicate these special states instead of these 'magic' string values. Do note that 'default' is not actually a magic string value but one specified by the spec. And you can in fact export the default value by doing: `export { 1 as default }`.
2022-01-27 01:54:47 +01:00
if (!m_module_request.module_specifier.is_null()) {
for (auto& entry : m_entries)
entry.m_module_request = &m_module_request;
}
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS/Bytecode: Add some basic codegen for ExportStatement This is by no means complete, but at least a bunch of test-js and test262 tests start working. :^)
2023-06-24 16:07:43 +02:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
bool has_export(DeprecatedFlyString const& export_name) const;
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
LibJS: Split parsing program to script and module separately This allows us to only perform checks like export bindings existing only for modules. Also this makes it easier to set strict and other state variables with TemporaryChanges.
2021-11-27 00:01:23 +01:00
bool has_statement() const { return m_statement; }
Vector<ExportEntry> const& entries() const { return m_entries; }
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
bool is_default_export() const { return m_is_default_export; }
ASTNode const& statement() const
{
VERIFY(m_statement);
return *m_statement;
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ModuleRequest const& module_request() const
LibJS: Implement the import assertions proposal The hard part of parsing them in import statements and calls was already done so this is just removing some check which threw before on assertions. And filtering the assertions based on the result of a new host hook.
2022-01-27 02:44:03 +01:00
{
VERIFY(!m_module_request.module_specifier.is_null());
return m_module_request;
}
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<ASTNode const> m_statement;
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
Vector<ExportEntry> m_entries;
LibJS: Make parsing import and export entries follow the spec The big changes are: - Allow strings as Module{Export, Import}Name - Properly track declarations in default export statements However, the spec is a little strange in that it allows function and class declarations without a name in default export statements. This is quite hard to fully implement without rewriting more of the parser so for now this behavior is emulated by faking things with function and class expressions. See the comments in parse_export_statement for details on the hacks and where it goes wrong.
2022-01-16 23:51:28 +01:00
bool m_is_default_export { false };
LibJS: Follow the spec with storing im- and export entries Because we can have arbitrary in- and export names with strings we can have '*' and '' which means using '*' as an indicating namespace imports failed / behaved incorrectly for string imports '*'. We now use more specific types to indicate these special states instead of these 'magic' string values. Do note that 'default' is not actually a magic string value but one specified by the spec. And you can in fact export the default value by doing: `export { 1 as default }`.
2022-01-27 01:54:47 +01:00
ModuleRequest m_module_request;
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class Program final : public ScopeNode {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
public:
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 17:30:37 +02:00
enum class Type {
Script,
Module
};
explicit Program(SourceRange source_range, Type program_type)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ScopeNode(move(source_range))
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 17:30:37 +02:00
, m_type(program_type)
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-03 17:02:43 -07:00
bool is_strict_mode() const { return m_is_strict_mode; }
void set_strict_mode() { m_is_strict_mode = true; }
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 17:30:37 +02:00
Type type() const { return m_type; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
void append_import(NonnullRefPtr<ImportStatement const> import_statement)
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
{
m_imports.append(import_statement);
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
append(move(import_statement));
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
void append_export(NonnullRefPtr<ExportStatement const> export_statement)
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
{
m_exports.append(export_statement);
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
append(move(export_statement));
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
}
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<ImportStatement const>> const& imports() const { return m_imports; }
Vector<NonnullRefPtr<ExportStatement const>> const& exports() const { return m_exports; }
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<ImportStatement const>>& imports() { return m_imports; }
Vector<NonnullRefPtr<ExportStatement const>>& exports() { return m_exports; }
LibJS: Implement the import assertions proposal The hard part of parsing them in import statements and calls was already done so this is just removing some check which threw before on assertions. And filtering the assertions based on the result of a new host hook.
2022-01-27 02:44:03 +01:00
LibJS: Track whether a program has a top level await statement
2022-01-18 18:55:19 +01:00
bool has_top_level_await() const { return m_has_top_level_await; }
void set_has_top_level_await() { m_has_top_level_await = true; }
LibJS: Make GlobalDeclarationInstantiation take a VM& This doesn't need to take an AST Interpreter&.
2023-06-15 10:37:42 +02:00
ThrowCompletionOr<void> global_declaration_instantiation(VM&, GlobalEnvironment&) const;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_program() const override { return true; }
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-03 17:02:43 -07:00
bool m_is_strict_mode { false };
LibJS: Add a mode to parse JS as a module In a module strict mode should be enabled at the start of parsing and we allow import and export statements.
2021-08-14 17:30:37 +02:00
Type m_type { Type::Script };
LibJS: Parse and partially execute import and export statements We produce the import and export entries as per the spec. However we do not yet verify that named things that are exported are declared somewhere.
2021-08-14 17:42:30 +02:00
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<ImportStatement const>> m_imports;
Vector<NonnullRefPtr<ExportStatement const>> m_exports;
LibJS: Track whether a program has a top level await statement
2022-01-18 18:55:19 +01:00
bool m_has_top_level_await { 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 19:42:11 +01:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class BlockStatement final : public ScopeNode {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit BlockStatement(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ScopeNode(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
};
class FunctionBody final : public ScopeNode {
public:
explicit FunctionBody(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ScopeNode(move(source_range))
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
{
}
void set_strict_mode() { m_in_strict_mode = true; }
bool in_strict_mode() const { return m_in_strict_mode; }
private:
bool m_in_strict_mode { 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 19:42:11 +01:00
};
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
class Expression : public ASTNode {
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit Expression(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
};
LibJS: Add Declaration class to the AST This is just here to make the AST class hierarchy more spec-like.
2020-04-04 21:32:10 +02:00
class Declaration : public Statement {
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit Declaration(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
virtual ThrowCompletionOr<void> for_each_bound_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&& callback) const = 0;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
// 8.1.3 Static Semantics: IsConstantDeclaration, https://tc39.es/ecma262/#sec-static-semantics-isconstantdeclaration
virtual bool is_constant_declaration() const { return false; }
virtual bool is_lexical_declaration() const { return false; }
LibJS: Add Declaration class to the AST This is just here to make the AST class hierarchy more spec-like.
2020-04-04 21:32:10 +02:00
};
LibJS: Distinguish between statement and declaration This separates matching/parsing of statements and declarations and fixes a few edge cases where the parser would incorrectly accept a declaration where only a statement is allowed - for example: if (foo) const a = 1; for (var bar;;) function b() {} while (baz) class c {}
2020-10-22 23:30:07 +01:00
class ErrorDeclaration final : public Declaration {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit ErrorDeclaration(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Declaration(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
ThrowCompletionOr<void> for_each_bound_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&&) const override
{
VERIFY_NOT_REACHED();
}
LibJS: Distinguish between statement and declaration This separates matching/parsing of statements and declarations and fixes a few edge cases where the parser would incorrectly accept a declaration where only a statement is allowed - for example: if (foo) const a = 1; for (var bar;;) function b() {} while (baz) class c {}
2020-10-22 23:30:07 +01:00
};
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
struct BindingPattern : RefCounted<BindingPattern> {
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
// This covers both BindingProperty and BindingElement, hence the more generic name
struct BindingEntry {
// If this entry represents a BindingElement, then name will be Empty
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Variant<NonnullRefPtr<Identifier const>, NonnullRefPtr<Expression const>, Empty> name {};
Variant<NonnullRefPtr<Identifier const>, NonnullRefPtr<BindingPattern const>, NonnullRefPtr<MemberExpression const>, Empty> alias {};
RefPtr<Expression const> initializer {};
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
bool is_rest { false };
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
bool is_elision() const { return name.has<Empty>() && alias.has<Empty>(); }
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
};
enum class Kind {
Array,
Object,
};
void dump(int indent) const;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
ThrowCompletionOr<void> for_each_bound_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&& callback) const;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
bool contains_expression() const;
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
Vector<BindingEntry> entries;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
Kind kind { Kind::Object };
};
LibJS: Use Identifier to represent name of FunctionNode
2023-07-02 00:35:51 +03:00
class Identifier final : public Expression {
public:
explicit Identifier(SourceRange source_range, DeprecatedFlyString string)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Use Identifier to represent name of FunctionNode
2023-07-02 00:35:51 +03:00
, m_string(move(string))
{
}
DeprecatedFlyString const& string() const { return m_string; }
bool is_local() const { return m_local_variable_index.has_value(); }
size_t local_variable_index() const
{
VERIFY(m_local_variable_index.has_value());
return m_local_variable_index.value();
}
void set_local_variable_index(size_t index) { m_local_variable_index = index; }
LibJS: Identify global variables during parsing Identifying global variables during parsing will make it possible to generate special optimized instruction to access them in upcoming changes.
2023-07-12 04:02:27 +02:00
bool is_global() const { return m_is_global; }
void set_is_global() { m_is_global = true; }
LibJS: Use Identifier to represent name of FunctionNode
2023-07-02 00:35:51 +03:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Use Identifier to represent name of FunctionNode
2023-07-02 00:35:51 +03:00
private:
virtual bool is_identifier() const override { return true; }
DeprecatedFlyString m_string;
Optional<size_t> m_local_variable_index;
LibJS: Identify global variables during parsing Identifying global variables during parsing will make it possible to generate special optimized instruction to access them in upcoming changes.
2023-07-12 04:02:27 +02:00
bool m_is_global { false };
LibJS: Use Identifier to represent name of FunctionNode
2023-07-02 00:35:51 +03:00
};
LibJS: Use Identifier to represent FunctionParameter name Using identifier instead of string allows to store supplemental information about whether it can be represented as local variable.
2023-07-06 17:49:38 +02:00
struct FunctionParameter {
Variant<NonnullRefPtr<Identifier const>, NonnullRefPtr<BindingPattern const>> binding;
RefPtr<Expression const> default_value;
bool is_rest { false };
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
Handle<Bytecode::Executable> bytecode_executable {};
LibJS: Use Identifier to represent FunctionParameter name Using identifier instead of string allows to store supplemental information about whether it can be represented as local variable.
2023-07-06 17:49:38 +02:00
};
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
class FunctionNode {
public:
LibJS: Use Identifier to represent name of FunctionNode
2023-07-02 00:35:51 +03:00
StringView name() const { return m_name ? m_name->string().view() : ""sv; }
LibJS: Use local variables for function declarations when possible Previously, the usage of local variables was limited for all function declarations. This change relaxes the restriction and only prohibits locals for hoistable annexB declarations.
2023-07-08 19:31:41 +02:00
RefPtr<Identifier const> name_identifier() const { return m_name; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString const& source_text() const { return m_source_text; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Statement const& body() const { return *m_body; }
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
Vector<FunctionParameter> const& parameters() const { return m_parameters; }
LibJS: Hoist function declarations This patch adds function declaration hoisting. The mechanism is similar to var hoisting. Hoisted function declarations are to be put before the hoisted var declarations, hence they have to be treated separately.
2020-06-04 14:48:36 +02:00
i32 function_length() const { return m_function_length; }
LibJS: Update parser to detect if identifier refer a "local" variable This modification enables the parser to determine whether an identifier used within a function refers to a local variable or not. In this context, a local identifier means that it is not captured by any nested function declaration which means it modified only from inside a function. The information about whether identifier is local is stored inside Identifier AST node and also contains information about the index of local variable inside a function and information about total number of local variables used by a function is stored in function nodes.
2023-07-05 00:14:41 +02:00
Vector<DeprecatedFlyString> const& local_variables_names() const { return m_local_variables_names; }
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-03 17:02:43 -07:00
bool is_strict_mode() const { return m_is_strict_mode; }
LibJS: Add an optimization to avoid needless arguments object creation This gives FunctionNode a "might need arguments object" boolean flag and sets it based on the simplest possible heuristic for this: if we encounter an identifier called "arguments" or "eval" up to the next (nested) function declaration or expression, we won't need an arguments object. Otherwise, we *might* need one - the final decision is made in the FunctionDeclarationInstantiation AO. Now, this is obviously not perfect. Even if you avoid eval, something like `foo.arguments` will still trigger a false positive - but it's a start and already massively cuts down on needlessly allocated objects, especially in real-world code that is often minified, and so a full "arguments" identifier will be an actual arguments object more often than not. To illustrate the actual impact of this change, here's the number of allocated arguments objects during a full test-js run: Before: - Unmapped arguments objects: 78765 - Mapped arguments objects: 2455 After: - Unmapped arguments objects: 18 - Mapped arguments objects: 37 This results in a ~5% speedup of test-js on my Linux host machine, and about 3.5% on i686 Serenity in QEMU (warm runs, average of 5). The following microbenchmark (calling an empty function 1M times) runs 25% faster on Linux and 45% on Serenity: function foo() {} for (var i = 0; i < 1_000_000; ++i) foo(); test262 reports no changes in either direction, apart from a speedup :^)
2021-10-05 08:44:58 +01:00
bool might_need_arguments_object() const { return m_might_need_arguments_object; }
LibJS: Propagate "contains direct call to eval()" flag from parser We now propagate this flag to FunctionDeclaration, and then also into ECMAScriptFunctionObject. This will be used to disable optimizations that aren't safe in the presence of direct eval().
2021-10-08 12:43:38 +02:00
bool contains_direct_call_to_eval() const { return m_contains_direct_call_to_eval; }
LibJS: Move is_arrow_function() from FunctionExpression to FunctionNode This will make it easier to write bytecode generation for function expressions in just a moment.
2021-06-11 10:45:49 +02:00
bool is_arrow_function() const { return m_is_arrow_function; }
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11 03:38:05 +04:30
FunctionKind kind() const { return m_kind; }
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
protected:
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
FunctionNode(RefPtr<Identifier const> name, ByteString source_text, NonnullRefPtr<Statement const> body, Vector<FunctionParameter> parameters, i32 function_length, FunctionKind kind, bool is_strict_mode, bool might_need_arguments_object, bool contains_direct_call_to_eval, bool is_arrow_function, Vector<DeprecatedFlyString> local_variables_names)
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
: m_name(move(name))
LibJS: Capture source text of FunctionNode and ClassExpression
2022-01-18 23:46:16 +00:00
, m_source_text(move(source_text))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
, m_body(move(body))
LibJS: Allow functions to take arguments (#1405)
2020-03-12 19:22:13 +08:00
, m_parameters(move(parameters))
LibJS: Function.length respects default and rest parameters "[Function.length is] the number of formal parameters. This number excludes the rest parameter and only includes parameters before the first one with a default value." - MDN
2020-05-05 20:02:14 -07:00
, m_function_length(function_length)
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11 03:38:05 +04:30
, m_kind(kind)
LibJS: Strict mode is now handled by Functions and Programs, not Blocks Since blocks can't be strict by themselves, it makes no sense for them to store whether or not they are strict. Strict-ness is now stored in the Program and FunctionNode ASTNodes. Fixes issue #3641
2020-10-03 17:02:43 -07:00
, m_is_strict_mode(is_strict_mode)
LibJS: Add an optimization to avoid needless arguments object creation This gives FunctionNode a "might need arguments object" boolean flag and sets it based on the simplest possible heuristic for this: if we encounter an identifier called "arguments" or "eval" up to the next (nested) function declaration or expression, we won't need an arguments object. Otherwise, we *might* need one - the final decision is made in the FunctionDeclarationInstantiation AO. Now, this is obviously not perfect. Even if you avoid eval, something like `foo.arguments` will still trigger a false positive - but it's a start and already massively cuts down on needlessly allocated objects, especially in real-world code that is often minified, and so a full "arguments" identifier will be an actual arguments object more often than not. To illustrate the actual impact of this change, here's the number of allocated arguments objects during a full test-js run: Before: - Unmapped arguments objects: 78765 - Mapped arguments objects: 2455 After: - Unmapped arguments objects: 18 - Mapped arguments objects: 37 This results in a ~5% speedup of test-js on my Linux host machine, and about 3.5% on i686 Serenity in QEMU (warm runs, average of 5). The following microbenchmark (calling an empty function 1M times) runs 25% faster on Linux and 45% on Serenity: function foo() {} for (var i = 0; i < 1_000_000; ++i) foo(); test262 reports no changes in either direction, apart from a speedup :^)
2021-10-05 08:44:58 +01:00
, m_might_need_arguments_object(might_need_arguments_object)
LibJS: Propagate "contains direct call to eval()" flag from parser We now propagate this flag to FunctionDeclaration, and then also into ECMAScriptFunctionObject. This will be used to disable optimizations that aren't safe in the presence of direct eval().
2021-10-08 12:43:38 +02:00
, m_contains_direct_call_to_eval(contains_direct_call_to_eval)
LibJS: Move is_arrow_function() from FunctionExpression to FunctionNode This will make it easier to write bytecode generation for function expressions in just a moment.
2021-06-11 10:45:49 +02:00
, m_is_arrow_function(is_arrow_function)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
, m_local_variables_names(move(local_variables_names))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
LibJS: Add an optimization to avoid needless arguments object creation This gives FunctionNode a "might need arguments object" boolean flag and sets it based on the simplest possible heuristic for this: if we encounter an identifier called "arguments" or "eval" up to the next (nested) function declaration or expression, we won't need an arguments object. Otherwise, we *might* need one - the final decision is made in the FunctionDeclarationInstantiation AO. Now, this is obviously not perfect. Even if you avoid eval, something like `foo.arguments` will still trigger a false positive - but it's a start and already massively cuts down on needlessly allocated objects, especially in real-world code that is often minified, and so a full "arguments" identifier will be an actual arguments object more often than not. To illustrate the actual impact of this change, here's the number of allocated arguments objects during a full test-js run: Before: - Unmapped arguments objects: 78765 - Mapped arguments objects: 2455 After: - Unmapped arguments objects: 18 - Mapped arguments objects: 37 This results in a ~5% speedup of test-js on my Linux host machine, and about 3.5% on i686 Serenity in QEMU (warm runs, average of 5). The following microbenchmark (calling an empty function 1M times) runs 25% faster on Linux and 45% on Serenity: function foo() {} for (var i = 0; i < 1_000_000; ++i) foo(); test262 reports no changes in either direction, apart from a speedup :^)
2021-10-05 08:44:58 +01:00
if (m_is_arrow_function)
VERIFY(!m_might_need_arguments_object);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
void dump(int indent, ByteString const& class_name) const;
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
LibJS: Use Identifier to represent name of FunctionNode
2023-07-02 00:35:51 +03:00
RefPtr<Identifier const> m_name { nullptr };
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
private:
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString m_source_text;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Statement const> m_body;
LibJS: Make FunctionNode::Parameter be a standalone FunctionParameter This will allow us to forward declare it and avoid including AST.h in a number of places.
2022-11-23 13:12:36 +01:00
Vector<FunctionParameter> const m_parameters;
LibJS: Cache bytecode executables on the corresponding AST nodes This greatly reduces the number of compilations necessary when functions declaring local functions are re-executed. For example Octane/typescript.js goes from 58080 bytecode executables to 960.
2023-11-10 17:55:34 +01:00
i32 const m_function_length;
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11 03:38:05 +04:30
FunctionKind m_kind;
LibJS: Shrink FunctionNode by using bitfields By making the boolean members be bitfields, we shrink FunctionNode by a total of 8 bytes.
2022-11-26 20:07:09 +01:00
bool m_is_strict_mode : 1 { false };
bool m_might_need_arguments_object : 1 { false };
bool m_contains_direct_call_to_eval : 1 { false };
bool m_is_arrow_function : 1 { false };
LibJS: Update parser to detect if identifier refer a "local" variable This modification enables the parser to determine whether an identifier used within a function refers to a local variable or not. In this context, a local identifier means that it is not captured by any nested function declaration which means it modified only from inside a function. The information about whether identifier is local is stored inside Identifier AST node and also contains information about the index of local variable inside a function and information about total number of local variables used by a function is stored in function nodes.
2023-07-05 00:14:41 +02:00
Vector<DeprecatedFlyString> m_local_variables_names;
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
};
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 21:32:10 +02: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 11:12:08 +01: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 11:52:56 +01:00
static bool must_have_name() { return true; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
FunctionDeclaration(SourceRange source_range, RefPtr<Identifier const> name, ByteString source_text, NonnullRefPtr<Statement const> body, Vector<FunctionParameter> parameters, i32 function_length, FunctionKind kind, bool is_strict_mode, bool might_need_arguments_object, bool contains_direct_call_to_eval, Vector<DeprecatedFlyString> local_variables_names)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Declaration(move(source_range))
, FunctionNode(move(name), move(source_text), move(body), move(parameters), function_length, kind, is_strict_mode, might_need_arguments_object, contains_direct_call_to_eval, false, move(local_variables_names))
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
{
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
ThrowCompletionOr<void> for_each_bound_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&&) const override;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
virtual bool is_function_declaration() const override { return true; }
void set_should_do_additional_annexB_steps() { m_is_hoisted = true; }
private:
bool m_is_hoisted { 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 19:42:11 +01:00
};
LibJS: Fix style inconsistencies in AST.h (#2403) Our current configuration clang-format allows both of these styles: ------------------ class A : B , C { ----------------- class A : B , C { ------------------ I was not able to find a setting of clang-format to only allow the latter style (or disallow the first style), but let's at least be consistent with the style within a file.
2020-05-26 19:52:03 +02:00
class FunctionExpression final
: public Expression
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
, public FunctionNode {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01: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 11:52:56 +01:00
static bool must_have_name() { return false; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
FunctionExpression(SourceRange source_range, RefPtr<Identifier const> name, ByteString source_text, NonnullRefPtr<Statement const> body, Vector<FunctionParameter> parameters, i32 function_length, FunctionKind kind, bool is_strict_mode, bool might_need_arguments_object, bool contains_direct_call_to_eval, Vector<DeprecatedFlyString> local_variables_names, bool is_arrow_function = false)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
, FunctionNode(move(name), move(source_text), move(body), move(parameters), function_length, kind, is_strict_mode, might_need_arguments_object, contains_direct_call_to_eval, is_arrow_function, move(local_variables_names))
LibJS: Add FunctionExpression AST node Most of the code is shared with FunctionDeclaration, so the shared bits are moved up into a common base called FunctionNode.
2020-03-19 11:12:08 +01:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode_with_lhs_name(Bytecode::Generator&, Optional<Bytecode::IdentifierTableIndex> lhs_name, Optional<Bytecode::Operand> preferred_dst = {}) const;
LibJS: Add bytecode generation for FunctionExpression :^)
2021-06-11 10:46:46 +02:00
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
bool has_name() const { return !name().is_empty(); }
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
Value instantiate_ordinary_function_expression(VM&, DeprecatedFlyString given_name) const;
LibJS: Add fast_is<T>() for FunctionExpression and ClassExpression Spotted RTTI for these two above 1% in a profile.
2021-10-07 12:05:13 +02:00
private:
virtual bool is_function_expression() 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 19:42:11 +01:00
};
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
class ErrorExpression final : public Expression {
public:
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
explicit ErrorExpression(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Add Javascript lexer and parser This adds a basic Javascript lexer and parser. It can parse the currently existing demo programs. More work needs to be done to turn it into a complete parser than can parse arbitrary JS Code. The lexer outputs tokens with preceeding whitespace and comments in the trivia member. This should allow us to generate the exact source code by concatenating the generated tokens. The parser is written in a way that it always returns a complete syntax tree. Error conditions are represented as nodes in the tree. This simplifies the code and allows it to be used as an early stage parser, e.g for parsing JS documents in an IDE while editing the source code.:
2020-03-11 19:27:43 +01:00
};
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
class YieldExpression final : public Expression {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
explicit YieldExpression(SourceRange source_range, RefPtr<Expression const> argument, bool is_yield_from)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
, m_argument(move(argument))
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 15:46:41 +04:30
, m_is_yield_from(is_yield_from)
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const* argument() const { return m_argument; }
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 15:46:41 +04:30
bool is_yield_from() const { return m_is_yield_from; }
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<Expression const> m_argument;
LibJS: Correctly parse yield-from expressions This commit implements parsing for `yield *expr`, and the multiple ways something can or can't be parsed like that. Also makes yield-from a TODO in the bytecode generator. Behold, the glory of javascript syntax: ```js // 'yield' = expression in generators. function* foo() { yield *bar; // <- Syntax error here, expression can't start with * } // 'yield' = identifier anywhere else. function foo() { yield *bar; // Perfectly fine, this is just `yield * bar` } ```
2021-06-14 15:46:41 +04:30
bool m_is_yield_from { false };
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
};
LibJS: Add support for await expressions
2021-11-09 22:52:21 +02:00
class AwaitExpression final : public Expression {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
explicit AwaitExpression(SourceRange source_range, NonnullRefPtr<Expression const> argument)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Add support for await expressions
2021-11-09 22:52:21 +02:00
, m_argument(move(argument))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add support for await expressions
2021-11-09 22:52:21 +02:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_argument;
LibJS: Add support for await expressions
2021-11-09 22:52:21 +02:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class ReturnStatement final : public Statement {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
explicit ReturnStatement(SourceRange source_range, RefPtr<Expression const> argument)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_argument(move(argument))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const* argument() const { return m_argument; }
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) 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 19:42:11 +01:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<Expression const> 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 19:42:11 +01:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class IfStatement final : public Statement {
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
IfStatement(SourceRange source_range, NonnullRefPtr<Expression const> predicate, NonnullRefPtr<Statement const> consequent, RefPtr<Statement const> alternate)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_predicate(move(predicate))
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
, m_consequent(move(consequent))
, m_alternate(move(alternate))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& predicate() const { return *m_predicate; }
Statement const& consequent() const { return *m_consequent; }
Statement const* alternate() const { return m_alternate; }
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement if statements If statements execute a certain action or an alternative one depending on whether the tested condition is true or false, this commit helps establish basic control flow capabilities in the AST.
2020-03-08 07:58:58 +02:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_predicate;
NonnullRefPtr<Statement const> m_consequent;
RefPtr<Statement const> 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 07:58:58 +02:00
};
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
class WhileStatement final : public IterationStatement {
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
WhileStatement(SourceRange source_range, NonnullRefPtr<Expression const> test, NonnullRefPtr<Statement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: IterationStatement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_test(move(test))
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& test() const { return *m_test; }
Statement const& body() const { return *m_body; }
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_test;
NonnullRefPtr<Statement const> m_body;
LibJS: Implement While statements
2020-03-09 03:22:21 +08:00
};
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
class DoWhileStatement final : public IterationStatement {
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
DoWhileStatement(SourceRange source_range, NonnullRefPtr<Expression const> test, NonnullRefPtr<Statement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: IterationStatement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_test(move(test))
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& test() const { return *m_test; }
Statement const& body() const { return *m_body; }
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_test;
NonnullRefPtr<Statement const> m_body;
LibJS: Add support for do..while statements
2020-04-04 21:29:23 +02:00
};
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
class WithStatement final : public Statement {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
WithStatement(SourceRange source_range, NonnullRefPtr<Expression const> object, NonnullRefPtr<Statement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_object(move(object))
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& object() const { return *m_object; }
Statement const& body() const { return *m_body; }
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_object;
NonnullRefPtr<Statement const> m_body;
LibJS: Parse "with" statements :^)
2020-11-28 15:05:57 +01:00
};
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
class ForStatement final : public IterationStatement {
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ForStatement(SourceRange source_range, RefPtr<ASTNode const> init, RefPtr<Expression const> test, RefPtr<Expression const> update, NonnullRefPtr<Statement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: IterationStatement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_init(move(init))
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
, m_test(move(test))
, m_update(move(update))
, m_body(move(body))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
ASTNode const* init() const { return m_init; }
Expression const* test() const { return m_test; }
Expression const* update() const { return m_update; }
Statement const& body() const { return *m_body; }
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<ASTNode const> m_init;
RefPtr<Expression const> m_test;
RefPtr<Expression const> m_update;
NonnullRefPtr<Statement const> m_body;
LibJS: Implement for statement
2020-03-12 23:12:12 +11:00
};
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
class ForInStatement final : public IterationStatement {
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ForInStatement(SourceRange source_range, Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> lhs, NonnullRefPtr<Expression const> rhs, NonnullRefPtr<Statement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: IterationStatement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_lhs(move(lhs))
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
, m_rhs(move(rhs))
, m_body(move(body))
{
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
auto const& lhs() const { return m_lhs; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& rhs() const { return *m_rhs; }
Statement const& body() const { return *m_body; }
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
virtual void dump(int indent) const override;
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> m_lhs;
NonnullRefPtr<Expression const> m_rhs;
NonnullRefPtr<Statement const> m_body;
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
};
LibJS: Allow multiple labels on the same statement Since there are only a number of statements where labels can actually be used we now also only store labels when necessary. Also now tracks the first continue usage of a label since this might not be valid but that can only be determined after we have parsed the statement. Also ensures the correct error does not get wiped by load_state.
2021-09-18 23:01:54 +02:00
class ForOfStatement final : public IterationStatement {
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ForOfStatement(SourceRange source_range, Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> lhs, NonnullRefPtr<Expression const> rhs, NonnullRefPtr<Statement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: IterationStatement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_lhs(move(lhs))
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
, m_rhs(move(rhs))
, m_body(move(body))
{
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
auto const& lhs() const { return m_lhs; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& rhs() const { return *m_rhs; }
Statement const& body() const { return *m_body; }
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
virtual void dump(int indent) const override;
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> m_lhs;
NonnullRefPtr<Expression const> m_rhs;
NonnullRefPtr<Statement const> m_body;
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
};
LibJS: Implement parsing and executing for-await-of loops
2021-11-23 16:09:28 +01:00
class ForAwaitOfStatement final : public IterationStatement {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ForAwaitOfStatement(SourceRange source_range, Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> lhs, NonnullRefPtr<Expression const> rhs, NonnullRefPtr<Statement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: IterationStatement(move(source_range))
LibJS: Implement parsing and executing for-await-of loops
2021-11-23 16:09:28 +01:00
, m_lhs(move(lhs))
, m_rhs(move(rhs))
, m_body(move(body))
{
}
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement parsing and executing for-await-of loops
2021-11-23 16:09:28 +01:00
virtual void dump(int indent) const override;
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> m_lhs;
NonnullRefPtr<Expression const> m_rhs;
NonnullRefPtr<Statement const> m_body;
LibJS: Implement parsing and executing for-await-of loops
2021-11-23 16:09:28 +01:00
};
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
enum class BinaryOp {
LibJS: Rename BinaryOp::{Plus,Minus,Asterisk,Slash}
2020-04-05 12:56:53 +01:00
Addition,
Subtraction,
Multiplication,
Division,
LibJS: Add basic support for modulo (%) in binary expressions
2020-04-04 21:17:34 +02:00
Modulo,
LibJS: Implement exponentiation (** operator)
2020-04-05 13:40:00 +01:00
Exponentiation,
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
StrictlyEquals,
StrictlyInequals,
LooselyEquals,
LooselyInequals,
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
GreaterThan,
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
GreaterThanEquals,
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
LessThan,
LibJS: Implement <= and >= binary operators
2020-03-12 23:07:08 +11:00
LessThanEquals,
LibJS: Move Value ops into Value.cpp and tweak BinaryOp names
2020-03-10 11:35:05 +01:00
BitwiseAnd,
BitwiseOr,
BitwiseXor,
LeftShift,
RightShift,
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
UnsignedRightShift,
LibJS: Implement 'in' operator
2020-04-23 16:06:01 +01:00
In,
LibJS: Implement the "instanceof" operator This operator walks the prototype chain of the RHS value and looks for a "prototype" property with the same value as the prototype of the LHS. This is pretty cool. :^)
2020-03-28 16:56:54 +01: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 19:42:11 +01:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class BinaryExpression final : public Expression {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
BinaryExpression(SourceRange source_range, BinaryOp op, NonnullRefPtr<Expression const> lhs, NonnullRefPtr<Expression const> rhs)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_op(op)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) 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 19:42:11 +01:00
private:
BinaryOp m_op;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_lhs;
NonnullRefPtr<Expression const> 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 19:42:11 +01:00
};
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
enum class LogicalOp {
And,
Or,
LibJS: Implement nullish coalescing operator (??)
2020-04-18 00:49:11 +01: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 07:55:44 +02:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class LogicalExpression final : public Expression {
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
LogicalExpression(SourceRange source_range, LogicalOp op, NonnullRefPtr<Expression const> lhs, NonnullRefPtr<Expression const> rhs)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_op(op)
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement logical expressions Logical expressions are expressions which can return either true or false according to a provided condition.
2020-03-08 07:55:44 +02:00
private:
LogicalOp m_op;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_lhs;
NonnullRefPtr<Expression const> 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 07:55:44 +02: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 23:27:18 +02:00
enum class UnaryOp {
LibJS: Rename BitNot -> BitwiseNot to match other bitwise operators
2020-03-14 20:43:35 +02:00
BitwiseNot,
LibJS: Move logical not operator to new unary expression class
2020-03-09 19:04:44 +02:00
Not,
LibJS: Implement unary plus / minus
2020-04-02 17:58:39 +01:00
Plus,
Minus,
LibJS: Implement typeof operator
2020-03-18 06:33:32 +11:00
Typeof,
LibJS: Implement void operator
2020-04-15 17:55:03 +01:00
Void,
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
Delete,
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class UnaryExpression final : public Expression {
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
UnaryExpression(SourceRange source_range, UnaryOp op, NonnullRefPtr<Expression const> lhs)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_op(op)
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
, m_lhs(move(lhs))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add new bitwise and relational operators Do note that when it comes to evaluating binary expressions, we are asserting in multiple contexts that the values we're operating on are numbers, we should probably handle other value types to be more tolerant in the future, since for example, adding a number and a string, in which case the number is converted to a string implicitly which is then concatenated, although ugly, is valid javascript.
2020-03-08 23:27:18 +02:00
private:
UnaryOp m_op;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> 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 23:27:18 +02:00
};
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
class SequenceExpression final : public Expression {
public:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
SequenceExpression(SourceRange source_range, Vector<NonnullRefPtr<Expression const>> expressions)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_expressions(move(expressions))
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
{
LibJS: Ensure SequenceExpression has two or more expressions Just a sanity check, as we should be able to make this assumption elsewhere - this way we can catch silly mistakes early.
2021-03-16 22:03:31 +01:00
VERIFY(m_expressions.size() >= 2);
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
private:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<Expression const>> m_expressions;
LibJS: Add SequenceExpression AST node (comma operator) This patch only adds the AST node, the parser doesn't create them yet.
2020-04-07 15:11:05 +02:00
};
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
class PrimitiveLiteral : 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 12:19:11 +01:00
public:
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
virtual Value value() const = 0;
protected:
explicit PrimitiveLiteral(SourceRange source_range)
LibJS: Remove unused Literal AST node sub-type
2023-11-17 21:26:57 +02:00
: Expression(move(source_range))
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
{
}
};
class BooleanLiteral final : public PrimitiveLiteral {
public:
explicit BooleanLiteral(SourceRange source_range, bool value)
: PrimitiveLiteral(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_value(value)
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
virtual Value value() const override { return Value(m_value); }
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
private:
bool m_value { false };
};
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
class NumericLiteral final : public PrimitiveLiteral {
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
public:
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
explicit NumericLiteral(SourceRange source_range, double value)
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
: PrimitiveLiteral(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_value(value)
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
virtual Value value() const override { return m_value; }
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
private:
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
Value m_value;
LibJS: Defer Value construction until a Literal is executed Remove the need to construct a full Value during parsing. This means we don't have to worry about plumbing the heap into the parser. The Literal ASTNode now has a bunch of subclasses that synthesize a Value on demand.
2020-03-12 12:19:11 +01:00
};
LibJS: Remove unused Literal AST node sub-type
2023-11-17 21:26:57 +02:00
class BigIntLiteral final : public Expression {
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
public:
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
explicit BigIntLiteral(SourceRange source_range, ByteString value)
LibJS: Remove unused Literal AST node sub-type
2023-11-17 21:26:57 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_value(move(value))
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
private:
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString m_value;
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
};
LibJS: Remove unused Literal AST node sub-type
2023-11-17 21:26:57 +02:00
class StringLiteral final : 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 12:19:11 +01:00
public:
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
explicit StringLiteral(SourceRange source_range, ByteString value)
LibJS: Remove unused Literal AST node sub-type
2023-11-17 21:26:57 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_value(move(value))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Fix "use strict" directive false positives By having the "is this a use strict directive?" logic in parse_string_literal() we would apply it to *any* string literal, which is incorrect and would lead to false positives - e.g.: "use strict" + 1 `"use strict"` "\123"; ({"use strict": ...}) Relevant part from the spec which is now implemented properly: [...] and where each ExpressionStatement in the sequence consists entirely of a StringLiteral token [...] I also got rid of UseStrictDirectiveState which is not needed anymore. Fixes #3903.
2020-11-01 21:49:25 +00:00
StringView value() const { return m_value; }
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_string_literal() const override { return true; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString m_value;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
};
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
class NullLiteral final : public PrimitiveLiteral {
LibJS: Implement null and undefined literals
2020-03-15 23:32:34 +02:00
public:
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
explicit NullLiteral(SourceRange source_range)
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
: PrimitiveLiteral(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Implement null and undefined literals
2020-03-15 23:32:34 +02:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 22:07:23 +02:00
virtual Value value() const override { return js_null(); }
LibJS: Implement null and undefined literals
2020-03-15 23:32:34 +02:00
};
LibJS: Remove unused Literal AST node sub-type
2023-11-17 21:26:57 +02:00
class RegExpLiteral final : public Expression {
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
public:
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
RegExpLiteral(SourceRange source_range, regex::Parser::Result parsed_regex, ByteString parsed_pattern, regex::RegexOptions<ECMAScriptFlags> parsed_flags, ByteString pattern, ByteString flags)
LibJS: Remove unused Literal AST node sub-type
2023-11-17 21:26:57 +02:00
: Expression(move(source_range))
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 10:34:37 -04:00
, m_parsed_regex(move(parsed_regex))
, m_parsed_pattern(move(parsed_pattern))
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
, m_parsed_flags(parsed_flags)
LibJS: Rename RegExpLiteral m_content to m_pattern This is what we call it elsewhere, let's be consistent.
2021-05-10 11:56:08 +01:00
, m_pattern(move(pattern))
, m_flags(move(flags))
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 10:34:37 -04:00
regex::Parser::Result const& parsed_regex() const { return m_parsed_regex; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString const& parsed_pattern() const { return m_parsed_pattern; }
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 10:34:37 -04:00
regex::RegexOptions<ECMAScriptFlags> const& parsed_flags() const { return m_parsed_flags; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString const& pattern() const { return m_pattern; }
ByteString const& flags() const { return m_flags; }
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
private:
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 10:34:37 -04:00
regex::Parser::Result m_parsed_regex;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString m_parsed_pattern;
LibJS: Parse RegExp literals at AST creation time, not execution time The spec requires that invalid RegExp literals must cause a Syntax Error before the JavaScript is executed. See: https://tc39.es/ecma262/#sec-patterns-static-semantics-early-errors This is explicitly tested in the RegExp/property-escapes test262 tests. For example, see unsupported-property-Line_Break.js: $DONOTEVALUATE(); /\p{Line_Break}/u; That RegExp literal is invalid because Line_Break is not a supported Unicode property. $DONOTEVALUATE() just throws an exception when it is executed. The test expects that this file will fail to be parsed. Note that RegExp patterns can still be parsed at execution time by way of "new RegExp(...)".
2021-07-29 10:34:37 -04:00
regex::RegexOptions<ECMAScriptFlags> m_parsed_flags;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString m_pattern;
ByteString m_flags;
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
};
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
class PrivateIdentifier final : public Expression {
public:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
explicit PrivateIdentifier(SourceRange source_range, DeprecatedFlyString string)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
, m_string(move(string))
{
}
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString const& string() const { return m_string; }
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
virtual void dump(int indent) const override;
LibJS: Actually override is_private_identifier() in PrivateIdentifier Regression from 72689ce7bd8b4668ad5afd0777e96668c5044eb7.
2022-03-06 00:48:44 +01:00
virtual bool is_private_identifier() const override { return true; }
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
private:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString m_string;
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
};
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
class ClassElement : public ASTNode {
public:
ClassElement(SourceRange source_range, bool is_static)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
, m_is_static(is_static)
{
}
enum class ElementKind {
Method,
Field,
LibJS: Add static initializers to classes
2021-10-20 21:29:47 +02:00
StaticInitializer,
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
};
virtual ElementKind class_element_kind() const = 0;
bool is_static() const { return m_is_static; }
LibJS: Add static initializers to classes
2021-10-20 21:29:47 +02:00
// We use the Completion also as a ClassStaticBlockDefinition Record.
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
using ClassValue = Variant<ClassFieldDefinition, Completion, PrivateElement>;
LibJS: Make class definition evaluation work in bytecode mode Instead of assuming that there's an active AST interpreter, this code now takes VM& everywhere and invokes the appropriate interpreter. 92 new passes on test262. :^)
2023-06-25 17:33:17 +02:00
virtual ThrowCompletionOr<ClassValue> class_element_evaluation(VM&, Object& home_object) const = 0;
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
virtual Optional<DeprecatedFlyString> private_bound_identifier() const { return {}; }
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
private:
bool m_is_static { false };
};
class ClassMethod final : public ClassElement {
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
public:
enum class Kind {
Method,
Getter,
Setter,
};
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ClassMethod(SourceRange source_range, NonnullRefPtr<Expression const> key, NonnullRefPtr<FunctionExpression const> function, Kind kind, bool is_static)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ClassElement(move(source_range), is_static)
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_key(move(key))
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
, m_function(move(function))
, m_kind(kind)
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& key() const { return *m_key; }
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
Kind kind() const { return m_kind; }
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
virtual ElementKind class_element_kind() const override { return ElementKind::Method; }
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
virtual void dump(int indent) const override;
LibJS: Make class definition evaluation work in bytecode mode Instead of assuming that there's an active AST interpreter, this code now takes VM& everywhere and invokes the appropriate interpreter. 92 new passes on test262. :^)
2023-06-25 17:33:17 +02:00
virtual ThrowCompletionOr<ClassValue> class_element_evaluation(VM&, Object& home_object) const override;
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
virtual Optional<DeprecatedFlyString> private_bound_identifier() const override;
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_class_method() const override { return true; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_key;
NonnullRefPtr<FunctionExpression const> m_function;
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
Kind m_kind;
};
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
class ClassField final : public ClassElement {
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ClassField(SourceRange source_range, NonnullRefPtr<Expression const> key, RefPtr<Expression const> init, bool contains_direct_call_to_eval, bool is_static)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ClassElement(move(source_range), is_static)
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
, m_key(move(key))
, m_initializer(move(init))
LibJS: Use ClassFieldInitializerStatement for class fields This is necessary as we might have to perform named evaluation with the field name. Ideally we would also skip some setup parts of the function like function_declaration_instantiation however this would require bigger changes to ECMAScriptFunctionObject.
2021-10-13 19:59:38 +02:00
, m_contains_direct_call_to_eval(contains_direct_call_to_eval)
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
{
}
Expression const& key() const { return *m_key; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<Expression const> const& initializer() const { return m_initializer; }
RefPtr<Expression const>& initializer() { return m_initializer; }
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
virtual ElementKind class_element_kind() const override { return ElementKind::Field; }
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
virtual void dump(int indent) const override;
LibJS: Make class definition evaluation work in bytecode mode Instead of assuming that there's an active AST interpreter, this code now takes VM& everywhere and invokes the appropriate interpreter. 92 new passes on test262. :^)
2023-06-25 17:33:17 +02:00
virtual ThrowCompletionOr<ClassValue> class_element_evaluation(VM&, Object& home_object) const override;
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
virtual Optional<DeprecatedFlyString> private_bound_identifier() const override;
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_key;
RefPtr<Expression const> m_initializer;
LibJS: Use ClassFieldInitializerStatement for class fields This is necessary as we might have to perform named evaluation with the field name. Ideally we would also skip some setup parts of the function like function_declaration_instantiation however this would require bigger changes to ECMAScriptFunctionObject.
2021-10-13 19:59:38 +02:00
bool m_contains_direct_call_to_eval { false };
LibJS: Add support for public fields in classes
2021-08-28 17:11:05 +02:00
};
LibJS: Add static initializers to classes
2021-10-20 21:29:47 +02:00
class StaticInitializer final : public ClassElement {
public:
StaticInitializer(SourceRange source_range, NonnullRefPtr<FunctionBody> function_body, bool contains_direct_call_to_eval)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ClassElement(move(source_range), true)
LibJS: Add static initializers to classes
2021-10-20 21:29:47 +02:00
, m_function_body(move(function_body))
, m_contains_direct_call_to_eval(contains_direct_call_to_eval)
{
}
virtual ElementKind class_element_kind() const override { return ElementKind::StaticInitializer; }
LibJS: Make class definition evaluation work in bytecode mode Instead of assuming that there's an active AST interpreter, this code now takes VM& everywhere and invokes the appropriate interpreter. 92 new passes on test262. :^)
2023-06-25 17:33:17 +02:00
virtual ThrowCompletionOr<ClassValue> class_element_evaluation(VM&, Object& home_object) const override;
LibJS: Add static initializers to classes
2021-10-20 21:29:47 +02:00
virtual void dump(int indent) const override;
private:
NonnullRefPtr<FunctionBody> m_function_body;
bool m_contains_direct_call_to_eval { false };
};
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
class SuperExpression final : public Expression {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit SuperExpression(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_super_expression() const override { return true; }
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
};
class ClassExpression final : public Expression {
public:
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ClassExpression(SourceRange source_range, RefPtr<Identifier const> name, ByteString source_text, RefPtr<FunctionExpression const> constructor, RefPtr<Expression const> super_class, Vector<NonnullRefPtr<ClassElement const>> elements)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_name(move(name))
LibJS: Capture source text of FunctionNode and ClassExpression
2022-01-18 23:46:16 +00:00
, m_source_text(move(source_text))
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
, m_constructor(move(constructor))
, m_super_class(move(super_class))
LibJS: Make class definition evaluation more spec like in ordering
2021-10-07 01:09:04 +02:00
, m_elements(move(elements))
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
{
}
LibJS: Use Identifier to represent name of ClassExpression By using Identifier class to represent the name of a class expression, it becomes possible to consistently store information within the identifier object, indicating whether the name refers to a local variable or not.
2023-06-30 16:51:39 +03:00
StringView name() const { return m_name ? m_name->string().view() : ""sv; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString const& source_text() const { return m_source_text; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<FunctionExpression const> constructor() const { return m_constructor; }
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode_with_lhs_name(Bytecode::Generator&, Optional<Bytecode::IdentifierTableIndex> lhs_name, Optional<Bytecode::Operand> preferred_dst = {}) const;
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
LibJS: Use Identifier to represent name of ClassExpression By using Identifier class to represent the name of a class expression, it becomes possible to consistently store information within the identifier object, indicating whether the name refers to a local variable or not.
2023-06-30 16:51:39 +03:00
bool has_name() const { return m_name; }
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Make class definition evaluation work in bytecode mode Instead of assuming that there's an active AST interpreter, this code now takes VM& everywhere and invokes the appropriate interpreter. 92 new passes on test262. :^)
2023-06-25 17:33:17 +02:00
ThrowCompletionOr<ECMAScriptFunctionObject*> class_definition_evaluation(VM&, DeprecatedFlyString const& binding_name = {}, DeprecatedFlyString const& class_name = {}) const;
LibJS: Stop using execute_ast_node in NewClass instruction This change replaces usage of `execute_ast_node` to evaluate super expression in NewClass by generating instructions instead.
2023-06-28 18:22:27 +03:00
ThrowCompletionOr<ECMAScriptFunctionObject*> create_class_constructor(VM&, Environment* class_environment, Environment* environment, Value super_class, DeprecatedFlyString const& binding_name = {}, DeprecatedFlyString const& class_name = {}) const;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
private:
LibJS: Add fast_is<T>() for FunctionExpression and ClassExpression Spotted RTTI for these two above 1% in a profile.
2021-10-07 12:05:13 +02:00
virtual bool is_class_expression() const override { return true; }
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
friend ClassDeclaration;
LibJS: Use Identifier to represent name of ClassExpression By using Identifier class to represent the name of a class expression, it becomes possible to consistently store information within the identifier object, indicating whether the name refers to a local variable or not.
2023-06-30 16:51:39 +03:00
RefPtr<Identifier const> m_name;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString m_source_text;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<FunctionExpression const> m_constructor;
RefPtr<Expression const> m_super_class;
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<ClassElement const>> m_elements;
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
};
class ClassDeclaration final : public Declaration {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ClassDeclaration(SourceRange source_range, NonnullRefPtr<ClassExpression const> class_expression)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Declaration(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_class_expression(move(class_expression))
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
ThrowCompletionOr<void> for_each_bound_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&&) const override;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
virtual bool is_lexical_declaration() const override { return true; }
LibJS: Split parsing program to script and module separately This allows us to only perform checks like export bindings existing only for modules. Also this makes it easier to set strict and other state variables with TemporaryChanges.
2021-11-27 00:01:23 +01:00
StringView name() const { return m_class_expression->name(); }
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_class_declaration() const override { return true; }
LibJS: Implement evaluation of im- and exports statements
2022-01-18 19:07:13 +01:00
friend ExportStatement;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<ClassExpression const> m_class_expression;
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
};
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
// We use this class to mimic Initializer : = AssignmentExpression of
// 10.2.1.3 Runtime Semantics: EvaluateBody, https://tc39.es/ecma262/#sec-runtime-semantics-evaluatebody
class ClassFieldInitializerStatement final : public Statement {
public:
ClassFieldInitializerStatement(SourceRange source_range, NonnullRefPtr<Expression const> expression, DeprecatedFlyString field_name)
: Statement(move(source_range))
, m_expression(move(expression))
, m_class_field_identifier_name(move(field_name))
{
}
virtual void dump(int) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
private:
NonnullRefPtr<Expression const> m_expression;
DeprecatedFlyString m_class_field_identifier_name; // [[ClassFieldIdentifierName]]
};
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
class SpreadExpression final : public Expression {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
explicit SpreadExpression(SourceRange source_range, NonnullRefPtr<Expression const> target)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
, m_target(move(target))
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_target;
LibJS: Add spreading in array literals Implement the syntax and behavor necessary to support array literals such as [...[1, 2, 3]]. A type error is thrown if the target of the spread operator does not evaluate to an array (though it should eventually just check for an iterable). Note that the spread token's name is TripleDot, since the '...' token is used for two features: spread and rest. Calling it anything involving 'spread' or 'rest' would be a bit confusing.
2020-04-26 23:05:37 -07:00
};
LibJS: Parse "this" as ThisExpression
2020-04-13 00:42:14 +02:00
class ThisExpression final : public Expression {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit ThisExpression(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Parse "this" as ThisExpression
2020-04-13 00:42:14 +02:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Parse "this" as ThisExpression
2020-04-13 00:42:14 +02:00
};
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
struct CallExpressionArgument {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> value;
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
bool is_spread;
};
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
enum InvocationStyleEnum {
Parenthesized,
NotParenthesized,
};
enum InsideParenthesesEnum {
InsideParentheses,
NotInsideParentheses,
};
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
class CallExpression : public ASTNodeWithTailArray<CallExpression, Expression, CallExpressionArgument> {
friend class ASTNodeWithTailArray;
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
InvocationStyleEnum m_invocation_style;
InsideParenthesesEnum m_inside_parentheses;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
public:
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
using Argument = CallExpressionArgument;
LibJS: Add function call spreading Adds support for the following syntax: myFunction(...x, ...[1, 2, 3], ...o.foo, ...'abcd')
2020-05-05 22:36:24 -07:00
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
static NonnullRefPtr<CallExpression> create(SourceRange, NonnullRefPtr<Expression const> callee, ReadonlySpan<Argument> arguments, InvocationStyleEnum invocation_style, InsideParenthesesEnum inside_parens);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) 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 19:42:11 +01:00
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
Expression const& callee() const { return m_callee; }
Everywhere: Use ReadonlySpan<T> instead of Span<T const>
2023-02-05 19:02:54 +00:00
ReadonlySpan<Argument> arguments() const { return tail_span(); }
LibJS: Split out NewExpression evaluation from CallExpression This patch adds an override for NewExpression::execute() in the AST interpreter to separate the logic from CallExpression. As a result, both evaluation functions are simplified. Both expressions are still largely non-conforming, but this makes it easier to work on improving that since we can now deal with them separately. :^)
2021-07-02 18:25:32 +02:00
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
bool is_parenthesized() const { return m_invocation_style == InvocationStyleEnum::Parenthesized; }
bool is_inside_parens() const { return m_inside_parentheses == InsideParenthesesEnum::InsideParentheses; }
void set_inside_parens() { m_inside_parentheses = InsideParenthesesEnum::InsideParentheses; }
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
protected:
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
CallExpression(SourceRange source_range, NonnullRefPtr<Expression const> callee, ReadonlySpan<Argument> arguments, InvocationStyleEnum invocation_style, InsideParenthesesEnum inside_parens = InsideParenthesesEnum::NotInsideParentheses)
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
: ASTNodeWithTailArray(move(source_range), arguments)
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
, m_invocation_style(invocation_style)
, m_inside_parentheses(inside_parens)
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
, m_callee(move(callee))
{
}
LibJS: NewExpression doesn't need compute_this_and_callee() Now that NewExpression is separated from CallExpression, it doesn't have to use the ad-hoc compute_this_and_callee() logic.
2021-07-02 18:43:25 +02:00
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
virtual bool is_call_expression() const override { return true; }
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
Optional<ByteString> expression_string() const;
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_callee;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
};
LibJS: Implement basic support for the "new" keyword NewExpression mostly piggybacks on the existing CallExpression. The big difference is that "new" creates a new Object and passes it as |this| to the callee.
2020-03-28 16:33:52 +01:00
class NewExpression final : public CallExpression {
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
friend class ASTNodeWithTailArray;
LibJS: Implement basic support for the "new" keyword NewExpression mostly piggybacks on the existing CallExpression. The big difference is that "new" creates a new Object and passes it as |this| to the callee.
2020-03-28 16:33:52 +01:00
public:
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
static NonnullRefPtr<NewExpression> create(SourceRange, NonnullRefPtr<Expression const> callee, ReadonlySpan<Argument> arguments, InvocationStyleEnum invocation_style, InsideParenthesesEnum inside_parens);
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_new_expression() const override { return true; }
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
private:
LibJS: Correctly handle parentheses and new Object Parses `new Object()?.foo`, `(new Object)?.foo` and shows syntax error on `new Object?.foo`
2023-06-15 15:13:48 +05:30
NewExpression(SourceRange source_range, NonnullRefPtr<Expression const> callee, ReadonlySpan<Argument> arguments, InvocationStyleEnum invocation_style, InsideParenthesesEnum inside_parens)
: CallExpression(move(source_range), move(callee), arguments, invocation_style, inside_parens)
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01: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 16:33:52 +01:00
};
LibJS: Make one compact allocation for CallExpression and its Arguments Instead of CallExpression storing its arguments in a Vector<Argument>, we now custom-allocate the memory slot for CallExpression (and its subclass NewExpression) so that it fits both CallExpression and its list of Arguments in one allocation. This reduces memory usage on twitter.com/awesomekling by 8.8 MiB :^)
2022-11-26 19:51:50 +01:00
static_assert(sizeof(NewExpression) == sizeof(CallExpression), "Adding members to NewExpression will break CallExpression memory layout");
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
class SuperCall final : public Expression {
public:
LibJS: Use a synthetic constructor if class with parent doesn't have one We already did this but it called the @@iterator method of %Array.prototype% visible to the user for example by overriding that method. This should not be visible so we use a special version of SuperCall now.
2022-08-20 17:27:02 +02:00
// This is here to be able to make a constructor like
// constructor(...args) { super(...args); } which does not use @@iterator of %Array.prototype%.
enum class IsPartOfSyntheticConstructor {
No,
Yes,
};
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
SuperCall(SourceRange source_range, Vector<CallExpression::Argument> arguments)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
, m_arguments(move(arguments))
LibJS: Use a synthetic constructor if class with parent doesn't have one We already did this but it called the @@iterator method of %Array.prototype% visible to the user for example by overriding that method. This should not be visible so we use a special version of SuperCall now.
2022-08-20 17:27:02 +02:00
, m_is_synthetic(IsPartOfSyntheticConstructor::No)
{
}
SuperCall(SourceRange source_range, IsPartOfSyntheticConstructor is_part_of_synthetic_constructor, CallExpression::Argument constructor_argument)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Use a synthetic constructor if class with parent doesn't have one We already did this but it called the @@iterator method of %Array.prototype% visible to the user for example by overriding that method. This should not be visible so we use a special version of SuperCall now.
2022-08-20 17:27:02 +02:00
, m_arguments({ move(constructor_argument) })
, m_is_synthetic(IsPartOfSyntheticConstructor::Yes)
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
{
LibJS: Use a synthetic constructor if class with parent doesn't have one We already did this but it called the @@iterator method of %Array.prototype% visible to the user for example by overriding that method. This should not be visible so we use a special version of SuperCall now.
2022-08-20 17:27:02 +02:00
VERIFY(is_part_of_synthetic_constructor == IsPartOfSyntheticConstructor::Yes);
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
private:
Vector<CallExpression::Argument> const m_arguments;
LibJS: Use a synthetic constructor if class with parent doesn't have one We already did this but it called the @@iterator method of %Array.prototype% visible to the user for example by overriding that method. This should not be visible so we use a special version of SuperCall now.
2022-08-20 17:27:02 +02:00
IsPartOfSyntheticConstructor const m_is_synthetic;
LibJS: Make SuperCall a proper AST node and clean up evaluation
2021-07-02 19:30:38 +02:00
};
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
enum class AssignmentOp {
LibJS: Tweak AssignmentOp names
2020-03-12 13:54:56 +01:00
Assignment,
AdditionAssignment,
SubtractionAssignment,
MultiplicationAssignment,
DivisionAssignment,
LibJS: Implement modulo assignment operator (%=)
2020-05-04 23:07:05 +01:00
ModuloAssignment,
LibJS: Implement exponentiation assignment operator (**=)
2020-05-04 23:03:35 +01:00
ExponentiationAssignment,
LibJS: Implement bitwise assignment operators (&=, |=, ^=)
2020-05-04 22:34:45 +01:00
BitwiseAndAssignment,
BitwiseOrAssignment,
BitwiseXorAssignment,
LibJS: Implement bitwise left shift operator (<<)
2020-04-23 13:36:14 +01:00
LeftShiftAssignment,
LibJS: Implement bitwise right shift operator (>>)
2020-04-23 13:45:19 +01:00
RightShiftAssignment,
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
UnsignedRightShiftAssignment,
LibJS: Implement logical assignment operators (&&=, ||=, ??=) TC39 proposal, stage 4 as of 2020-07. https://tc39.es/proposal-logical-assignment/
2020-10-05 16:49:43 +01:00
AndAssignment,
OrAssignment,
NullishAssignment,
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class AssignmentExpression final : public Expression {
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
AssignmentExpression(SourceRange source_range, AssignmentOp op, NonnullRefPtr<Expression const> lhs, NonnullRefPtr<Expression const> rhs)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_op(op)
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
, m_lhs(move(lhs))
, m_rhs(move(rhs))
{
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
AssignmentExpression(SourceRange source_range, AssignmentOp op, NonnullRefPtr<BindingPattern const> lhs, NonnullRefPtr<Expression const> rhs)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Implement parsing and evaluation for AssignmentPatterns e.g. `[...foo] = bar` can now be evaluated :^)
2021-07-11 01:16:17 +04:30
, m_op(op)
, m_lhs(move(lhs))
, m_rhs(move(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 21:13:55 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
private:
AssignmentOp m_op;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Variant<NonnullRefPtr<Expression const>, NonnullRefPtr<BindingPattern const>> m_lhs;
NonnullRefPtr<Expression const> 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 21:13:55 +01:00
};
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
enum class UpdateOp {
Increment,
Decrement,
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class UpdateExpression final : public Expression {
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
UpdateExpression(SourceRange source_range, UpdateOp op, NonnullRefPtr<Expression const> argument, bool prefixed = false)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_op(op)
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
, m_argument(move(argument))
LibJS/AST: Implement prefixed update expressions
2020-03-14 20:44:57 +02: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 13:45:45 +02:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_update_expression() const override { return true; }
LibJS: Implement update expressions Note that currently only the non-prefixed variant is supported (i.e i++ not ++i), this variant returns the value of the argument before the update.
2020-03-12 13:45:45 +02:00
UpdateOp m_op;
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_argument;
LibJS/AST: Implement prefixed update expressions
2020-03-14 20:44:57 +02: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 13:45:45 +02: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 11:59:18 +02: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 21:09:20 +02: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 14:24:34 +02: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 21:09:20 +02: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 21:46:25 +02:00
class VariableDeclarator final : public ASTNode {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
VariableDeclarator(SourceRange source_range, NonnullRefPtr<Identifier const> id)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
, m_target(move(id))
LibJS: Implement basic for..in and for..of loops
2020-04-21 19:21:26 +01:00
{
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
VariableDeclarator(SourceRange source_range, NonnullRefPtr<Identifier const> target, RefPtr<Expression const> init)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
, m_target(move(target))
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
, m_init(move(init))
{
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
VariableDeclarator(SourceRange source_range, Variant<NonnullRefPtr<Identifier const>, NonnullRefPtr<BindingPattern const>> target, RefPtr<Expression const> init)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
, m_target(move(target))
, m_init(move(init))
{
}
auto& target() const { return m_target; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const* init() const { return m_init; }
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
virtual void dump(int indent) const override;
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Variant<NonnullRefPtr<Identifier const>, NonnullRefPtr<BindingPattern const>> m_target;
RefPtr<Expression const> m_init;
LibJS: Support VariableDeclaration with multiple declarators This patch adds support in the parser and interpreter for this: var a = 1, b = 2, c = a + b; VariableDeclaration is now a sequence of VariableDeclarators. :^)
2020-04-04 21:46:25 +02:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class VariableDeclaration final : public Declaration {
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
public:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
VariableDeclaration(SourceRange source_range, DeclarationKind declaration_kind, Vector<NonnullRefPtr<VariableDeclarator const>> declarations)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Declaration(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, 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 21:46:25 +02: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 21:13:55 +01: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 11:59:18 +02: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 21:13:55 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<VariableDeclarator const>> const& declarations() const { return m_declarations; }
LibJS: Hoist variable declarations to the nearest relevant scope "var" declarations are hoisted to the nearest function scope, while "let" and "const" are hoisted to the nearest block scope. This is done by the parser, which keeps two scope stacks, one stack for the current var scope and one for the current let/const scope. When the interpreter enters a scope, we walk all of the declarations and insert them into the variable environment. We don't support the temporal dead zone for let/const yet.
2020-04-13 16:42:54 +02:00
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
ThrowCompletionOr<void> for_each_bound_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&&) const override;
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
virtual bool is_constant_declaration() const override { return m_declaration_kind == DeclarationKind::Const; }
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
virtual bool is_lexical_declaration() const override { return m_declaration_kind != DeclarationKind::Var; }
LibJS: Add basic support for (scoped) variables It's now possible to assign expressions to variables. The variables are put into the current scope of the interpreter. Variable lookup follows the scope chain, ending in the global object.
2020-03-09 21:13:55 +01:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01: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 11:59:18 +02:00
DeclarationKind m_declaration_kind;
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<VariableDeclarator const>> 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 21:13:55 +01:00
};
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
class UsingDeclaration final : public Declaration {
public:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
UsingDeclaration(SourceRange source_range, Vector<NonnullRefPtr<VariableDeclarator const>> declarations)
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
: Declaration(move(source_range))
, m_declarations(move(declarations))
{
}
virtual void dump(int indent) const override;
LibJS: Add for_each_bound_identifier for AST::Declaration The same as for_each_bound_name but for identifiers.
2023-07-02 01:04:07 +03:00
ThrowCompletionOr<void> for_each_bound_identifier(ThrowCompletionOrVoidCallback<Identifier const&>&&) const override;
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
virtual bool is_constant_declaration() const override { return true; }
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
virtual bool is_lexical_declaration() const override { return true; }
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<VariableDeclarator const>> const& declarations() const { return m_declarations; }
LibJS: Add using declaration support in for and for of loops The using declarations have kind of special behavior in for loops so this is seperated.
2022-12-23 01:45:29 +01:00
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
private:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<VariableDeclarator const>> m_declarations;
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
};
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
class ObjectProperty final : public ASTNode {
public:
LibJS: Shrink ObjectProperty AST nodes by rearranging members By putting smaller members in the padding hole after the ASTNode base class, we shrink ObjectProperty by 8 bytes.
2022-11-26 19:55:46 +01:00
enum class Type : u8 {
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
KeyValue,
Getter,
Setter,
Spread,
LibJS: Implement the object literal __proto__ property key special case
2022-03-05 23:44:49 +02:00
ProtoSetter,
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
};
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ObjectProperty(SourceRange source_range, NonnullRefPtr<Expression const> key, RefPtr<Expression const> value, Type property_type, bool is_method)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
, m_property_type(property_type)
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
, m_is_method(is_method)
LibJS: Shrink ObjectProperty AST nodes by rearranging members By putting smaller members in the padding hole after the ASTNode base class, we shrink ObjectProperty by 8 bytes.
2022-11-26 19:55:46 +01:00
, m_key(move(key))
, m_value(move(value))
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& key() const { return m_key; }
Expression const& value() const
LibJS: Rewrite Parser.parse_object_expression() This rewrite drastically increases the accuracy of object literals. Additionally, an "assertIsSyntaxError" function has been added to test-common.js to assist in testing syntax errors.
2020-05-28 22:50:06 -07:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(m_value);
LibJS: Rewrite Parser.parse_object_expression() This rewrite drastically increases the accuracy of object literals. Additionally, an "assertIsSyntaxError" function has been added to test-common.js to assist in testing syntax errors.
2020-05-28 22:50:06 -07:00
return *m_value;
}
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
Type type() const { return m_property_type; }
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
bool is_method() const { return m_is_method; }
LibJS: Add spreading in object literals Supports spreading strings, arrays, and other objects within object literals.
2020-04-27 21:52:47 -07:00
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
virtual void dump(int indent) const override;
private:
LibJS: Add object literal getter/setter shorthand Adds support for the following syntax: let foo = { get x() { // ... }, set x(value) { // ... } }
2020-05-21 17:28:28 -07:00
Type m_property_type;
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
bool m_is_method { false };
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_key;
RefPtr<Expression const> m_value;
LibJS: Implement computed properties in object expressions
2020-04-23 19:37:53 +01:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class ObjectExpression final : public Expression {
LibJS: Add a very simple ObjectExpression for "var x = {}" This allows us to allocate an empty new Object on the GC heap.
2020-03-09 21:28:31 +01:00
public:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
explicit ObjectExpression(SourceRange source_range, Vector<NonnullRefPtr<ObjectProperty>> properties = {})
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_properties(move(properties))
LibJS: Parse object expressions
2020-03-21 02:29:00 +02:00
{
}
LibJS: Add a very simple ObjectExpression for "var x = {}" This allows us to allocate an empty new Object on the GC heap.
2020-03-09 21:28:31 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add a very simple ObjectExpression for "var x = {}" This allows us to allocate an empty new Object on the GC heap.
2020-03-09 21:28:31 +01:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_object_expression() const override { return true; }
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<ObjectProperty>> 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 21:28:31 +01:00
};
LibJS: Mark more ASTNode classes as `final`
2020-09-16 19:13:32 +01:00
class ArrayExpression final : public Expression {
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ArrayExpression(SourceRange source_range, Vector<RefPtr<Expression const>> elements)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_elements(move(elements))
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
{
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Vector<RefPtr<Expression const>> const& elements() const { return m_elements; }
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_array_expression() const override { return true; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Vector<RefPtr<Expression const>> m_elements;
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
};
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
class TemplateLiteral final : public Expression {
public:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
TemplateLiteral(SourceRange source_range, Vector<NonnullRefPtr<Expression const>> expressions)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_expressions(move(expressions))
LibJS: Add raw strings to tagged template literals When calling a function with a tagged template, the first array that is passed in now contains a "raw" property with the raw, escaped strings.
2020-05-06 16:34:14 -07:00
{
}
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
TemplateLiteral(SourceRange source_range, Vector<NonnullRefPtr<Expression const>> expressions, Vector<NonnullRefPtr<Expression const>> raw_strings)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_expressions(move(expressions))
LibJS: Add raw strings to tagged template literals When calling a function with a tagged template, the first array that is passed in now contains a "raw" property with the raw, escaped strings.
2020-05-06 16:34:14 -07:00
, m_raw_strings(move(raw_strings))
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<Expression const>> const& expressions() const { return m_expressions; }
Vector<NonnullRefPtr<Expression const>> const& raw_strings() const { return m_raw_strings; }
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
private:
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<Expression const>> const m_expressions;
Vector<NonnullRefPtr<Expression const>> const m_raw_strings;
LibJS: Add template literals Adds fully functioning template literals. Because template literals contain expressions, most of the work has to be done in the Lexer rather than the Parser. And because of the complexity of template literals (expressions, nesting, escapes, etc), the Lexer needs to have some template-related state. When entering a new template literal, a TemplateLiteralStart token is emitted. When inside a literal, all text will be parsed up until a '${' or '`' (or EOF, but that's a syntax error) is seen, and then a TemplateLiteralExprStart token is emitted. At this point, the Lexer proceeds as normal, however it keeps track of the number of opening and closing curly braces it has seen in order to determine the close of the expression. Once it finds a matching curly brace for the '${', a TemplateLiteralExprEnd token is emitted and the state is updated accordingly. When the Lexer is inside of a template literal, but not an expression, and sees a '`', this must be the closing grave: a TemplateLiteralEnd token is emitted. The state required to correctly parse template strings consists of a vector (for nesting) of two pieces of information: whether or not we are in a template expression (as opposed to a template string); and the count of the number of unmatched open curly braces we have seen (only applicable if the Lexer is currently in a template expression). TODO: Add support for template literal newlines in the JS REPL (this will cause a syntax error currently): > `foo > bar` 'foo bar'
2020-05-03 15:41:14 -07:00
};
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
class TaggedTemplateLiteral final : public Expression {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
TaggedTemplateLiteral(SourceRange source_range, NonnullRefPtr<Expression const> tag, NonnullRefPtr<TemplateLiteral const> template_literal)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_tag(move(tag))
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
, m_template_literal(move(template_literal))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> const m_tag;
NonnullRefPtr<TemplateLiteral const> const m_template_literal;
LibJS: Implement tagged template literals (foo`bar`) To make processing tagged template literals easier, template literals will now add one empty StringLiteral before and after each template expression *if* there's no other string - e.g.: `${foo}` -> "", foo, "" `test${foo}${bar}test` -> "test", foo, "", bar, "test" This also matches the behaviour of many other parsers.
2020-05-06 10:17:35 +01:00
};
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
class MemberExpression final : public Expression {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
MemberExpression(SourceRange source_range, NonnullRefPtr<Expression const> object, NonnullRefPtr<Expression const> property, bool computed = false)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Shrink MemberExpression by rearranging members slightly By putting m_computed in the padding hole after our base class, we shrink MemberExpression by 8 bytes. :^)
2022-11-26 19:04:15 +01:00
, m_computed(computed)
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_object(move(object))
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
, m_property(move(property))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
LibJS: Parse computed MemberExpressions MemberExpression comes in two flavors: computed: a[b] non-computed: a.b We can now parse both of the types. :^)
2020-03-20 20:51:03 +01:00
bool is_computed() const { return m_computed; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& object() const { return *m_object; }
Expression const& property() const { return *m_property; }
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString to_string_approximation() const;
LibJS: Improve CallExpression::execute()'s error messages
2020-04-19 01:12:51 +01:00
LibJS: Add parsing and evaluation of private fields and methods
2021-10-12 22:45:52 +02:00
bool ends_in_private_name() const;
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
private:
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_member_expression() const override { return true; }
LibJS: Shrink MemberExpression by rearranging members slightly By putting m_computed in the padding hole after our base class, we shrink MemberExpression by 8 bytes. :^)
2022-11-26 19:04:15 +01:00
bool m_computed { false };
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_object;
NonnullRefPtr<Expression const> m_property;
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
};
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
class OptionalChain final : public Expression {
public:
enum class Mode {
Optional,
NotOptional,
};
struct Call {
Vector<CallExpression::Argument> arguments;
Mode mode;
};
struct ComputedReference {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> expression;
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
Mode mode;
};
struct MemberReference {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Identifier const> identifier;
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
Mode mode;
};
LibJS: Implement private identifiers in optional chains
2021-10-18 23:32:47 +02:00
struct PrivateMemberReference {
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<PrivateIdentifier const> private_identifier;
LibJS: Implement private identifiers in optional chains
2021-10-18 23:32:47 +02:00
Mode mode;
};
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
LibJS: Implement private identifiers in optional chains
2021-10-18 23:32:47 +02:00
using Reference = Variant<Call, ComputedReference, MemberReference, PrivateMemberReference>;
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
OptionalChain(SourceRange source_range, NonnullRefPtr<Expression const> base, Vector<Reference> references)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
, m_base(move(base))
, m_references(move(references))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
Expression const& base() const { return *m_base; }
Vector<Reference> const& references() const { return m_references; }
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_base;
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
Vector<Reference> m_references;
};
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
class MetaProperty final : public Expression {
public:
enum class Type {
NewTarget,
ImportMeta,
};
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
MetaProperty(SourceRange source_range, Type type)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_type(type)
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement 'new.target' This adds a new MetaProperty AST node which will be used for 'new.target' and 'import.meta' meta properties. The parser now distinguishes between "in function context" and "in arrow function context" (which is required for this). When encountering TokenType::New we will attempt to parse it as meta property and resort to regular new expression parsing if that fails, much like the parsing of labelled statements.
2020-11-02 21:27:42 +00:00
private:
Type m_type;
};
LibJS: Parse dynamic import calls 'import()' and 'import.meta' For now both just throw when executing but this can be implemented when modules are implemented :^).
2021-11-26 23:45:10 +01:00
class ImportCall final : public Expression {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ImportCall(SourceRange source_range, NonnullRefPtr<Expression const> specifier, RefPtr<Expression const> options)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Parse dynamic import calls 'import()' and 'import.meta' For now both just throw when executing but this can be implemented when modules are implemented :^).
2021-11-26 23:45:10 +01:00
, m_specifier(move(specifier))
, m_options(move(options))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Parse dynamic import calls 'import()' and 'import.meta' For now both just throw when executing but this can be implemented when modules are implemented :^).
2021-11-26 23:45:10 +01:00
private:
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
virtual bool is_import_call() const override { return true; }
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_specifier;
RefPtr<Expression const> m_options;
LibJS: Parse dynamic import calls 'import()' and 'import.meta' For now both just throw when executing but this can be implemented when modules are implemented :^).
2021-11-26 23:45:10 +01:00
};
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
class ConditionalExpression final : public Expression {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
ConditionalExpression(SourceRange source_range, NonnullRefPtr<Expression const> test, NonnullRefPtr<Expression const> consequent, NonnullRefPtr<Expression const> alternate)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_test(move(test))
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
, m_consequent(move(consequent))
, m_alternate(move(alternate))
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_test;
NonnullRefPtr<Expression const> m_consequent;
NonnullRefPtr<Expression const> m_alternate;
LibJS: Implement ConditionalExpression (ternary "?:" operator)
2020-04-03 12:14:28 +02:00
};
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
class CatchClause final : public ASTNode {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
CatchClause(SourceRange source_range, DeprecatedFlyString parameter, NonnullRefPtr<BlockStatement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
, m_parameter(move(parameter))
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
, m_body(move(body))
{
}
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
CatchClause(SourceRange source_range, NonnullRefPtr<BindingPattern const> parameter, NonnullRefPtr<BlockStatement const> body)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ASTNode(move(source_range))
LibJS: Add support for binding patterns in catch clauses `try { ... } catch({a=foo}) {}` is valid, and now we parse and evaluate it correctly :^)
2021-07-11 15:15:38 +04:30
, m_parameter(move(parameter))
, m_body(move(body))
{
}
auto& parameter() const { return m_parameter; }
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
BlockStatement const& body() const { return m_body; }
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
virtual void dump(int indent) const override;
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
Variant<DeprecatedFlyString, NonnullRefPtr<BindingPattern const>> m_parameter;
NonnullRefPtr<BlockStatement const> m_body;
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
};
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01:00
class TryStatement final : public Statement {
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
TryStatement(SourceRange source_range, NonnullRefPtr<BlockStatement const> block, RefPtr<CatchClause const> handler, RefPtr<BlockStatement const> finalizer)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_block(move(block))
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
, m_handler(move(handler))
, m_finalizer(move(finalizer))
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
BlockStatement const& block() const { return m_block; }
CatchClause const* handler() const { return m_handler; }
BlockStatement const* finalizer() const { return m_finalizer; }
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<BlockStatement const> m_block;
RefPtr<CatchClause const> m_handler;
RefPtr<BlockStatement const> m_finalizer;
LibJS: Parse "try", "catch" and "finally" This is the first step towards support exceptions. :^)
2020-03-24 14:03:55 +01:00
};
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 22:03:50 +01:00
class ThrowStatement final : public Statement {
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
explicit ThrowStatement(SourceRange source_range, NonnullRefPtr<Expression const> argument)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_argument(move(argument))
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 22:03:50 +01:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const& argument() const { return m_argument; }
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 22:03:50 +01:00
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 22:03:50 +01:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_argument;
LibJS: Implement "throw" You can now throw an expression to the nearest catcher! :^) To support throwing arbitrary values, I added an Exception class that sits as a wrapper around whatever is thrown. In the future it will be a logical place to store a call stack.
2020-03-24 22:03:50 +01:00
};
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
class SwitchCase final : public ScopeNode {
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
SwitchCase(SourceRange source_range, RefPtr<Expression const> test)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ScopeNode(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_test(move(test))
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
{
}
LibJS: Switch AST.{h,cpp} to east const
2021-06-11 02:13:06 +04:30
Expression const* test() const { return m_test; }
LibJS: Implement basic execution of "switch" statements The "break" keyword now unwinds to the nearest ScopeType::Breakable. There's no support for break labels yet, but we'll get there too.
2020-03-29 14:34:25 +02:00
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
virtual void dump(int indent) const override;
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
RefPtr<Expression const> m_test;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
};
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
class SwitchStatement final : public ScopeNode {
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
public:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
SwitchStatement(SourceRange source_range, NonnullRefPtr<Expression const> discriminant)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: ScopeNode(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
, m_discriminant(move(discriminant))
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
{
}
virtual void dump(int indent) const override;
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&, Optional<Bytecode::Operand> preferred_dst = {}) const;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
void add_case(NonnullRefPtr<SwitchCase const> switch_case) { m_cases.append(move(switch_case)); }
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
private:
LibJS: Make RefPtr and NonnullRefPtr usage const-correct This mainly affected the AST, which is now const throughout.
2023-02-19 22:07:52 +01:00
NonnullRefPtr<Expression const> m_discriminant;
Everywhere: Stop using NonnullRefPtrVector This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-03-06 14:17:01 +01:00
Vector<NonnullRefPtr<SwitchCase const>> m_cases;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
};
class BreakStatement final : public Statement {
public:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
BreakStatement(SourceRange source_range, DeprecatedFlyString target_label)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
, m_target_label(move(target_label))
LibJS: Parse labels in continue and break statements
2020-05-28 12:02:32 -07:00
{
}
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString const& target_label() const { return m_target_label; }
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Parse labels in continue and break statements
2020-05-28 12:02:32 -07:00
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
private:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString m_target_label;
LibJS: Lexer and parser support for "switch" statements
2020-03-29 13:09:54 +02:00
};
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
class ContinueStatement final : public Statement {
public:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
ContinueStatement(SourceRange source_range, DeprecatedFlyString target_label)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
, m_target_label(move(target_label))
LibJS: Parse labels in continue and break statements
2020-05-28 12:02:32 -07:00
{
}
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString const& target_label() const { return m_target_label; }
LibJS: Parse labels in continue and break statements
2020-05-28 12:02:32 -07:00
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
private:
AK+Everywhere: Rename FlyString to DeprecatedFlyString DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so let's rename it to A) match the name of DeprecatedString, B) write a new FlyString class that is tied to String.
2023-01-08 19:23:00 -05:00
DeprecatedFlyString m_target_label;
LibJS: Add support for "continue" inside "for" statements :^)
2020-04-05 00:22:42 +02:00
};
LibJS: Implement (no-op) debugger statement
2020-04-30 17:26:27 +01:00
class DebuggerStatement final : public Statement {
public:
LibJS: Fix clang-tidy warnings in AST.h - Add/remove `move()` as suggested. - Add missing `explicit` on single-parameter constructors.
2021-06-24 13:38:21 +02:00
explicit DebuggerStatement(SourceRange source_range)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Statement(move(source_range))
LibJS: Track source positions all the way down to exceptions This makes exceptions have a trace of source positions too, which could probably be helpful in making fancier error tracebacks.
2020-12-28 20:45:22 +03:30
{
}
LibJS: Implement (no-op) debugger statement
2020-04-30 17:26:27 +01:00
LibJS/Bytecode: Add Operand in/out to all the bytecode codegen helpers This is pure prep work for refactoring the bytecode to use more operands instead of only registers. generate_bytecode() virtuals now return an Optional<Operand>, and the idea is to return an Operand referring to the value produced by this AST node. They also take an Optional<Operand> "preferred_dst" input. This is intended to communicate the caller's preference for an output operand, if any. This will be used to elide temporaries when we can store the result directly in a local, for example.
2024-02-03 20:16:02 +01:00
virtual Bytecode::CodeGenerationErrorOr<Optional<Bytecode::Operand>> generate_bytecode(Bytecode::Generator&, Optional<Bytecode::Operand> preferred_dst = {}) const override;
LibJS: Implement (no-op) debugger statement
2020-04-30 17:26:27 +01:00
};
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
class SyntheticReferenceExpression final : public Expression {
public:
explicit SyntheticReferenceExpression(SourceRange source_range, Reference reference, Value value)
LibJS: Fix most clang-tidy warnings in AST.h Mostly adding a bunch of move() to avoid ref-count churn.
2023-08-08 13:11:33 +02:00
: Expression(move(source_range))
LibJS: Implement parsing and execution of optional chains
2021-09-14 06:56:31 +04:30
, m_reference(move(reference))
, m_value(value)
{
}
private:
Reference m_reference;
Value m_value;
};
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
template<>
inline bool ASTNode::fast_is<NewExpression>() const { return is_new_expression(); }
template<>
inline bool ASTNode::fast_is<MemberExpression>() const { return is_member_expression(); }
template<>
inline bool ASTNode::fast_is<SuperExpression>() const { return is_super_expression(); }
LibJS: Add fast_is<T>() for FunctionExpression and ClassExpression Spotted RTTI for these two above 1% in a profile.
2021-10-07 12:05:13 +02:00
template<>
inline bool ASTNode::fast_is<FunctionExpression>() const { return is_function_expression(); }
template<>
inline bool ASTNode::fast_is<ClassExpression>() const { return is_class_expression(); }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
template<>
inline bool ASTNode::fast_is<Identifier>() const { return is_identifier(); }
LibJS: Add fast_is<PrivateIdentifier>()
2022-03-05 23:49:37 +01:00
template<>
inline bool ASTNode::fast_is<PrivateIdentifier>() const { return is_private_identifier(); }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
template<>
inline bool ASTNode::fast_is<ExpressionStatement>() const { return is_expression_statement(); }
template<>
inline bool ASTNode::fast_is<ScopeNode>() const { return is_scope_node(); }
template<>
inline bool ASTNode::fast_is<Program>() const { return is_program(); }
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
template<>
inline bool ASTNode::fast_is<ClassDeclaration>() const { return is_class_declaration(); }
LibJS: Add fast_is<T>() for FunctionDeclaration
2021-10-07 23:07:52 +02:00
template<>
inline bool ASTNode::fast_is<FunctionDeclaration>() const { return is_function_declaration(); }
LibJS: Add fast_is<T>() for things that were hot in RTTI This gives a ~4% speedup when parsing the largest Discord JS file.
2022-02-13 13:07:38 +01:00
template<>
inline bool ASTNode::fast_is<VariableDeclaration>() const { return is_variable_declaration(); }
template<>
inline bool ASTNode::fast_is<ArrayExpression>() const { return is_array_expression(); }
template<>
inline bool ASTNode::fast_is<ObjectExpression>() const { return is_object_expression(); }
template<>
inline bool ASTNode::fast_is<ImportCall>() const { return is_import_call(); }
template<>
inline bool ASTNode::fast_is<StringLiteral>() const { return is_string_literal(); }
template<>
inline bool ASTNode::fast_is<UpdateExpression>() const { return is_update_expression(); }
template<>
inline bool ASTNode::fast_is<CallExpression>() const { return is_call_expression(); }
template<>
inline bool ASTNode::fast_is<LabelledStatement>() const { return is_labelled_statement(); }
template<>
inline bool ASTNode::fast_is<IterationStatement>() const { return is_iteration_statement(); }
template<>
inline bool ASTNode::fast_is<ClassMethod>() const { return is_class_method(); }
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Reference in a new issue Copy permalink