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

2876 lines
127 KiB
C++
Raw Normal View History

LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +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
* Copyright (c) 2021-2023, Andreas Kling <kling@serenityos.org>
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
* Copyright (c) 2021, Linus Groh <linusg@serenityos.org>
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
* Copyright (c) 2021, Gunnar Beutner <gbeutner@serenityos.org>
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
* Copyright (c) 2021, Marcin Gasperowicz <xnooga@gmail.com>
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
#include <AK/Find.h>
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
#include <LibJS/AST.h>
#include <LibJS/Bytecode/Generator.h>
#include <LibJS/Bytecode/Instruction.h>
#include <LibJS/Bytecode/Op.h>
#include <LibJS/Bytecode/Register.h>
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
#include <LibJS/Bytecode/StringTable.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/Environment.h>
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
#include <LibJS/Runtime/ErrorTypes.h>
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
namespace JS {
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
Bytecode::CodeGenerationErrorOr<void> ASTNode::generate_bytecode(Bytecode::Generator&) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
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
return Bytecode::CodeGenerationError {
this,
"Missing generate_bytecode()"sv,
};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> ScopeNode::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
bool did_create_lexical_environment = false;
LibJS/Bytecode: Actually exit `switch` statement's lexical scope 95 new passes on test262. :^)
2023-06-25 07:37:24 +02:00
if (is<BlockStatement>(*this)) {
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
if (has_lexical_declarations()) {
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
generator.block_declaration_instantiation(*this);
did_create_lexical_environment = true;
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
}
} else if (is<Program>(*this)) {
LibJS/Bytecode: Leave GlobalDeclarationInstantiation in C++ Don't try to implement this AO in bytecode. Instead, the bytecode Interpreter class now has a run() API with the same inputs as the AST interpreter. It sets up the necessary environments etc, including invoking the GlobalDeclarationInstantiation AO.
2023-06-15 12:36:57 +02:00
// GlobalDeclarationInstantiation is handled by the C++ AO.
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
} else {
LibJS/Bytecode: Leave FunctionDeclarationInstantantiation in C++ Instead of trying to implement this AO in bytecode, we can just let it be a C++ thing. Once we implement fast uncaptured locals, we won't even be calling it super often.
2023-06-15 09:14:25 +02:00
// FunctionDeclarationInstantiation is handled by the C++ AO.
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
}
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
for (auto& child : children()) {
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
TRY(child->generate_bytecode(generator));
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
if (generator.is_current_block_terminated())
break;
}
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
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
if (did_create_lexical_environment)
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
generator.end_variable_scope();
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
return {};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> EmptyStatement::generate_bytecode(Bytecode::Generator&) const
LibJS: Add bytecode generation for EmptyStatement
2021-06-07 20:47:26 +02:00
{
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
return {};
LibJS: Add bytecode generation for EmptyStatement
2021-06-07 20:47:26 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> ExpressionStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
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
return m_expression->generate_bytecode(generator);
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> BinaryExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
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
TRY(m_lhs->generate_bytecode(generator));
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
auto lhs_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(lhs_reg);
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
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
TRY(m_rhs->generate_bytecode(generator));
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
switch (m_op) {
case BinaryOp::Addition:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Add>(lhs_reg);
break;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
case BinaryOp::Subtraction:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Sub>(lhs_reg);
break;
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
case BinaryOp::Multiplication:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Mul>(lhs_reg);
break;
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
case BinaryOp::Division:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Div>(lhs_reg);
break;
LibJS: Add bytecode instructions for modulo and exponentiation
2021-06-07 19:37:23 +02:00
case BinaryOp::Modulo:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Mod>(lhs_reg);
break;
LibJS: Add bytecode instructions for modulo and exponentiation
2021-06-07 19:37:23 +02:00
case BinaryOp::Exponentiation:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Exp>(lhs_reg);
break;
LibJS: Add bytecode ops for >, >= and <=
2021-06-07 19:57:38 +02:00
case BinaryOp::GreaterThan:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::GreaterThan>(lhs_reg);
break;
LibJS: Add bytecode ops for >, >= and <=
2021-06-07 19:57:38 +02:00
case BinaryOp::GreaterThanEquals:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::GreaterThanEquals>(lhs_reg);
break;
LibJS: Add LessThan bytecode instruction :^)
2021-06-04 12:03:57 +02:00
case BinaryOp::LessThan:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LessThan>(lhs_reg);
break;
LibJS: Add bytecode ops for >, >= and <=
2021-06-07 19:57:38 +02:00
case BinaryOp::LessThanEquals:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LessThanEquals>(lhs_reg);
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyInequals:
generator.emit<Bytecode::Op::LooselyInequals>(lhs_reg);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::LooselyEquals:
generator.emit<Bytecode::Op::LooselyEquals>(lhs_reg);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyInequals:
generator.emit<Bytecode::Op::StrictlyInequals>(lhs_reg);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-24 00:06:10 +02:00
case BinaryOp::StrictlyEquals:
generator.emit<Bytecode::Op::StrictlyEquals>(lhs_reg);
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
break;
LibJS: Add bytecode ops for &, | and ^
2021-06-07 19:16:04 +01:00
case BinaryOp::BitwiseAnd:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::BitwiseAnd>(lhs_reg);
break;
LibJS: Add bytecode ops for &, | and ^
2021-06-07 19:16:04 +01:00
case BinaryOp::BitwiseOr:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::BitwiseOr>(lhs_reg);
break;
LibJS: Add bytecode ops for &, | and ^
2021-06-07 19:16:04 +01:00
case BinaryOp::BitwiseXor:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::BitwiseXor>(lhs_reg);
break;
LibJS: Add bytecode ops for <<, >> and >>>
2021-06-07 20:14:12 +01:00
case BinaryOp::LeftShift:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LeftShift>(lhs_reg);
break;
LibJS: Add bytecode ops for <<, >> and >>>
2021-06-07 20:14:12 +01:00
case BinaryOp::RightShift:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::RightShift>(lhs_reg);
break;
LibJS: Add bytecode ops for <<, >> and >>>
2021-06-07 20:14:12 +01:00
case BinaryOp::UnsignedRightShift:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::UnsignedRightShift>(lhs_reg);
break;
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
case BinaryOp::In:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::In>(lhs_reg);
break;
LibJS: Add bytecode generation for BinaryOp::InstanceOf
2021-06-07 21:18:19 +01:00
case BinaryOp::InstanceOf:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::InstanceOf>(lhs_reg);
break;
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
default:
LibJS: Add bytecode generation for BinaryOp::InstanceOf
2021-06-07 21:18:19 +01:00
VERIFY_NOT_REACHED();
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
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
return {};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> LogicalExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
{
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
TRY(m_lhs->generate_bytecode(generator));
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// lhs
// jump op (true) end (false) rhs
// rhs
// jump always (true) end
// end
auto& rhs_block = generator.make_block();
auto& end_block = generator.make_block();
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
switch (m_op) {
case LogicalOp::And:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { rhs_block },
Bytecode::Label { end_block });
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
break;
case LogicalOp::Or:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { end_block },
Bytecode::Label { rhs_block });
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
break;
case LogicalOp::NullishCoalescing:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpNullish>().set_targets(
Bytecode::Label { rhs_block },
Bytecode::Label { end_block });
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
break;
default:
VERIFY_NOT_REACHED();
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(rhs_block);
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
TRY(m_rhs->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { end_block },
{});
generator.switch_to_basic_block(end_block);
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
return {};
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> UnaryExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
{
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
if (m_op == UnaryOp::Delete)
return generator.emit_delete_reference(m_lhs);
LibJS/Bytecode: Make typeof return "undefined" on unresolvable IDs Previously it would throw instead of returning "undefined" for `typeof Identifier` if Identifier does not exist.
2022-06-11 23:12:22 +01:00
// Typeof needs some special handling for when the LHS is an Identifier. Namely, it shouldn't throw on unresolvable references, but instead return "undefined".
if (m_op != UnaryOp::Typeof)
TRY(m_lhs->generate_bytecode(generator));
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
switch (m_op) {
case UnaryOp::BitwiseNot:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::BitwiseNot>();
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Not:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Not>();
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Plus:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::UnaryPlus>();
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Minus:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::UnaryMinus>();
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Typeof:
LibJS/Bytecode: Make typeof return "undefined" on unresolvable IDs Previously it would throw instead of returning "undefined" for `typeof Identifier` if Identifier does not exist.
2022-06-11 23:12:22 +01:00
if (is<Identifier>(*m_lhs)) {
auto& identifier = static_cast<Identifier const&>(*m_lhs);
generator.emit<Bytecode::Op::TypeofVariable>(generator.intern_identifier(identifier.string()));
break;
}
TRY(m_lhs->generate_bytecode(generator));
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::Typeof>();
break;
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
case UnaryOp::Void:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
break;
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
case UnaryOp::Delete: // Delete is implemented above.
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
default:
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 19:50:09 +01:00
VERIFY_NOT_REACHED();
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
}
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
return {};
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
}
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
Bytecode::CodeGenerationErrorOr<void> NumericLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LoadImmediate>(m_value);
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
return {};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> BooleanLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
{
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LoadImmediate>(Value(m_value));
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
return {};
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> NullLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
{
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LoadImmediate>(js_null());
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
return {};
LibJS: Add bytecode ops for loading boolean and null values
2021-06-07 20:22:15 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> BigIntLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
{
LibJS: Support non-base-10 BigInt literals in bytecode VM Fixes 39 tests in test262 and a handful in test-js. :^)
2022-10-19 19:17:58 +02:00
// 1. Return the NumericValue of NumericLiteral as defined in 12.8.3.
auto integer = [&] {
if (m_value[0] == '0' && m_value.length() >= 3)
if (m_value[1] == 'x' || m_value[1] == 'X')
return Crypto::SignedBigInteger::from_base(16, m_value.substring(2, m_value.length() - 3));
if (m_value[1] == 'o' || m_value[1] == 'O')
return Crypto::SignedBigInteger::from_base(8, m_value.substring(2, m_value.length() - 3));
if (m_value[1] == 'b' || m_value[1] == 'B')
return Crypto::SignedBigInteger::from_base(2, m_value.substring(2, m_value.length() - 3));
return Crypto::SignedBigInteger::from_base(10, m_value.substring(0, m_value.length() - 1));
}();
generator.emit<Bytecode::Op::NewBigInt>(integer);
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
return {};
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> StringLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
generator.emit<Bytecode::Op::NewString>(generator.intern_string(m_value));
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
return {};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> RegExpLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
{
auto source_index = generator.intern_string(m_pattern);
auto flags_index = generator.intern_string(m_flags);
generator.emit<Bytecode::Op::NewRegExp>(source_index, flags_index);
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
return {};
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
}
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
Bytecode::CodeGenerationErrorOr<void> Identifier::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
generator.emit<Bytecode::Op::GetVariable>(generator.intern_identifier(m_string));
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
return {};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
Everywhere: Use ReadonlySpan<T> instead of Span<T const>
2023-02-05 19:02:54 +00:00
static Bytecode::CodeGenerationErrorOr<void> arguments_to_array_for_call(Bytecode::Generator& generator, ReadonlySpan<CallExpression::Argument> arguments)
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
{
if (arguments.is_empty()) {
generator.emit<Bytecode::Op::NewArray>();
return {};
}
auto first_spread = find_if(arguments.begin(), arguments.end(), [](auto el) { return el.is_spread; });
Bytecode::Register args_start_reg { 0 };
for (auto it = arguments.begin(); it != first_spread; ++it) {
auto reg = generator.allocate_register();
if (args_start_reg.index() == 0)
args_start_reg = reg;
}
u32 i = 0;
for (auto it = arguments.begin(); it != first_spread; ++it, ++i) {
VERIFY(it->is_spread == false);
Bytecode::Register reg { args_start_reg.index() + i };
TRY(it->value->generate_bytecode(generator));
generator.emit<Bytecode::Op::Store>(reg);
}
if (first_spread.index() != 0)
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2u, AK::Array { args_start_reg, Bytecode::Register { args_start_reg.index() + static_cast<u32>(first_spread.index() - 1) } });
else
generator.emit<Bytecode::Op::NewArray>();
if (first_spread != arguments.end()) {
auto array_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(array_reg);
for (auto it = first_spread; it != arguments.end(); ++it) {
TRY(it->value->generate_bytecode(generator));
generator.emit<Bytecode::Op::Append>(array_reg, it->is_spread);
}
generator.emit<Bytecode::Op::Load>(array_reg);
}
return {};
}
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
Bytecode::CodeGenerationErrorOr<void> SuperCall::generate_bytecode(Bytecode::Generator& generator) const
{
if (m_is_synthetic == IsPartOfSyntheticConstructor::Yes) {
// NOTE: This is the case where we have a fake constructor(...args) { super(...args); } which
// shouldn't call @@iterator of %Array.prototype%.
VERIFY(m_arguments.size() == 1);
VERIFY(m_arguments[0].is_spread);
auto const& argument = m_arguments[0];
// This generates a single argument, which will be implicitly passed in accumulator
MUST(argument.value->generate_bytecode(generator));
} else {
LibJS: Handle argument spreading in the bytecode vm
2022-09-09 16:05:40 +02:00
TRY(arguments_to_array_for_call(generator, m_arguments));
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
}
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 23:39:43 +02:00
generator.emit<Bytecode::Op::SuperCall>(m_is_synthetic == IsPartOfSyntheticConstructor::Yes);
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
return {};
}
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
static Bytecode::CodeGenerationErrorOr<void> generate_binding_pattern_bytecode(Bytecode::Generator& generator, BindingPattern const& pattern, Bytecode::Op::SetVariable::InitializationMode, Bytecode::Register const& value_reg, bool create_variables);
LibJS/Bytecode: Implement destructuring assignment
2022-07-17 19:24:37 +01:00
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
Bytecode::CodeGenerationErrorOr<void> AssignmentExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
{
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
if (m_op == AssignmentOp::Assignment) {
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// AssignmentExpression : LeftHandSideExpression = AssignmentExpression
return m_lhs.visit(
// 1. If LeftHandSideExpression is neither an ObjectLiteral nor an ArrayLiteral, then
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& lhs) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// a. Let lref be the result of evaluating LeftHandSideExpression.
// b. ReturnIfAbrupt(lref).
Optional<Bytecode::Register> base_object_register;
Optional<Bytecode::Register> computed_property_register;
if (is<MemberExpression>(*lhs)) {
auto& expression = static_cast<MemberExpression const&>(*lhs);
TRY(expression.object().generate_bytecode(generator));
base_object_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(*base_object_register);
if (expression.is_computed()) {
TRY(expression.property().generate_bytecode(generator));
computed_property_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(*computed_property_register);
// To be continued later with PutByValue.
} else if (expression.property().is_identifier()) {
// Do nothing, this will be handled by PutById later.
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
} else if (expression.property().is_private_identifier()) {
// Do nothing, this will be handled by PutPrivateById later.
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
} else {
return Bytecode::CodeGenerationError {
&expression,
"Unimplemented non-computed member expression"sv
};
}
} else if (is<Identifier>(*lhs)) {
// NOTE: For Identifiers, we cannot perform GetVariable and then write into the reference it retrieves, only SetVariable can do this.
// FIXME: However, this breaks spec as we are doing variable lookup after evaluating the RHS. This is observable in an object environment, where we visibly perform HasOwnProperty and Get(@@unscopables) on the binded object.
} else {
TRY(lhs->generate_bytecode(generator));
}
// FIXME: c. If IsAnonymousFunctionDefinition(AssignmentExpression) and IsIdentifierRef of LeftHandSideExpression are both true, then
// i. Let rval be ? NamedEvaluation of AssignmentExpression with argument lref.[[ReferencedName]].
// d. Else,
// i. Let rref be the result of evaluating AssignmentExpression.
// ii. Let rval be ? GetValue(rref).
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
if (lhs->is_identifier()) {
TRY(generator.emit_named_evaluation_if_anonymous_function(*m_rhs, static_cast<Identifier const&>(*lhs).string()));
} else {
TRY(m_rhs->generate_bytecode(generator));
}
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
// e. Perform ? PutValue(lref, rval).
if (is<Identifier>(*lhs)) {
auto& identifier = static_cast<Identifier const&>(*lhs);
generator.emit<Bytecode::Op::SetVariable>(generator.intern_identifier(identifier.string()));
} else if (is<MemberExpression>(*lhs)) {
auto& expression = static_cast<MemberExpression const&>(*lhs);
if (expression.is_computed()) {
generator.emit<Bytecode::Op::PutByValue>(*base_object_register, *computed_property_register);
} else if (expression.property().is_identifier()) {
auto identifier_table_ref = generator.intern_identifier(verify_cast<Identifier>(expression.property()).string());
generator.emit<Bytecode::Op::PutById>(*base_object_register, identifier_table_ref);
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
} else if (expression.property().is_private_identifier()) {
auto identifier_table_ref = generator.intern_identifier(verify_cast<PrivateIdentifier>(expression.property()).string());
generator.emit<Bytecode::Op::PutPrivateById>(*base_object_register, identifier_table_ref);
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
} else {
return Bytecode::CodeGenerationError {
&expression,
"Unimplemented non-computed member expression"sv
};
}
} else {
return Bytecode::CodeGenerationError {
lhs,
"Unimplemented/invalid node used a reference"sv
};
}
// f. Return rval.
// NOTE: This is already in the accumulator.
return {};
},
// 2. Let assignmentPattern be the AssignmentPattern that is covered by LeftHandSideExpression.
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<BindingPattern const> const& pattern) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS/Bytecode: Implement destructuring assignment
2022-07-17 19:24:37 +01:00
// 3. Let rref be the result of evaluating AssignmentExpression.
// 4. Let rval be ? GetValue(rref).
TRY(m_rhs->generate_bytecode(generator));
auto value_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(value_register);
// 5. Perform ? DestructuringAssignmentEvaluation of assignmentPattern with argument rval.
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
TRY(generate_binding_pattern_bytecode(generator, pattern, Bytecode::Op::SetVariable::InitializationMode::Set, value_register, false));
LibJS/Bytecode: Implement destructuring assignment
2022-07-17 19:24:37 +01:00
// 6. Return rval.
generator.emit<Bytecode::Op::Load>(value_register);
return {};
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
});
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
}
LibJS: Add support for various assignment operators
2021-06-07 20:12:38 +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
VERIFY(m_lhs.has<NonnullRefPtr<Expression const>>());
auto& lhs = m_lhs.get<NonnullRefPtr<Expression const>>();
LibJS/Bytecode: Evaluate LHS of assignment before RHS We had the same issue with the AST interpreter, see issue #3689.
2022-07-17 19:23:52 +01:00
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
TRY(generator.emit_load_from_reference(lhs));
LibJS: Add support for various assignment operators
2021-06-07 20:12:38 +01:00
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
Bytecode::BasicBlock* rhs_block_ptr { nullptr };
Bytecode::BasicBlock* end_block_ptr { nullptr };
LibJS: Add support for various assignment operators
2021-06-07 20:12:38 +01:00
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
// Logical assignments short circuit.
if (m_op == AssignmentOp::AndAssignment) { // &&=
rhs_block_ptr = &generator.make_block();
end_block_ptr = &generator.make_block();
LibJS: Add logical assignment bytecode generation
2021-06-09 21:14:31 +01:00
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { *rhs_block_ptr },
Bytecode::Label { *end_block_ptr });
} else if (m_op == AssignmentOp::OrAssignment) { // ||=
rhs_block_ptr = &generator.make_block();
end_block_ptr = &generator.make_block();
LibJS: Add logical assignment bytecode generation
2021-06-09 21:14:31 +01:00
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { *end_block_ptr },
Bytecode::Label { *rhs_block_ptr });
} else if (m_op == AssignmentOp::NullishAssignment) { // ??=
rhs_block_ptr = &generator.make_block();
end_block_ptr = &generator.make_block();
generator.emit<Bytecode::Op::JumpNullish>().set_targets(
Bytecode::Label { *rhs_block_ptr },
Bytecode::Label { *end_block_ptr });
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
if (rhs_block_ptr)
generator.switch_to_basic_block(*rhs_block_ptr);
// lhs_reg is a part of the rhs_block because the store isn't necessary
// if the logical assignment condition fails.
auto lhs_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(lhs_reg);
LibJS/Bytecode: Use LHS identifier as function name on logical assign This now creates a function named `x`: x ||= function() { } 9 new passes on test262. :^)
2023-06-26 15:26:46 +02:00
if (lhs->is_identifier())
TRY(generator.emit_named_evaluation_if_anonymous_function(*m_rhs, static_cast<Identifier const&>(*lhs).string()));
else
TRY(m_rhs->generate_bytecode(generator));
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
switch (m_op) {
case AssignmentOp::AdditionAssignment:
generator.emit<Bytecode::Op::Add>(lhs_reg);
break;
case AssignmentOp::SubtractionAssignment:
generator.emit<Bytecode::Op::Sub>(lhs_reg);
break;
case AssignmentOp::MultiplicationAssignment:
generator.emit<Bytecode::Op::Mul>(lhs_reg);
break;
case AssignmentOp::DivisionAssignment:
generator.emit<Bytecode::Op::Div>(lhs_reg);
break;
case AssignmentOp::ModuloAssignment:
generator.emit<Bytecode::Op::Mod>(lhs_reg);
break;
case AssignmentOp::ExponentiationAssignment:
generator.emit<Bytecode::Op::Exp>(lhs_reg);
break;
case AssignmentOp::BitwiseAndAssignment:
generator.emit<Bytecode::Op::BitwiseAnd>(lhs_reg);
break;
case AssignmentOp::BitwiseOrAssignment:
generator.emit<Bytecode::Op::BitwiseOr>(lhs_reg);
break;
case AssignmentOp::BitwiseXorAssignment:
generator.emit<Bytecode::Op::BitwiseXor>(lhs_reg);
break;
case AssignmentOp::LeftShiftAssignment:
generator.emit<Bytecode::Op::LeftShift>(lhs_reg);
break;
case AssignmentOp::RightShiftAssignment:
generator.emit<Bytecode::Op::RightShift>(lhs_reg);
break;
case AssignmentOp::UnsignedRightShiftAssignment:
generator.emit<Bytecode::Op::UnsignedRightShift>(lhs_reg);
break;
case AssignmentOp::AndAssignment:
case AssignmentOp::OrAssignment:
case AssignmentOp::NullishAssignment:
break; // These are handled above.
default:
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
return Bytecode::CodeGenerationError {
this,
"Unimplemented operation"sv,
};
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
}
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
TRY(generator.emit_store_to_reference(lhs));
LibJS: Support more assignment expressions in the bytecode VM Use the new reference get/put helpers in BytecodeGenerator to support assignment expressions other than just plain assignment.
2021-10-25 15:29:52 +02:00
if (end_block_ptr) {
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { *end_block_ptr },
{});
generator.switch_to_basic_block(*end_block_ptr);
}
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
return {};
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
// 14.13.3 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-labelled-statements-runtime-semantics-evaluation
// LabelledStatement : LabelIdentifier : LabelledItem
Bytecode::CodeGenerationErrorOr<void> LabelledStatement::generate_bytecode(Bytecode::Generator& generator) const
{
// Return ? LabelledEvaluation of this LabelledStatement with argument « ».
return generate_labelled_evaluation(generator, {});
}
// 14.13.4 Runtime Semantics: LabelledEvaluation, https://tc39.es/ecma262/#sec-runtime-semantics-labelledevaluation
// LabelledStatement : LabelIdentifier : LabelledItem
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
Bytecode::CodeGenerationErrorOr<void> LabelledStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
// Convert the m_labelled_item NNRP to a reference early so we don't have to do it every single time we want to use it.
auto const& labelled_item = *m_labelled_item;
// 1. Let label be the StringValue of LabelIdentifier.
// NOTE: Not necessary, this is m_label.
// 2. Let newLabelSet be the list-concatenation of labelSet and « label ».
// FIXME: Avoid copy here.
auto new_label_set = label_set;
new_label_set.append(m_label);
// 3. Let stmtResult be LabelledEvaluation of LabelledItem with argument newLabelSet.
// NOTE: stmtResult will be in the accumulator after running the generated bytecode.
if (is<IterationStatement>(labelled_item)) {
auto const& iteration_statement = static_cast<IterationStatement const&>(labelled_item);
TRY(iteration_statement.generate_labelled_evaluation(generator, new_label_set));
} else if (is<SwitchStatement>(labelled_item)) {
auto const& switch_statement = static_cast<SwitchStatement const&>(labelled_item);
TRY(switch_statement.generate_labelled_evaluation(generator, new_label_set));
} else if (is<LabelledStatement>(labelled_item)) {
auto const& labelled_statement = static_cast<LabelledStatement const&>(labelled_item);
TRY(labelled_statement.generate_labelled_evaluation(generator, new_label_set));
} else {
auto& labelled_break_block = generator.make_block();
// NOTE: We do not need a continuable scope as `continue;` is not allowed outside of iteration statements, throwing a SyntaxError in the parser.
generator.begin_breakable_scope(Bytecode::Label { labelled_break_block }, new_label_set);
TRY(labelled_item.generate_bytecode(generator));
generator.end_breakable_scope();
if (!generator.is_current_block_terminated()) {
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { labelled_break_block },
{});
}
generator.switch_to_basic_block(labelled_break_block);
}
// 4. If stmtResult.[[Type]] is break and SameValue(stmtResult.[[Target]], label) is true, then
// a. Set stmtResult to NormalCompletion(stmtResult.[[Value]]).
// NOTE: These steps are performed by making labelled break jump straight to the appropriate break block, which preserves the statement result's value in the accumulator.
// 5. Return Completion(stmtResult).
// NOTE: This is in the accumulator.
return {};
}
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
Bytecode::CodeGenerationErrorOr<void> IterationStatement::generate_labelled_evaluation(Bytecode::Generator&, Vector<DeprecatedFlyString> const&) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
return Bytecode::CodeGenerationError {
this,
"Missing generate_labelled_evaluation()"sv,
};
}
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
Bytecode::CodeGenerationErrorOr<void> WhileStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
return generate_labelled_evaluation(generator, {});
}
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
Bytecode::CodeGenerationErrorOr<void> WhileStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
{
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// test
// jump if_false (true) end (false) body
// body
// jump always (true) test
// end
auto& test_block = generator.make_block();
auto& body_block = generator.make_block();
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
auto& load_result_and_jump_to_end_block = generator.make_block();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
auto& end_block = generator.make_block();
// Init result register
LibJS: Make sure loop results are initialized This ensures that "while", do...while, "for" expressions have a properly initialized result value even if the user terminated the loop body via break or the loop body wasn't executed at all.
2021-06-08 22:17:00 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
auto result_reg = generator.allocate_register();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// jump to the test block
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { test_block },
{});
generator.switch_to_basic_block(test_block);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.emit<Bytecode::Op::Store>(result_reg);
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
TRY(m_test->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { body_block },
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
Bytecode::Label { load_result_and_jump_to_end_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(body_block);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_continuable_scope(Bytecode::Label { test_block }, label_set);
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set);
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
TRY(m_body->generate_bytecode(generator));
LibJS/Bytecode: Unconditionally end break/continuable scopes Previously we would only end these scopes if the block was not terminated. If the block was generated, we would not end the scope and would generate other bytecode with these scopes still open. These functions do not generate any code, so they can be used even if the current block is terminated. The enter and end scope functions are only used to track where to unwind to when break/continue are used.
2022-03-14 02:13:33 +00:00
generator.end_breakable_scope();
generator.end_continuable_scope();
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
if (!generator.is_current_block_terminated()) {
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { test_block },
{});
}
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
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.switch_to_basic_block(load_result_and_jump_to_end_block);
LibJS/Bytecode: Make for, do/while and while always switch to end block Previously we only did this if the body block was not terminated. If it was, all future codegen would happen in this block terminated body block until another switch occurred, dropping all generated instructions in this time on the floor.
2022-06-30 14:29:43 +01:00
generator.emit<Bytecode::Op::Load>(result_reg);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(end_block);
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
return {};
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> DoWhileStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
return generate_labelled_evaluation(generator, {});
}
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
Bytecode::CodeGenerationErrorOr<void> DoWhileStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
{
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// jump always (true) body
// test
// jump if_false (true) end (false) body
// body
// jump always (true) test
// end
auto& test_block = generator.make_block();
auto& body_block = generator.make_block();
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
auto& load_result_and_jump_to_end_block = generator.make_block();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
auto& end_block = generator.make_block();
// Init result register
LibJS: Make sure loop results are initialized This ensures that "while", do...while, "for" expressions have a properly initialized result value even if the user terminated the loop body via break or the loop body wasn't executed at all.
2021-06-08 22:17:00 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
auto result_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(result_reg);
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// jump to the body block
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { body_block },
{});
generator.switch_to_basic_block(test_block);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.emit<Bytecode::Op::Store>(result_reg);
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
TRY(m_test->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { body_block },
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
Bytecode::Label { load_result_and_jump_to_end_block });
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(body_block);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_continuable_scope(Bytecode::Label { test_block }, label_set);
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set);
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
TRY(m_body->generate_bytecode(generator));
LibJS/Bytecode: Unconditionally end break/continuable scopes Previously we would only end these scopes if the block was not terminated. If the block was generated, we would not end the scope and would generate other bytecode with these scopes still open. These functions do not generate any code, so they can be used even if the current block is terminated. The enter and end scope functions are only used to track where to unwind to when break/continue are used.
2022-03-14 02:13:33 +00:00
generator.end_breakable_scope();
generator.end_continuable_scope();
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
if (!generator.is_current_block_terminated()) {
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { test_block },
{});
}
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
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.switch_to_basic_block(load_result_and_jump_to_end_block);
LibJS/Bytecode: Make for, do/while and while always switch to end block Previously we only did this if the body block was not terminated. If it was, all future codegen would happen in this block terminated body block until another switch occurred, dropping all generated instructions in this time on the floor.
2022-06-30 14:29:43 +01:00
generator.emit<Bytecode::Op::Load>(result_reg);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(end_block);
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
return {};
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> ForStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
return generate_labelled_evaluation(generator, {});
}
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
Bytecode::CodeGenerationErrorOr<void> ForStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
{
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// init
// jump always (true) test
// test
// jump if_true (true) body (false) end
// body
// jump always (true) update
// update
// jump always (true) test
// end
// If 'test' is missing, fuse the 'test' and 'body' basic blocks
// If 'update' is missing, fuse the 'body' and 'update' basic blocks
Bytecode::BasicBlock* test_block_ptr { nullptr };
Bytecode::BasicBlock* body_block_ptr { nullptr };
Bytecode::BasicBlock* update_block_ptr { nullptr };
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
Bytecode::BasicBlock* load_result_and_jump_to_end_block_ptr { nullptr };
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
auto& end_block = generator.make_block();
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
bool has_lexical_environment = false;
if (m_init) {
if (m_init->is_variable_declaration()) {
auto& variable_declaration = verify_cast<VariableDeclaration>(*m_init);
if (variable_declaration.is_lexical_declaration()) {
has_lexical_environment = true;
// FIXME: Is Block correct?
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
generator.begin_variable_scope();
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
bool is_const = variable_declaration.is_constant_declaration();
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
MUST(variable_declaration.for_each_bound_name([&](auto const& name) {
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
auto index = generator.intern_identifier(name);
generator.emit<Bytecode::Op::CreateVariable>(index, Bytecode::Op::EnvironmentMode::Lexical, is_const);
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
}));
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
}
}
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
TRY(m_init->generate_bytecode(generator));
LibJS/Bytecode: Setup declarative environment for lexical for statements
2022-03-14 02:39:24 +00:00
}
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
body_block_ptr = &generator.make_block();
if (m_test)
test_block_ptr = &generator.make_block();
else
test_block_ptr = body_block_ptr;
if (m_update)
update_block_ptr = &generator.make_block();
else
update_block_ptr = body_block_ptr;
LibJS: Make sure loop results are initialized This ensures that "while", do...while, "for" expressions have a properly initialized result value even if the user terminated the loop body via break or the loop body wasn't executed at all.
2021-06-08 22:17:00 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
auto result_reg = generator.allocate_register();
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
if (m_test && m_update)
generator.emit<Bytecode::Op::Store>(result_reg);
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { *test_block_ptr },
{});
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
if (m_test) {
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
load_result_and_jump_to_end_block_ptr = &generator.make_block();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(*test_block_ptr);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
if (!m_update)
generator.emit<Bytecode::Op::Store>(result_reg);
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
TRY(m_test->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { *body_block_ptr },
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
Bytecode::Label { *load_result_and_jump_to_end_block_ptr });
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
}
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
LibJS/Bytecode: Fix multiple wrong jumps in ForStatement codegen
2023-06-15 19:13:00 +02:00
if (m_update) {
generator.switch_to_basic_block(*update_block_ptr);
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
if (m_test)
generator.emit<Bytecode::Op::Store>(result_reg);
LibJS/Bytecode: Fix multiple wrong jumps in ForStatement codegen
2023-06-15 19:13:00 +02:00
TRY(m_update->generate_bytecode(generator));
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { *test_block_ptr },
{});
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(*body_block_ptr);
LibJS/Bytecode: Fix multiple wrong jumps in ForStatement codegen
2023-06-15 19:13:00 +02:00
generator.begin_continuable_scope(Bytecode::Label { m_update ? *update_block_ptr : *test_block_ptr }, label_set);
LibJS/Bytecode: Don't begin breakable scope before variable scope in for This is no longer required, since the variable scope is ended after switching to the end block, which means that LeaveLexicalEnvironment will always be generated instead of depending on the unwind mechanism to handle it for us.
2022-07-17 19:22:18 +01:00
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set);
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
TRY(m_body->generate_bytecode(generator));
LibJS/Bytecode: Don't begin breakable scope before variable scope in for This is no longer required, since the variable scope is ended after switching to the end block, which means that LeaveLexicalEnvironment will always be generated instead of depending on the unwind mechanism to handle it for us.
2022-07-17 19:22:18 +01:00
generator.end_breakable_scope();
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
generator.end_continuable_scope();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
if (!generator.is_current_block_terminated()) {
if (m_update) {
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { *update_block_ptr },
{});
LibJS/Bytecode: Fix multiple wrong jumps in ForStatement codegen
2023-06-15 19:13:00 +02:00
} else {
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { *test_block_ptr },
{});
LibJS: Don't generate code after we've encountered a terminating op
2021-06-09 19:57:18 +02:00
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
}
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
LibJS/Bytecode: Return the proper result for iteration statements
2023-06-25 20:52:35 +01:00
if (load_result_and_jump_to_end_block_ptr) {
generator.switch_to_basic_block(*load_result_and_jump_to_end_block_ptr);
generator.emit<Bytecode::Op::Load>(result_reg);
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
}
LibJS/Bytecode: End the for variable scope at the start of its end block If the for loop's body is not block terminated, we will generate a Jump to the end block which will block terminate the body. Then, we ended the lexical variable scope if needed. However, since the body is now block terminated, the "LeaveLexicalEnvironment" instruction that is generated by end_variable_scope is now dropped on the floor. This fixes this by moving it to the beginning of the end block.
2022-06-30 15:55:57 +01:00
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: End for's variable scope after update block generation The update block can generate bytecode that refers to the lexical environment, so we have to end the scope after it has been generated. Previously the Jump to the update block would terminate the block, causing us to leave the lexical environment just before jumping to the update block.
2022-03-15 01:44:32 +00:00
if (has_lexical_environment)
generator.end_variable_scope();
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
return {};
LibJS: Add for loop bytecode generation
2021-06-08 10:54:40 +01:00
}
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
Bytecode::CodeGenerationErrorOr<void> ObjectExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
{
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::NewObject>();
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
if (m_properties.is_empty())
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
return {};
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
auto object_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(object_reg);
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
generator.push_home_object(object_reg);
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
for (auto& property : m_properties) {
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
Bytecode::Op::PropertyKind property_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
switch (property->type()) {
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
case ObjectProperty::Type::KeyValue:
property_kind = Bytecode::Op::PropertyKind::KeyValue;
break;
case ObjectProperty::Type::Getter:
property_kind = Bytecode::Op::PropertyKind::Getter;
break;
case ObjectProperty::Type::Setter:
property_kind = Bytecode::Op::PropertyKind::Setter;
break;
case ObjectProperty::Type::Spread:
property_kind = Bytecode::Op::PropertyKind::Spread;
break;
case ObjectProperty::Type::ProtoSetter:
property_kind = Bytecode::Op::PropertyKind::ProtoSetter;
break;
}
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03: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
if (is<StringLiteral>(property->key())) {
auto& string_literal = static_cast<StringLiteral const&>(property->key());
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
Bytecode::IdentifierTableIndex key_name = generator.intern_identifier(string_literal.value());
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
LibJS/Bytecode: Transfer object expression property names to functions 2 new passes on test262. :^)
2023-06-25 19:25:38 +02:00
if (property_kind == Bytecode::Op::PropertyKind::ProtoSetter) {
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
TRY(property->value().generate_bytecode(generator));
LibJS/Bytecode: Transfer object expression property names to functions 2 new passes on test262. :^)
2023-06-25 19:25:38 +02:00
} else if (property_kind != Bytecode::Op::PropertyKind::Spread) {
DeprecatedFlyString name = string_literal.value();
TRY(generator.emit_named_evaluation_if_anonymous_function(property->value(), name));
}
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
generator.emit<Bytecode::Op::PutById>(object_reg, key_name, property_kind);
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
} else {
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
TRY(property->key().generate_bytecode(generator));
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
auto property_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(property_reg);
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
if (property_kind != Bytecode::Op::PropertyKind::Spread)
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
TRY(property->value().generate_bytecode(generator));
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
generator.emit<Bytecode::Op::PutByValue>(object_reg, property_reg, property_kind);
LibJS: Add bytecode generation for simple ObjectExpressions Bytecode is now generated for object literals which only contain simple key-value pairs (i.e. no spread, getters or setters)
2021-06-11 19:40:48 +03:00
}
}
generator.emit<Bytecode::Op::Load>(object_reg);
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
generator.pop_home_object();
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
return {};
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> ArrayExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
{
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
if (m_elements.is_empty()) {
generator.emit<Bytecode::Op::NewArray>();
return {};
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
}
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
auto first_spread = find_if(m_elements.begin(), m_elements.end(), [](auto el) { return el && is<SpreadExpression>(*el); });
Bytecode::Register args_start_reg { 0 };
for (auto it = m_elements.begin(); it != first_spread; ++it) {
auto reg = generator.allocate_register();
if (args_start_reg.index() == 0)
args_start_reg = reg;
}
u32 i = 0;
for (auto it = m_elements.begin(); it != first_spread; ++it, ++i) {
Bytecode::Register reg { args_start_reg.index() + i };
if (!*it)
LibJS: Only set element in array literal to an empty value if it's null This avoids an unnecessary empty load that immediately gets overridden. For example, `[1,,]` would appear as: [ 0] EnterScope [ 10] LoadImmediate value:<empty> [ 28] LoadImmediate value:1 [ 40] Store dst:$1 [ 48] LoadImmediate value:<empty> [ 60] Store dst:$2 [ 68] NewArray, elements:[$1,$2] But now appears as: [ 0] EnterScope [ 10] LoadImmediate value:1 [ 28] Store dst:$1 [ 30] LoadImmediate value:<empty> [ 48] Store dst:$2 [ 50] NewArray, elements:[$1,$2]
2021-06-09 04:43:13 +01:00
generator.emit<Bytecode::Op::LoadImmediate>(Value {});
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
else {
TRY((*it)->generate_bytecode(generator));
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
}
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
generator.emit<Bytecode::Op::Store>(reg);
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
}
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
if (first_spread.index() != 0)
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2u, AK::Array { args_start_reg, Bytecode::Register { args_start_reg.index() + static_cast<u32>(first_spread.index() - 1) } });
else
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
generator.emit<Bytecode::Op::NewArray>();
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
if (first_spread != m_elements.end()) {
auto array_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(array_reg);
for (auto it = first_spread; it != m_elements.end(); ++it) {
if (!*it) {
generator.emit<Bytecode::Op::LoadImmediate>(Value {});
generator.emit<Bytecode::Op::Append>(array_reg, false);
} else {
TRY((*it)->generate_bytecode(generator));
generator.emit<Bytecode::Op::Append>(array_reg, *it && is<SpreadExpression>(**it));
}
}
generator.emit<Bytecode::Op::Load>(array_reg);
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
}
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 15:23:02 +02:00
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
return {};
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> MemberExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
{
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
return generator.emit_load_from_reference(*this);
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
}
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
Bytecode::CodeGenerationErrorOr<void> FunctionDeclaration::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
{
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
if (m_is_hoisted) {
auto index = generator.intern_identifier(name());
generator.emit<Bytecode::Op::GetVariable>(index);
LibJS: Initialize 'var' bindings to undefined on declaration This is what CreateGlobalVarBinding does, so do the same thing in BC.
2022-03-13 12:43:45 +03:30
generator.emit<Bytecode::Op::SetVariable>(index, Bytecode::Op::SetVariable::InitializationMode::Set, Bytecode::Op::EnvironmentMode::Var);
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
}
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
return {};
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> FunctionExpression::generate_bytecode_with_lhs_name(Bytecode::Generator& generator, Optional<DeprecatedFlyString const&> lhs_name) const
LibJS: Add bytecode generation for FunctionExpression :^)
2021-06-11 10:46:46 +02:00
{
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
bool has_name = !name().is_empty();
Optional<Bytecode::IdentifierTableIndex> name_identifier;
if (has_name) {
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
generator.begin_variable_scope();
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
name_identifier = generator.intern_identifier(name());
generator.emit<Bytecode::Op::CreateVariable>(*name_identifier, Bytecode::Op::EnvironmentMode::Lexical, true);
}
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
generator.emit_new_function(*this, lhs_name);
LibJS/Bytecode: Define named functions as a variable inside their scope This allows you to recurse into a named function that is stored in a variable. For example, this would previously print "wrong" instead of "right": ```js function g() { console.log("wrong") } f = function g(i) { if (i !== 1) g(1); else console.log("right"); } f() ```
2022-06-11 23:24:55 +01:00
if (has_name) {
generator.emit<Bytecode::Op::SetVariable>(*name_identifier, Bytecode::Op::SetVariable::InitializationMode::Initialize, Bytecode::Op::EnvironmentMode::Lexical);
generator.end_variable_scope();
}
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
return {};
LibJS: Add bytecode generation for FunctionExpression :^)
2021-06-11 10:46:46 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> FunctionExpression::generate_bytecode(Bytecode::Generator& generator) const
{
return generate_bytecode_with_lhs_name(generator, {});
}
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
static Bytecode::CodeGenerationErrorOr<void> generate_object_binding_pattern_bytecode(Bytecode::Generator& generator, BindingPattern const& pattern, Bytecode::Op::SetVariable::InitializationMode initialization_mode, Bytecode::Register const& value_reg, bool create_variables)
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
{
LibJS/Bytecode: Throw on destructuring object assignment to nullish LHS 24 new passes on test262. :^)
2023-06-25 08:50:07 +02:00
generator.emit<Bytecode::Op::ThrowIfNullish>();
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
Vector<Bytecode::Register> excluded_property_names;
auto has_rest = false;
if (pattern.entries.size() > 0)
has_rest = pattern.entries[pattern.entries.size() - 1].is_rest;
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
for (auto& [name, alias, initializer, is_rest] : pattern.entries) {
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
if (is_rest) {
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
VERIFY(name.has<NonnullRefPtr<Identifier const>>());
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
VERIFY(alias.has<Empty>());
VERIFY(!initializer);
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
auto identifier = name.get<NonnullRefPtr<Identifier const>>()->string();
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
auto interned_identifier = generator.intern_identifier(identifier);
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
generator.emit_with_extra_register_slots<Bytecode::Op::CopyObjectExcludingProperties>(excluded_property_names.size(), value_reg, excluded_property_names);
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
if (create_variables)
generator.emit<Bytecode::Op::CreateVariable>(interned_identifier, Bytecode::Op::EnvironmentMode::Lexical, false);
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
generator.emit<Bytecode::Op::SetVariable>(interned_identifier, initialization_mode);
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
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
return {};
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
Bytecode::StringTableIndex name_index;
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -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
if (name.has<NonnullRefPtr<Identifier const>>()) {
auto identifier = name.get<NonnullRefPtr<Identifier const>>()->string();
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
name_index = generator.intern_string(identifier);
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
if (has_rest) {
auto excluded_name_reg = generator.allocate_register();
excluded_property_names.append(excluded_name_reg);
generator.emit<Bytecode::Op::NewString>(name_index);
generator.emit<Bytecode::Op::Store>(excluded_name_reg);
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.emit<Bytecode::Op::Load>(value_reg);
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
generator.emit<Bytecode::Op::GetById>(generator.intern_identifier(identifier));
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
} else {
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
auto expression = name.get<NonnullRefPtr<Expression const>>();
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
TRY(expression->generate_bytecode(generator));
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
if (has_rest) {
auto excluded_name_reg = generator.allocate_register();
excluded_property_names.append(excluded_name_reg);
generator.emit<Bytecode::Op::Store>(excluded_name_reg);
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.emit<Bytecode::Op::GetByValue>(value_reg);
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
if (initializer) {
auto& if_undefined_block = generator.make_block();
auto& if_not_undefined_block = generator.make_block();
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.emit<Bytecode::Op::JumpUndefined>().set_targets(
Bytecode::Label { if_undefined_block },
Bytecode::Label { if_not_undefined_block });
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.switch_to_basic_block(if_undefined_block);
LibJS/Bytecode: Prefer alias over name in object pattern bindings 10 new passes on test262. :^)
2023-06-27 14:41:09 +02:00
if (auto const* alias_identifier = alias.get_pointer<NonnullRefPtr<Identifier const>>()) {
TRY(generator.emit_named_evaluation_if_anonymous_function(*initializer, (*alias_identifier)->string()));
} else if (auto const* lhs = name.get_pointer<NonnullRefPtr<Identifier const>>()) {
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
TRY(generator.emit_named_evaluation_if_anonymous_function(*initializer, (*lhs)->string()));
} else {
TRY(initializer->generate_bytecode(generator));
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { if_not_undefined_block },
{});
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.switch_to_basic_block(if_not_undefined_block);
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -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
if (alias.has<NonnullRefPtr<BindingPattern const>>()) {
auto& binding_pattern = *alias.get<NonnullRefPtr<BindingPattern const>>();
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
auto nested_value_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(nested_value_reg);
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
TRY(generate_binding_pattern_bytecode(generator, binding_pattern, initialization_mode, nested_value_reg, create_variables));
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
} else if (alias.has<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
if (name.has<NonnullRefPtr<Expression const>>()) {
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
// This needs some sort of SetVariableByValue opcode, as it's a runtime binding
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
return Bytecode::CodeGenerationError {
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
name.get<NonnullRefPtr<Expression const>>().ptr(),
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
"Unimplemented name/alias pair: Empty/Expression"sv,
};
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -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
auto& identifier = name.get<NonnullRefPtr<Identifier const>>()->string();
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
auto identifier_ref = generator.intern_identifier(identifier);
if (create_variables)
generator.emit<Bytecode::Op::CreateVariable>(identifier_ref, Bytecode::Op::EnvironmentMode::Lexical, false);
generator.emit<Bytecode::Op::SetVariable>(identifier_ref, initialization_mode);
LibJS/Bytecode: Handle object destructuring to member expression 19 new passes on test262. :^)
2023-06-25 16:24:05 +02:00
} else if (alias.has<NonnullRefPtr<MemberExpression const>>()) {
TRY(generator.emit_store_to_reference(alias.get<NonnullRefPtr<MemberExpression const>>()));
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
} else {
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
auto& identifier = alias.get<NonnullRefPtr<Identifier const>>()->string();
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
auto identifier_ref = generator.intern_identifier(identifier);
if (create_variables)
generator.emit<Bytecode::Op::CreateVariable>(identifier_ref, Bytecode::Op::EnvironmentMode::Lexical, false);
generator.emit<Bytecode::Op::SetVariable>(identifier_ref, initialization_mode);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
}
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
return {};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
static Bytecode::CodeGenerationErrorOr<void> generate_array_binding_pattern_bytecode(Bytecode::Generator& generator, BindingPattern const& pattern, Bytecode::Op::SetVariable::InitializationMode initialization_mode, Bytecode::Register const& value_reg, bool create_variables)
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
/*
* Consider the following destructuring assignment:
*
* let [a, b, c, d, e] = o;
*
* It would be fairly trivial to just loop through this iterator, getting the value
* at each step and assigning them to the binding sequentially. However, this is not
* correct: once an iterator is exhausted, it must not be called again. This complicates
* the bytecode. In order to accomplish this, we do the following:
*
* - Reserve a special boolean register which holds 'true' if the iterator is exhausted,
* and false otherwise
* - When we are retrieving the value which should be bound, we first check this register.
* If it is 'true', we load undefined into the accumulator. Otherwise, we grab the next
* value from the iterator and store it into the accumulator.
*
* Note that the is_exhausted register does not need to be loaded with false because the
* first IteratorNext bytecode is _not_ proceeded by an exhausted check, as it is
* unnecessary.
*/
auto is_iterator_exhausted_register = generator.allocate_register();
LibJS/Bytecode: Ensure iterator is closed after array destructuring If destructuring didn't exhaust the iterator, we have to manually close the iterator. 49 new passes on test262. :^)
2023-06-26 17:21:12 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(Value(false));
generator.emit<Bytecode::Op::Store>(is_iterator_exhausted_register);
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
auto iterator_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Load>(value_reg);
generator.emit<Bytecode::Op::GetIterator>();
generator.emit<Bytecode::Op::Store>(iterator_reg);
bool first = true;
auto temp_iterator_result_reg = generator.allocate_register();
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
auto assign_accumulator_to_alias = [&](auto& alias) {
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
return alias.visit(
[&](Empty) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
// This element is an elision
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
return {};
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -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
[&](NonnullRefPtr<Identifier const> const& identifier) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
auto interned_index = generator.intern_identifier(identifier->string());
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
if (create_variables)
generator.emit<Bytecode::Op::CreateVariable>(interned_index, Bytecode::Op::EnvironmentMode::Lexical, false);
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
generator.emit<Bytecode::Op::SetVariable>(interned_index, initialization_mode);
return {};
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -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
[&](NonnullRefPtr<BindingPattern const> const& pattern) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
// Store the accumulator value in a permanent register
auto target_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(target_reg);
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
return generate_binding_pattern_bytecode(generator, pattern, initialization_mode, target_reg, create_variables);
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
},
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<MemberExpression const> const& expr) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS: Implement codegen for MemberExpression binding patterns
2022-03-31 03:09:08 +04:30
return generator.emit_store_to_reference(*expr);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
});
};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
for (auto& [name, alias, initializer, is_rest] : pattern.entries) {
VERIFY(name.has<Empty>());
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
if (is_rest) {
LibJS/Bytecode: Implement initializers for array binding patterns
2022-07-17 19:25:23 +01:00
VERIFY(!initializer);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
if (first) {
// The iterator has not been called, and is thus known to be not exhausted
generator.emit<Bytecode::Op::Load>(iterator_reg);
generator.emit<Bytecode::Op::IteratorToArray>();
} else {
auto& if_exhausted_block = generator.make_block();
auto& if_not_exhausted_block = generator.make_block();
auto& continuation_block = generator.make_block();
generator.emit<Bytecode::Op::Load>(is_iterator_exhausted_register);
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { if_exhausted_block },
Bytecode::Label { if_not_exhausted_block });
generator.switch_to_basic_block(if_exhausted_block);
generator.emit<Bytecode::Op::NewArray>();
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { continuation_block },
{});
generator.switch_to_basic_block(if_not_exhausted_block);
generator.emit<Bytecode::Op::Load>(iterator_reg);
generator.emit<Bytecode::Op::IteratorToArray>();
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { continuation_block },
{});
generator.switch_to_basic_block(continuation_block);
}
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
return assign_accumulator_to_alias(alias);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
// In the first iteration of the loop, a few things are true which can save
// us some bytecode:
// - the iterator result is still in the accumulator, so we can avoid a load
// - the iterator is not yet exhausted, which can save us a jump and some
// creation
auto& iterator_is_exhausted_block = generator.make_block();
if (!first) {
auto& iterator_is_not_exhausted_block = generator.make_block();
generator.emit<Bytecode::Op::Load>(is_iterator_exhausted_register);
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { iterator_is_exhausted_block },
Bytecode::Label { iterator_is_not_exhausted_block });
generator.switch_to_basic_block(iterator_is_not_exhausted_block);
generator.emit<Bytecode::Op::Load>(iterator_reg);
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
generator.emit<Bytecode::Op::IteratorNext>();
generator.emit<Bytecode::Op::Store>(temp_iterator_result_reg);
generator.emit<Bytecode::Op::IteratorResultDone>();
generator.emit<Bytecode::Op::Store>(is_iterator_exhausted_register);
// We still have to check for exhaustion here. If the iterator is exhausted,
// we need to bail before trying to get the value
auto& no_bail_block = generator.make_block();
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { iterator_is_exhausted_block },
Bytecode::Label { no_bail_block });
generator.switch_to_basic_block(no_bail_block);
// Get the next value in the iterator
generator.emit<Bytecode::Op::Load>(temp_iterator_result_reg);
generator.emit<Bytecode::Op::IteratorResultValue>();
auto& create_binding_block = generator.make_block();
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { create_binding_block },
{});
// The iterator is exhausted, so we just load undefined and continue binding
generator.switch_to_basic_block(iterator_is_exhausted_block);
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { create_binding_block },
{});
// Create the actual binding. The value which this entry must bind is now in the
// accumulator. We can proceed, processing the alias as a nested destructuring
// pattern if necessary.
generator.switch_to_basic_block(create_binding_block);
LibJS/Bytecode: Implement initializers for array binding patterns
2022-07-17 19:25:23 +01:00
if (initializer) {
auto& value_is_undefined_block = generator.make_block();
auto& value_is_not_undefined_block = generator.make_block();
generator.emit<Bytecode::Op::JumpUndefined>().set_targets(
Bytecode::Label { value_is_undefined_block },
Bytecode::Label { value_is_not_undefined_block });
generator.switch_to_basic_block(value_is_undefined_block);
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
LibJS/Bytecode: Transfer binding pattern aliases to function names 60 new passes on test262. :^)
2023-06-25 11:11:36 +02:00
if (auto const* alias_identifier = alias.get_pointer<NonnullRefPtr<Identifier const>>()) {
TRY(generator.emit_named_evaluation_if_anonymous_function(*initializer, (*alias_identifier)->string()));
} else if (auto const* name_identifier = name.get_pointer<NonnullRefPtr<Identifier const>>()) {
TRY(generator.emit_named_evaluation_if_anonymous_function(*initializer, (*name_identifier)->string()));
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
} else {
TRY(initializer->generate_bytecode(generator));
}
LibJS/Bytecode: Implement initializers for array binding patterns
2022-07-17 19:25:23 +01:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { value_is_not_undefined_block });
generator.switch_to_basic_block(value_is_not_undefined_block);
}
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
TRY(assign_accumulator_to_alias(alias));
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
first = false;
}
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
LibJS/Bytecode: Ensure iterator is closed after array destructuring If destructuring didn't exhaust the iterator, we have to manually close the iterator. 49 new passes on test262. :^)
2023-06-26 17:21:12 +02:00
auto& done_block = generator.make_block();
auto& not_done_block = generator.make_block();
generator.emit<Bytecode::Op::Load>(is_iterator_exhausted_register);
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { done_block },
Bytecode::Label { not_done_block });
generator.switch_to_basic_block(not_done_block);
generator.emit<Bytecode::Op::Load>(iterator_reg);
generator.emit<Bytecode::Op::IteratorClose>(Completion::Type::Normal, Optional<Value> {});
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { done_block });
generator.switch_to_basic_block(done_block);
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
return {};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
static Bytecode::CodeGenerationErrorOr<void> generate_binding_pattern_bytecode(Bytecode::Generator& generator, BindingPattern const& pattern, Bytecode::Op::SetVariable::InitializationMode initialization_mode, Bytecode::Register const& value_reg, bool create_variables)
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
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
if (pattern.kind == BindingPattern::Kind::Object)
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
return generate_object_binding_pattern_bytecode(generator, pattern, initialization_mode, value_reg, create_variables);
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
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
return generate_array_binding_pattern_bytecode(generator, pattern, initialization_mode, value_reg, create_variables);
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
}
LibJS: Support object destructuring in the bytecode interpreter
2021-06-13 12:24:55 -07:00
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
static Bytecode::CodeGenerationErrorOr<void> assign_accumulator_to_variable_declarator(Bytecode::Generator& generator, VariableDeclarator const& declarator, VariableDeclaration const& declaration)
{
auto initialization_mode = declaration.is_lexical_declaration() ? Bytecode::Op::SetVariable::InitializationMode::Initialize : Bytecode::Op::SetVariable::InitializationMode::Set;
return declarator.target().visit(
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> const& id) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS/Bytecode: Variable declarators should always prefer lexical env This fixes an issue where object environments (from `with` statement) were bypassed by statements like `var x = 1` (for objects with an `x` property). Fixes 25 tests in test262. :^)
2023-05-13 13:37:12 +02:00
generator.emit<Bytecode::Op::SetVariable>(generator.intern_identifier(id->string()), initialization_mode);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
return {};
},
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<BindingPattern const> const& pattern) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
auto value_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(value_register);
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
return generate_binding_pattern_bytecode(generator, pattern, initialization_mode, value_register, false);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
});
}
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
Bytecode::CodeGenerationErrorOr<void> VariableDeclaration::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add empty bytecode generation for VariableDeclaration These will be partly handled by the relevant ScopeNode due to hoisting, same basic idea as function declarations. VariableDeclaration needs to do some work, but let's stub it out first and start empty.
2021-06-10 00:29:17 +02:00
{
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
for (auto& declarator : m_declarations) {
LibJS/Bytecode: Let `var` without initializer codegen to nothing Otherwise we incorrectly overwrite the binding with `undefined` at the point where the `var` statement is. Fixes 9 test262 tests. :^)
2023-06-17 15:16:30 +02:00
if (declarator->init()) {
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
if (auto const* lhs = declarator->target().get_pointer<NonnullRefPtr<Identifier const>>()) {
TRY(generator.emit_named_evaluation_if_anonymous_function(*declarator->init(), (*lhs)->string()));
} else {
TRY(declarator->init()->generate_bytecode(generator));
}
LibJS/Bytecode: Let `var` without initializer codegen to nothing Otherwise we incorrectly overwrite the binding with `undefined` at the point where the `var` statement is. Fixes 9 test262 tests. :^)
2023-06-17 15:16:30 +02:00
TRY(assign_accumulator_to_variable_declarator(generator, declarator, *this));
} else if (m_declaration_kind != DeclarationKind::Var) {
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
LibJS/Bytecode: Let `var` without initializer codegen to nothing Otherwise we incorrectly overwrite the binding with `undefined` at the point where the `var` statement is. Fixes 9 test262 tests. :^)
2023-06-17 15:16:30 +02:00
TRY(assign_accumulator_to_variable_declarator(generator, declarator, *this));
}
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
}
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
return {};
LibJS: Add empty bytecode generation for VariableDeclaration These will be partly handled by the relevant ScopeNode due to hoisting, same basic idea as function declarations. VariableDeclaration needs to do some work, but let's stub it out first and start empty.
2021-06-10 00:29:17 +02:00
}
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
static Bytecode::CodeGenerationErrorOr<void> get_base_and_value_from_member_expression(Bytecode::Generator& generator, MemberExpression const& member_expression, Bytecode::Register this_reg)
{
// https://tc39.es/ecma262/#sec-super-keyword-runtime-semantics-evaluation
if (is<SuperExpression>(member_expression.object())) {
// 1. Let env be GetThisEnvironment().
// 2. Let actualThis be ? env.GetThisBinding().
generator.emit<Bytecode::Op::ResolveThisBinding>();
generator.emit<Bytecode::Op::Store>(this_reg);
Optional<Bytecode::Register> computed_property_value_register;
if (member_expression.is_computed()) {
// SuperProperty : super [ Expression ]
// 3. Let propertyNameReference be ? Evaluation of Expression.
// 4. Let propertyNameValue be ? GetValue(propertyNameReference).
TRY(member_expression.property().generate_bytecode(generator));
computed_property_value_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(*computed_property_value_register);
}
// 5/7. Return ? MakeSuperPropertyReference(actualThis, propertyKey, strict).
// https://tc39.es/ecma262/#sec-makesuperpropertyreference
// 1. Let env be GetThisEnvironment().
// 2. Assert: env.HasSuperBinding() is true.
// 3. Let baseValue be ? env.GetSuperBase().
generator.emit<Bytecode::Op::ResolveSuperBase>();
// 4. Return the Reference Record { [[Base]]: baseValue, [[ReferencedName]]: propertyKey, [[Strict]]: strict, [[ThisValue]]: actualThis }.
if (computed_property_value_register.has_value()) {
// 5. Let propertyKey be ? ToPropertyKey(propertyNameValue).
// FIXME: This does ToPropertyKey out of order, which is observable by Symbol.toPrimitive!
LibJS/Bytecode: Actually get value from super base for computed property
2023-06-17 18:42:32 +01:00
auto super_base_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(super_base_register);
generator.emit<Bytecode::Op::Load>(*computed_property_value_register);
generator.emit<Bytecode::Op::GetByValue>(super_base_register);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else {
// 3. Let propertyKey be StringValue of IdentifierName.
auto identifier_table_ref = generator.intern_identifier(verify_cast<Identifier>(member_expression.property()).string());
generator.emit<Bytecode::Op::GetById>(identifier_table_ref);
}
} else {
TRY(member_expression.object().generate_bytecode(generator));
generator.emit<Bytecode::Op::Store>(this_reg);
if (member_expression.is_computed()) {
TRY(member_expression.property().generate_bytecode(generator));
generator.emit<Bytecode::Op::GetByValue>(this_reg);
LibJS/Bytecode: Emit GetPrivateById for private member expressions This makes it possible to call private member functions. 347 new passes on test262. :^)
2023-06-23 17:09:32 +02:00
} else if (is<PrivateIdentifier>(member_expression.property())) {
generator.emit<Bytecode::Op::GetPrivateById>(generator.intern_identifier(verify_cast<PrivateIdentifier>(member_expression.property()).string()));
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else {
LibJS/Bytecode: Emit GetPrivateById for private member expressions This makes it possible to call private member functions. 347 new passes on test262. :^)
2023-06-23 17:09:32 +02:00
generator.emit<Bytecode::Op::GetById>(generator.intern_identifier(verify_cast<Identifier>(member_expression.property()).string()));
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}
}
return {};
}
static Bytecode::CodeGenerationErrorOr<void> generate_optional_chain(Bytecode::Generator& generator, OptionalChain const& optional_chain, Bytecode::Register current_value_register, Bytecode::Register current_base_register);
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
Bytecode::CodeGenerationErrorOr<void> CallExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
{
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
auto callee_reg = generator.allocate_register();
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
auto this_reg = generator.allocate_register();
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::Store>(this_reg);
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
if (is<NewExpression>(this)) {
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
TRY(m_callee->generate_bytecode(generator));
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
generator.emit<Bytecode::Op::Store>(callee_reg);
} else if (is<MemberExpression>(*m_callee)) {
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
auto& member_expression = static_cast<MemberExpression const&>(*m_callee);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
TRY(get_base_and_value_from_member_expression(generator, member_expression, this_reg));
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
generator.emit<Bytecode::Op::Store>(callee_reg);
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
} else if (is<OptionalChain>(*m_callee)) {
auto& optional_chain = static_cast<OptionalChain const&>(*m_callee);
TRY(generate_optional_chain(generator, optional_chain, callee_reg, this_reg));
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
} else {
// FIXME: this = global object in sloppy mode.
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
TRY(m_callee->generate_bytecode(generator));
LibJS: Resolve the `this' value in call expression bytecode
2021-06-11 01:36:10 +04:30
generator.emit<Bytecode::Op::Store>(callee_reg);
}
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
TRY(arguments_to_array_for_call(generator, arguments()));
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
Bytecode::Op::Call::CallType call_type;
if (is<NewExpression>(*this)) {
call_type = Bytecode::Op::Call::CallType::Construct;
LibJS/Bytecode: Add support for direct eval() This is implemented as a special mode of the Call opcode that invokes the PerformEval AO (instead of the Call or Construct AO).
2023-06-15 13:16:01 +02:00
} else if (m_callee->is_identifier() && static_cast<Identifier const&>(*m_callee).string() == "eval"sv) {
call_type = Bytecode::Op::Call::CallType::DirectEval;
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
} else {
call_type = Bytecode::Op::Call::CallType::Call;
}
LibJS: Forward a string aproximation of the CallExpression to Call Ops This gives us better debug output when analysing calls to `undefined` and also fixes multiple test-js cases expecting an `(evaluated from $Expression)` in the error message. This also refactors out the generation of that string, to avoid code duplication with the AST interpreter.
2022-10-01 01:36:06 +02:00
Optional<Bytecode::StringTableIndex> expression_string_index;
if (auto expression_string = this->expression_string(); expression_string.has_value())
expression_string_index = generator.intern_string(expression_string.release_value());
generator.emit<Bytecode::Op::Call>(call_type, callee_reg, this_reg, expression_string_index);
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
return {};
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> ReturnStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
{
LibJS: Fix not executing the expression of a return statement
2021-06-08 16:29:21 -07:00
if (m_argument)
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
TRY(m_argument->generate_bytecode(generator));
LibJS/Bytecode: Make `return;` return undefined Previously it would return whatever was in the accumulator.
2022-06-11 23:13:02 +01:00
else
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
if (generator.is_in_generator_or_async_function()) {
generator.perform_needed_unwinds<Bytecode::Op::Yield>();
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
generator.emit<Bytecode::Op::Yield>(nullptr);
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
} else {
generator.perform_needed_unwinds<Bytecode::Op::Return>();
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
generator.emit<Bytecode::Op::Return>();
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
}
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
return {};
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
}
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
Bytecode::CodeGenerationErrorOr<void> YieldExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
{
VERIFY(generator.is_in_generator_function());
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
auto received_completion_register = generator.allocate_register();
auto received_completion_type_register = generator.allocate_register();
auto received_completion_value_register = generator.allocate_register();
auto type_identifier = generator.intern_identifier("type");
auto value_identifier = generator.intern_identifier("value");
auto get_received_completion_type_and_value = [&]() {
// The accumulator is set to an object, for example: { "type": 1 (normal), value: 1337 }
generator.emit<Bytecode::Op::Store>(received_completion_register);
generator.emit<Bytecode::Op::GetById>(type_identifier);
generator.emit<Bytecode::Op::Store>(received_completion_type_register);
generator.emit<Bytecode::Op::Load>(received_completion_register);
generator.emit<Bytecode::Op::GetById>(value_identifier);
generator.emit<Bytecode::Op::Store>(received_completion_value_register);
};
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
if (m_is_yield_from) {
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
// 15.5.5 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-generator-function-definitions-runtime-semantics-evaluation
// FIXME: 1. Let generatorKind be GetGeneratorKind().
// 2. Let exprRef be ? Evaluation of AssignmentExpression.
// 3. Let value be ? GetValue(exprRef).
VERIFY(m_argument);
TRY(m_argument->generate_bytecode(generator));
// 4. Let iteratorRecord be ? GetIterator(value, generatorKind).
// FIXME: Consider generatorKind.
auto iterator_record_register = generator.allocate_register();
generator.emit<Bytecode::Op::GetIterator>();
generator.emit<Bytecode::Op::Store>(iterator_record_register);
// 5. Let iterator be iteratorRecord.[[Iterator]].
auto iterator_register = generator.allocate_register();
auto iterator_identifier = generator.intern_identifier("iterator");
generator.emit<Bytecode::Op::GetById>(iterator_identifier);
generator.emit<Bytecode::Op::Store>(iterator_register);
// Cache iteratorRecord.[[NextMethod]] for use in step 7.a.i.
auto next_method_register = generator.allocate_register();
auto next_method_identifier = generator.intern_identifier("next");
generator.emit<Bytecode::Op::Load>(iterator_record_register);
generator.emit<Bytecode::Op::GetById>(next_method_identifier);
generator.emit<Bytecode::Op::Store>(next_method_register);
// 6. Let received be NormalCompletion(undefined).
// See get_received_completion_type_and_value above.
generator.emit<Bytecode::Op::LoadImmediate>(Value(to_underlying(Completion::Type::Normal)));
generator.emit<Bytecode::Op::Store>(received_completion_type_register);
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::Store>(received_completion_value_register);
// 7. Repeat,
auto& loop_block = generator.make_block();
auto& continuation_block = generator.make_block();
auto& loop_end_block = generator.make_block();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_block });
generator.switch_to_basic_block(loop_block);
// a. If received.[[Type]] is normal, then
auto& type_is_normal_block = generator.make_block();
auto& is_type_throw_block = generator.make_block();
generator.emit<Bytecode::Op::LoadImmediate>(Value(to_underlying(Completion::Type::Normal)));
generator.emit<Bytecode::Op::StrictlyEquals>(received_completion_type_register);
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { type_is_normal_block },
Bytecode::Label { is_type_throw_block });
generator.switch_to_basic_block(type_is_normal_block);
// i. Let innerResult be ? Call(iteratorRecord.[[NextMethod]], iteratorRecord.[[Iterator]], « received.[[Value]] »).
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2, AK::Array { received_completion_value_register, received_completion_value_register });
generator.emit<Bytecode::Op::Call>(Bytecode::Op::Call::CallType::Call, next_method_register, iterator_register);
// FIXME: ii. If generatorKind is async, set innerResult to ? Await(innerResult).
// iii. If innerResult is not an Object, throw a TypeError exception.
generator.emit<Bytecode::Op::ThrowIfNotObject>();
auto inner_result_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(inner_result_register);
// iv. Let done be ? IteratorComplete(innerResult).
generator.emit<Bytecode::Op::IteratorResultDone>();
// v. If done is true, then
auto& type_is_normal_done_block = generator.make_block();
auto& type_is_normal_not_done_block = generator.make_block();
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { type_is_normal_done_block },
Bytecode::Label { type_is_normal_not_done_block });
generator.switch_to_basic_block(type_is_normal_done_block);
// 1. Return ? IteratorValue(innerResult).
generator.emit<Bytecode::Op::Load>(inner_result_register);
generator.emit<Bytecode::Op::IteratorResultValue>();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_end_block });
generator.switch_to_basic_block(type_is_normal_not_done_block);
// FIXME: vi. If generatorKind is async, set received to Completion(AsyncGeneratorYield(? IteratorValue(innerResult))).
// vii. Else, set received to Completion(GeneratorYield(innerResult)).
// FIXME: Else,
generator.emit<Bytecode::Op::Load>(inner_result_register);
// FIXME: Yield currently only accepts a Value, not an object conforming to the IteratorResult interface, so we have to do an observable lookup of `value` here.
generator.emit<Bytecode::Op::IteratorResultValue>();
generator.emit<Bytecode::Op::Yield>(Bytecode::Label { continuation_block });
// b. Else if received.[[Type]] is throw, then
generator.switch_to_basic_block(is_type_throw_block);
auto& type_is_throw_block = generator.make_block();
auto& type_is_return_block = generator.make_block();
generator.emit<Bytecode::Op::LoadImmediate>(Value(to_underlying(Completion::Type::Throw)));
generator.emit<Bytecode::Op::StrictlyEquals>(received_completion_type_register);
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { type_is_throw_block },
Bytecode::Label { type_is_return_block });
generator.switch_to_basic_block(type_is_throw_block);
// i. Let throw be ? GetMethod(iterator, "throw").
auto throw_method_register = generator.allocate_register();
auto throw_identifier = generator.intern_identifier("throw");
generator.emit<Bytecode::Op::Load>(iterator_register);
generator.emit<Bytecode::Op::GetMethod>(throw_identifier);
generator.emit<Bytecode::Op::Store>(throw_method_register);
// ii. If throw is not undefined, then
auto& throw_method_is_defined_block = generator.make_block();
auto& throw_method_is_undefined_block = generator.make_block();
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::StrictlyInequals>(throw_method_register);
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { throw_method_is_defined_block },
Bytecode::Label { throw_method_is_undefined_block });
generator.switch_to_basic_block(throw_method_is_defined_block);
// 1. Let innerResult be ? Call(throw, iterator, « received.[[Value]] »).
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2, AK::Array { received_completion_value_register, received_completion_value_register });
generator.emit<Bytecode::Op::Call>(Bytecode::Op::Call::CallType::Call, throw_method_register, iterator_register);
// FIXME: 2. If generatorKind is async, set innerResult to ? Await(innerResult).
// 3. NOTE: Exceptions from the inner iterator throw method are propagated. Normal completions from an inner throw method are processed similarly to an inner next.
// 4. If innerResult is not an Object, throw a TypeError exception.
generator.emit<Bytecode::Op::ThrowIfNotObject>();
generator.emit<Bytecode::Op::Store>(inner_result_register);
// 5. Let done be ? IteratorComplete(innerResult).
generator.emit<Bytecode::Op::IteratorResultDone>();
// 6. If done is true, then
auto& type_is_throw_done_block = generator.make_block();
auto& type_is_throw_not_done_block = generator.make_block();
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { type_is_throw_done_block },
Bytecode::Label { type_is_throw_not_done_block });
generator.switch_to_basic_block(type_is_throw_done_block);
// a. Return ? IteratorValue(innerResult).
generator.emit<Bytecode::Op::Load>(inner_result_register);
generator.emit<Bytecode::Op::IteratorResultValue>();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_end_block });
generator.switch_to_basic_block(type_is_throw_not_done_block);
// FIXME: 7. If generatorKind is async, set received to Completion(AsyncGeneratorYield(? IteratorValue(innerResult))).
// 8. Else, set received to Completion(GeneratorYield(innerResult)).
// FIXME: Else,
generator.emit<Bytecode::Op::Load>(inner_result_register);
// FIXME: Yield currently only accepts a Value, not an object conforming to the IteratorResult interface, so we have to do an observable lookup of `value` here.
generator.emit<Bytecode::Op::IteratorResultValue>();
generator.emit<Bytecode::Op::Yield>(Bytecode::Label { continuation_block });
generator.switch_to_basic_block(throw_method_is_undefined_block);
// 1. NOTE: If iterator does not have a throw method, this throw is going to terminate the yield* loop. But first we need to give iterator a chance to clean up.
// 2. Let closeCompletion be Completion Record { [[Type]]: normal, [[Value]]: empty, [[Target]]: empty }.
// FIXME: 3. If generatorKind is async, perform ? AsyncIteratorClose(iteratorRecord, closeCompletion).
// 4. Else, perform ? IteratorClose(iteratorRecord, closeCompletion).
// FIXME: Else,
generator.emit<Bytecode::Op::Load>(iterator_record_register);
generator.emit<Bytecode::Op::IteratorClose>(Completion::Type::Normal, Optional<Value> {});
// 5. NOTE: The next step throws a TypeError to indicate that there was a yield* protocol violation: iterator does not have a throw method.
// 6. Throw a TypeError exception.
generator.emit<Bytecode::Op::NewTypeError>(generator.intern_string(ErrorType::YieldFromIteratorMissingThrowMethod.message()));
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
generator.emit<Bytecode::Op::Throw>();
// c. Else,
// i. Assert: received.[[Type]] is return.
generator.switch_to_basic_block(type_is_return_block);
// ii. Let return be ? GetMethod(iterator, "return").
auto return_method_register = generator.allocate_register();
auto return_identifier = generator.intern_identifier("return");
generator.emit<Bytecode::Op::Load>(iterator_register);
generator.emit<Bytecode::Op::GetMethod>(return_identifier);
generator.emit<Bytecode::Op::Store>(return_method_register);
// iii. If return is undefined, then
auto& return_is_undefined_block = generator.make_block();
auto& return_is_defined_block = generator.make_block();
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::StrictlyEquals>(return_method_register);
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { return_is_undefined_block },
Bytecode::Label { return_is_defined_block });
generator.switch_to_basic_block(return_is_undefined_block);
// FIXME: 1. If generatorKind is async, set received.[[Value]] to ? Await(received.[[Value]]).
// 2. Return ? received.
// NOTE: This will always be a return completion.
generator.emit<Bytecode::Op::Load>(received_completion_value_register);
generator.perform_needed_unwinds<Bytecode::Op::Yield>();
generator.emit<Bytecode::Op::Yield>(nullptr);
generator.switch_to_basic_block(return_is_defined_block);
// iv. Let innerReturnResult be ? Call(return, iterator, « received.[[Value]] »).
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2, AK::Array { received_completion_value_register, received_completion_value_register });
generator.emit<Bytecode::Op::Call>(Bytecode::Op::Call::CallType::Call, return_method_register, iterator_register);
// FIXME: v. If generatorKind is async, set innerReturnResult to ? Await(innerReturnResult).
// vi. If innerReturnResult is not an Object, throw a TypeError exception.
generator.emit<Bytecode::Op::ThrowIfNotObject>();
auto inner_return_result_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(inner_return_result_register);
// vii. Let done be ? IteratorComplete(innerReturnResult).
generator.emit<Bytecode::Op::IteratorResultDone>();
// viii. If done is true, then
auto& type_is_return_done_block = generator.make_block();
auto& type_is_return_not_done_block = generator.make_block();
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { type_is_return_done_block },
Bytecode::Label { type_is_return_not_done_block });
generator.switch_to_basic_block(type_is_return_done_block);
// 1. Let value be ? IteratorValue(innerReturnResult).
generator.emit<Bytecode::Op::Load>(inner_result_register);
generator.emit<Bytecode::Op::IteratorResultValue>();
// 2. Return Completion Record { [[Type]]: return, [[Value]]: value, [[Target]]: empty }.
generator.perform_needed_unwinds<Bytecode::Op::Yield>();
generator.emit<Bytecode::Op::Yield>(nullptr);
generator.switch_to_basic_block(type_is_return_not_done_block);
// FIXME: ix. If generatorKind is async, set received to Completion(AsyncGeneratorYield(? IteratorValue(innerReturnResult))).
// x. Else, set received to Completion(GeneratorYield(innerReturnResult)).
// FIXME: Else,
generator.emit<Bytecode::Op::Load>(inner_return_result_register);
// FIXME: Yield currently only accepts a Value, not an object conforming to the IteratorResult interface, so we have to do an observable lookup of `value` here.
generator.emit<Bytecode::Op::IteratorResultValue>();
generator.emit<Bytecode::Op::Yield>(Bytecode::Label { continuation_block });
generator.switch_to_basic_block(continuation_block);
get_received_completion_type_and_value();
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_block });
generator.switch_to_basic_block(loop_end_block);
return {};
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
}
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
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
if (m_argument)
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
TRY(m_argument->generate_bytecode(generator));
LibJS/Bytecode: Make `yield` by itself yield undefined
2022-11-25 23:14:27 +00:00
else
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
auto& continuation_block = generator.make_block();
generator.emit<Bytecode::Op::Yield>(Bytecode::Label { continuation_block });
generator.switch_to_basic_block(continuation_block);
LibJS: Perform received abrupt generator completions in the generator Previously, throw and return completions would not be executed inside the generator. This is incorrect, as throw and return need to perform unwinds which can potentially execute more code inside the generator, such as finally blocks. This is done by also passing the completion type alongside the passed in value. The continuation block will immediately extract and type and value and perform the appropriate operation for the given type. For normal completions, this is continuing as normal. For throw completions, it will perform `throw <value>`. For return completions, it will perform `return <value>`, which is a `Yield return` in this case due to being inside a generator. This also refactors GeneratorObject to properly send across the completion type and value to the generator inside of trying to operate on the completions itself. This is a prerequisite for yield*, as it performs special iterator operations when receiving a throw/return completion and does not complete the generator like the regular yield would. There's still more work to be done to make GeneratorObject::execute be closer to the spec. It's mostly a restructuring of the existing GeneratorObject::next_impl.
2022-11-25 23:14:08 +00:00
get_received_completion_type_and_value();
auto& normal_completion_continuation_block = generator.make_block();
auto& throw_completion_continuation_block = generator.make_block();
generator.emit<Bytecode::Op::LoadImmediate>(Value(to_underlying(Completion::Type::Normal)));
generator.emit<Bytecode::Op::StrictlyEquals>(received_completion_type_register);
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { normal_completion_continuation_block },
Bytecode::Label { throw_completion_continuation_block });
auto& throw_value_block = generator.make_block();
auto& return_value_block = generator.make_block();
generator.switch_to_basic_block(throw_completion_continuation_block);
generator.emit<Bytecode::Op::LoadImmediate>(Value(to_underlying(Completion::Type::Throw)));
generator.emit<Bytecode::Op::StrictlyEquals>(received_completion_type_register);
// If type is not equal to "throw" or "normal", assume it's "return".
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { throw_value_block },
Bytecode::Label { return_value_block });
generator.switch_to_basic_block(throw_value_block);
generator.emit<Bytecode::Op::Load>(received_completion_value_register);
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
generator.emit<Bytecode::Op::Throw>();
generator.switch_to_basic_block(return_value_block);
generator.emit<Bytecode::Op::Load>(received_completion_value_register);
generator.perform_needed_unwinds<Bytecode::Op::Yield>();
generator.emit<Bytecode::Op::Yield>(nullptr);
generator.switch_to_basic_block(normal_completion_continuation_block);
generator.emit<Bytecode::Op::Load>(received_completion_value_register);
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
return {};
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> IfStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add basic "if" statement support to the bytecode VM :^) This also required making Bytecode::Op::Jump support lazy linking to a target label. I left a FIXME here about having the "if" statement return the result value from the taken branch statement. That's what the AST interpreter does but I'm not sure if it's actually required.
2021-06-06 13:26:50 +02:00
{
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// test
// jump if_true (true) true (false) false
// true
// jump always (true) end
// false
// jump always (true) end
// end
auto& true_block = generator.make_block();
auto& false_block = generator.make_block();
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
TRY(m_predicate->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { true_block },
Bytecode::Label { false_block });
Bytecode::Op::Jump* true_block_jump { nullptr };
LibJS: Add basic "if" statement support to the bytecode VM :^) This also required making Bytecode::Op::Jump support lazy linking to a target label. I left a FIXME here about having the "if" statement return the result value from the taken branch statement. That's what the AST interpreter does but I'm not sure if it's actually required.
2021-06-06 13:26:50 +02:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(true_block);
LibJS: Let if yield undefined for branches that don't yield a value According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-20 12:38:59 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
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
TRY(m_consequent->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
if (!generator.is_current_block_terminated())
true_block_jump = &generator.emit<Bytecode::Op::Jump>();
generator.switch_to_basic_block(false_block);
LibJS: Let if yield undefined for branches that don't yield a value According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-20 12:38:59 +02:00
auto& end_block = generator.make_block();
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Let if yield undefined for branches that don't yield a value According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-20 12:38:59 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
if (m_alternate)
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
TRY(m_alternate->generate_bytecode(generator));
LibJS: Let if yield undefined for branches that don't yield a value According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-20 12:38:59 +02:00
if (!generator.is_current_block_terminated())
generator.emit<Bytecode::Op::Jump>().set_targets(Bytecode::Label { end_block }, {});
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Let if yield undefined for branches that don't yield a value According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-20 12:38:59 +02:00
if (true_block_jump)
true_block_jump->set_targets(Bytecode::Label { end_block }, {});
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
LibJS: Let if yield undefined for branches that don't yield a value According to 13.6.7 the return value for if expressions should be undefined when the branch statements don't yield a value.
2021-06-20 12:38:59 +02:00
generator.switch_to_basic_block(end_block);
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
return {};
LibJS: Add basic "if" statement support to the bytecode VM :^) This also required making Bytecode::Op::Jump support lazy linking to a target label. I left a FIXME here about having the "if" statement return the result value from the taken branch statement. That's what the AST interpreter does but I'm not sure if it's actually required.
2021-06-06 13:26:50 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> ContinueStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
{
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
// FIXME: Handle finally blocks in a graceful manner
// We need to execute the finally block, but tell it to resume
// execution at the designated block
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
if (m_target_label.is_null()) {
LibJS: Generate unwind chains for continue in Bytecode This works similar to `break` The `try-finally-continue` still do not pass with this, likely because of binding issues.
2022-11-25 16:35:39 +01:00
generator.generate_continue();
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return {};
}
LibJS: Generate unwind chains for continue in Bytecode This works similar to `break` The `try-finally-continue` still do not pass with this, likely because of binding issues.
2022-11-25 16:35:39 +01:00
generator.generate_continue(m_target_label);
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
return {};
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> DebuggerStatement::generate_bytecode(Bytecode::Generator&) const
LibJS: Add bytecode generation for DebuggerStatement No-op. :^)
2021-06-07 20:05:50 +01:00
{
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
return {};
LibJS: Add bytecode generation for DebuggerStatement No-op. :^)
2021-06-07 20:05:50 +01:00
}
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
Bytecode::CodeGenerationErrorOr<void> ConditionalExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
{
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
// test
// jump if_true (true) true (false) false
// true
// jump always (true) end
// false
// jump always (true) end
// end
auto& true_block = generator.make_block();
auto& false_block = generator.make_block();
auto& end_block = generator.make_block();
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
TRY(m_test->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::JumpConditional>().set_targets(
Bytecode::Label { true_block },
Bytecode::Label { false_block });
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(true_block);
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
TRY(m_consequent->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { end_block },
{});
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(false_block);
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
TRY(m_alternate->generate_bytecode(generator));
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.emit<Bytecode::Op::Jump>().set_targets(
Bytecode::Label { end_block },
{});
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
generator.switch_to_basic_block(end_block);
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
return {};
LibJS: Add conditional expression bytecode generation Or, by its more common name, the ternary operator :^)
2021-06-08 04:54:34 +01:00
}
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
Bytecode::CodeGenerationErrorOr<void> SequenceExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Add sequence expression bytecode generation
2021-06-08 10:13:37 +01:00
{
for (auto& expression : m_expressions)
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
TRY(expression->generate_bytecode(generator));
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
return {};
LibJS: Add sequence expression bytecode generation
2021-06-08 10:13:37 +01:00
}
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
Bytecode::CodeGenerationErrorOr<void> TemplateLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
{
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
auto string_reg = generator.allocate_register();
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
for (size_t i = 0; i < m_expressions.size(); i++) {
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
TRY(m_expressions[i]->generate_bytecode(generator));
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
if (i == 0) {
generator.emit<Bytecode::Op::Store>(string_reg);
} else {
generator.emit<Bytecode::Op::ConcatString>(string_reg);
}
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
}
LibJS: Fix the return value for TemplateLiteral This ensures that the bytecode generated for TemplateLiterals returns the correct value.
2021-06-09 21:11:04 +02:00
generator.emit<Bytecode::Op::Load>(string_reg);
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
return {};
LibJS: Generate bytecode for template literals
2021-06-08 19:14:01 +02:00
}
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
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
Bytecode::CodeGenerationErrorOr<void> TaggedTemplateLiteral::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
{
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
TRY(m_tag->generate_bytecode(generator));
LibJS: Fix evaluation order for tagged template literals This ensures that the tag function is evaluated first.
2021-06-09 22:07:18 +02:00
auto tag_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(tag_reg);
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 23:39:43 +02:00
// FIXME: We only need to record the first and last register,
// due to packing everything in an array, same goes for argument_regs
LibJS: Replace invalid escapes in TemplateLiterals with undefined in BC Also adds a big FIXME, to outline what is still wrong
2023-06-25 12:31:49 +02:00
// FIXME: Follow
// 13.2.8.3 GetTemplateObject ( templateLiteral ), https://tc39.es/ecma262/#sec-gettemplateobject
// more closely, namely:
// * cache this somehow
// * add a raw object accessor
// * freeze array and raw member
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
Vector<Bytecode::Register> string_regs;
auto& expressions = m_template_literal->expressions();
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
for (size_t i = 0; i < expressions.size(); ++i) {
if (i % 2 != 0)
continue;
string_regs.append(generator.allocate_register());
}
size_t reg_index = 0;
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
for (size_t i = 0; i < expressions.size(); ++i) {
if (i % 2 != 0)
continue;
LibJS: Replace invalid escapes in TemplateLiterals with undefined in BC Also adds a big FIXME, to outline what is still wrong
2023-06-25 12:31:49 +02:00
// NOTE: If the string contains invalid escapes we get a null expression here,
// which we then convert to the expected `undefined` TV. See
// 12.9.6.1 Static Semantics: TV, https://tc39.es/ecma262/#sec-static-semantics-tv
if (is<NullLiteral>(expressions[i]))
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
else
TRY(expressions[i]->generate_bytecode(generator));
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
auto string_reg = string_regs[reg_index++];
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
generator.emit<Bytecode::Op::Store>(string_reg);
}
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
if (string_regs.is_empty()) {
generator.emit<Bytecode::Op::NewArray>();
} else {
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2u, AK::Array { string_regs.first(), string_regs.last() });
}
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
auto strings_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(strings_reg);
Vector<Bytecode::Register> argument_regs;
argument_regs.append(strings_reg);
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 23:39:43 +02:00
for (size_t i = 1; i < expressions.size(); i += 2)
argument_regs.append(generator.allocate_register());
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 23:39:43 +02:00
for (size_t i = 1; i < expressions.size(); i += 2) {
auto string_reg = argument_regs[1 + i / 2];
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
TRY(expressions[i]->generate_bytecode(generator));
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
generator.emit<Bytecode::Op::Store>(string_reg);
}
Vector<Bytecode::Register> raw_string_regs;
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
for ([[maybe_unused]] auto& raw_string : m_template_literal->raw_strings())
string_regs.append(generator.allocate_register());
reg_index = 0;
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
for (auto& raw_string : m_template_literal->raw_strings()) {
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
TRY(raw_string->generate_bytecode(generator));
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
auto raw_string_reg = string_regs[reg_index++];
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
generator.emit<Bytecode::Op::Store>(raw_string_reg);
raw_string_regs.append(raw_string_reg);
}
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
if (raw_string_regs.is_empty()) {
generator.emit<Bytecode::Op::NewArray>();
} else {
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2u, AK::Array { raw_string_regs.first(), raw_string_regs.last() });
}
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
auto raw_strings_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(raw_strings_reg);
LibJS/Bytecode: Add "raw" property correctly for tagged template literal We were adding it to the wrong object before. :^)
2023-06-15 16:36:14 +02:00
generator.emit<Bytecode::Op::PutById>(strings_reg, generator.intern_identifier("raw"));
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
auto this_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(this_reg);
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 23:39:43 +02:00
if (!argument_regs.is_empty())
generator.emit_with_extra_register_slots<Bytecode::Op::NewArray>(2, AK::Array { argument_regs.first(), argument_regs.last() });
else
generator.emit<Bytecode::Op::NewArray>();
generator.emit<Bytecode::Op::Call>(Bytecode::Op::Call::CallType::Call, tag_reg, this_reg);
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
return {};
LibJS: Generate bytecode for tagged template literals
2021-06-09 21:02:24 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> UpdateExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
{
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
TRY(generator.emit_load_from_reference(*m_argument));
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS: Generate bytecode for UpdateExpression with MemberExpression arg
2021-10-25 15:17:41 +02:00
Optional<Bytecode::Register> previous_value_for_postfix_reg;
if (!m_prefixed) {
previous_value_for_postfix_reg = generator.allocate_register();
LibJS/Bytecode: Perform ToNumeric on accumulator before postfix inc/dec This ensures we get the expected behavior of code like: let a = [] let b = a++ (Where b should be 0, not [], because JavaScript.)
2023-06-16 10:51:40 +02:00
generator.emit<Bytecode::Op::ToNumeric>();
LibJS: Generate bytecode for UpdateExpression with MemberExpression arg
2021-10-25 15:17:41 +02:00
generator.emit<Bytecode::Op::Store>(*previous_value_for_postfix_reg);
}
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS: Generate bytecode for UpdateExpression with MemberExpression arg
2021-10-25 15:17:41 +02:00
if (m_op == UpdateOp::Increment)
generator.emit<Bytecode::Op::Increment>();
else
generator.emit<Bytecode::Op::Decrement>();
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
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
TRY(generator.emit_store_to_reference(*m_argument));
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
LibJS: Generate bytecode for UpdateExpression with MemberExpression arg
2021-10-25 15:17:41 +02:00
if (!m_prefixed)
generator.emit<Bytecode::Op::Load>(*previous_value_for_postfix_reg);
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
return {};
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> ThrowStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
{
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
TRY(m_argument->generate_bytecode(generator));
LibJS/Bytecode: Unwind to closest unwind boundary on Throw This will leave any lexical/variable environments on the way to the closest unwind context boundary. This will not leave the closest unwind context, as we still need the unwind context to perform the Throw instruction correctly.
2022-03-14 02:26:39 +00:00
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
generator.emit<Bytecode::Op::Throw>();
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
return {};
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> BreakStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
{
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
// FIXME: Handle finally blocks in a graceful manner
// We need to execute the finally block, but tell it to resume
// execution at the designated block
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
if (m_target_label.is_null()) {
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
generator.generate_break();
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return {};
}
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
generator.generate_break(m_target_label);
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
return {};
LibJS: Implement bytecode generation for BreakStatement
2021-06-10 20:28:43 +08:00
}
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
Bytecode::CodeGenerationErrorOr<void> TryStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
auto& saved_block = generator.current_block();
Optional<Bytecode::Label> handler_target;
Optional<Bytecode::Label> finalizer_target;
Bytecode::BasicBlock* next_block { nullptr };
if (m_finalizer) {
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
// FIXME: See notes in Op.h->ScheduleJump
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
auto& finalizer_block = generator.make_block();
generator.switch_to_basic_block(finalizer_block);
LibJS: Leave unwind contexts on enter of finally blocks in Bytecode Before we were doing so while exiting the catch-block, but not when exiting the try-block. This now centralizes the responsibility to exit the unwind context to the finalizer, ignoring return/break/continue. This makes it easier to handle the return case in a future commit.
2022-11-13 15:58:36 +01:00
generator.emit<Bytecode::Op::LeaveUnwindContext>();
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
TRY(m_finalizer->generate_bytecode(generator));
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
if (!generator.is_current_block_terminated()) {
next_block = &generator.make_block();
auto next_target = Bytecode::Label { *next_block };
generator.emit<Bytecode::Op::ContinuePendingUnwind>(next_target);
}
finalizer_target = Bytecode::Label { finalizer_block };
}
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (m_finalizer)
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
if (m_handler) {
auto& handler_block = generator.make_block();
generator.switch_to_basic_block(handler_block);
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (!m_finalizer)
generator.emit<Bytecode::Op::LeaveUnwindContext>();
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
generator.begin_variable_scope();
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
TRY(m_handler->parameter().visit(
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& parameter) -> Bytecode::CodeGenerationErrorOr<void> {
LibJS: Fix bogus bytecode codegen for "catch" parameters Add a missing '!' so that catch clauses with a named parameter actually generate a SetVariable opcode.
2021-10-24 22:46:54 +02:00
if (!parameter.is_empty()) {
LibJS/Bytecode: Setup declarative environment for catch with variable
2022-03-14 02:38:13 +00:00
auto parameter_identifier = generator.intern_identifier(parameter);
generator.emit<Bytecode::Op::CreateVariable>(parameter_identifier, Bytecode::Op::EnvironmentMode::Lexical, false);
generator.emit<Bytecode::Op::SetVariable>(parameter_identifier, Bytecode::Op::SetVariable::InitializationMode::Initialize);
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
}
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
return {};
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
},
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
[&](NonnullRefPtr<BindingPattern const> const& binding_pattern) -> Bytecode::CodeGenerationErrorOr<void> {
auto value_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(value_register);
TRY(generate_binding_pattern_bytecode(generator, *binding_pattern, Bytecode::Op::SetVariable::InitializationMode::Initialize, value_register, true));
return {};
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
}));
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
LibJS/Bytecode: Set accumulator to undefined at start of catch blocks Otherwise we leak the error value through to the result.
2023-06-25 20:52:06 +01:00
// Set accumulator to undefined, otherwise we leak the error object through the accumulator.
// For example: `try { BigInt.call() } catch {}` would result in the error object. Note that
// the exception _is_ caught here, it just leaks the error object through to the result.
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
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
TRY(m_handler->body().generate_bytecode(generator));
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
handler_target = Bytecode::Label { handler_block };
LibJS/Bytecode: Setup declarative environment for catch with variable
2022-03-14 02:38:13 +00:00
generator.end_variable_scope();
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
if (!generator.is_current_block_terminated()) {
if (m_finalizer) {
generator.emit<Bytecode::Op::Jump>(finalizer_target);
} else {
VERIFY(!next_block);
next_block = &generator.make_block();
auto next_target = Bytecode::Label { *next_block };
generator.emit<Bytecode::Op::Jump>(next_target);
}
}
}
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (m_finalizer)
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
auto& target_block = generator.make_block();
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
generator.switch_to_basic_block(saved_block);
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
generator.emit<Bytecode::Op::EnterUnwindContext>(Bytecode::Label { target_block }, handler_target, finalizer_target);
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::Unwind);
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (m_finalizer)
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
generator.switch_to_basic_block(target_block);
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
TRY(m_block->generate_bytecode(generator));
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
if (!generator.is_current_block_terminated()) {
if (m_finalizer) {
generator.emit<Bytecode::Op::Jump>(finalizer_target);
} else {
LibJS/Bytecode: Fix bogus program termination after `try` with `catch` For `try` statements with a `catch` clause, we were generating *two* "next" blocks. This meant that not throwing an exception would cause execution to stop. Fix this by using the "next" block pointer for the try "entry" and "handler" blocks.
2023-05-13 18:50:27 +02:00
if (!next_block)
next_block = &generator.make_block();
LibJS: Remove FinishUnwind instruction This is essentially a LeaveUnwind+Jump, so lets just do that, that will make it easier to optimize it, or see unwind state transitions
2022-11-13 18:38:15 +01:00
generator.emit<Bytecode::Op::LeaveUnwindContext>();
LibJS/Bytecode: Fix bogus program termination after `try` with `catch` For `try` statements with a `catch` clause, we were generating *two* "next" blocks. This meant that not throwing an exception would cause execution to stop. Fix this by using the "next" block pointer for the try "entry" and "handler" blocks.
2023-05-13 18:50:27 +02:00
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { *next_block });
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
}
}
LibJS: Intercept returns through finally blocks in Bytecode This is still not perfect, as we now actually crash in the `try-finally-continue` tests, while we now succeed all `try-catch-finally-*` tests. Note that we do not yet go through the finally block when exiting the unwind context through a break or continue.
2022-11-13 20:56:53 +01:00
if (m_finalizer)
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::ReturnToFinally);
LibJS: Leave the unwind context on break/continue/return in bytecode Otherwise we'd keep the old unwind context, and end up never invoking the other handlers up the stack.
2022-03-13 11:51:02 +03:30
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::Unwind);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
generator.switch_to_basic_block(next_block ? *next_block : saved_block);
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
return {};
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
}
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
Bytecode::CodeGenerationErrorOr<void> SwitchStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
return generate_labelled_evaluation(generator, {});
}
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
Bytecode::CodeGenerationErrorOr<void> SwitchStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
{
auto discriminant_reg = generator.allocate_register();
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
TRY(m_discriminant->generate_bytecode(generator));
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
generator.emit<Bytecode::Op::Store>(discriminant_reg);
Vector<Bytecode::BasicBlock&> case_blocks;
Bytecode::BasicBlock* default_block { nullptr };
Bytecode::BasicBlock* next_test_block = &generator.make_block();
LibJS: Actually generate a lexical env for SwitchStatement in BC We had code for this in ScopeNode, but that function was never called for a SwitchStatement. This fixes a bunch of scoping tests for switch.
2022-04-03 02:13:51 +04:30
LibJS/Bytecode: Actually exit `switch` statement's lexical scope 95 new passes on test262. :^)
2023-06-25 07:37:24 +02:00
auto has_lexical_declarations = this->has_lexical_declarations();
if (has_lexical_declarations)
generator.block_declaration_instantiation(*this);
LibJS: Actually generate a lexical env for SwitchStatement in BC We had code for this in ScopeNode, but that function was never called for a SwitchStatement. This fixes a bunch of scoping tests for switch.
2022-04-03 02:13:51 +04:30
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
generator.emit<Bytecode::Op::Jump>().set_targets(Bytecode::Label { *next_test_block }, {});
LibJS: Actually generate a lexical env for SwitchStatement in BC We had code for this in ScopeNode, but that function was never called for a SwitchStatement. This fixes a bunch of scoping tests for switch.
2022-04-03 02:13:51 +04:30
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
for (auto& switch_case : m_cases) {
auto& case_block = generator.make_block();
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
if (switch_case->test()) {
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
generator.switch_to_basic_block(*next_test_block);
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
TRY(switch_case->test()->generate_bytecode(generator));
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
generator.emit<Bytecode::Op::StrictlyEquals>(discriminant_reg);
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
next_test_block = &generator.make_block();
generator.emit<Bytecode::Op::JumpConditional>().set_targets(Bytecode::Label { case_block }, Bytecode::Label { *next_test_block });
} else {
default_block = &case_block;
}
case_blocks.append(case_block);
}
generator.switch_to_basic_block(*next_test_block);
auto& end_block = generator.make_block();
if (default_block != nullptr) {
generator.emit<Bytecode::Op::Jump>().set_targets(Bytecode::Label { *default_block }, {});
} else {
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::Jump>().set_targets(Bytecode::Label { end_block }, {});
}
auto current_block = case_blocks.begin();
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_breakable_scope(Bytecode::Label { end_block }, label_set);
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
for (auto& switch_case : m_cases) {
generator.switch_to_basic_block(*current_block);
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
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
for (auto& statement : switch_case->children()) {
TRY(statement->generate_bytecode(generator));
LibJS: Stop generating switch case statements on block termination After we terminate a block (e.g. break, continue), we cannot generate anymore bytecode for the block. This caused us to crash with this example code: ``` a = 0; switch (a) { case 0: break; console.log("hello world"); } ``` Anything after a block terminating instruction is considered unreachable code, so we can safely skip any statements after it.
2022-03-15 01:43:44 +00:00
if (generator.is_current_block_terminated())
break;
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
}
if (!generator.is_current_block_terminated()) {
auto next_block = current_block;
next_block++;
if (next_block.is_end()) {
generator.emit<Bytecode::Op::Jump>().set_targets(Bytecode::Label { end_block }, {});
} else {
generator.emit<Bytecode::Op::Jump>().set_targets(Bytecode::Label { *next_block }, {});
}
}
current_block++;
}
generator.end_breakable_scope();
generator.switch_to_basic_block(end_block);
LibJS/Bytecode: Actually exit `switch` statement's lexical scope 95 new passes on test262. :^)
2023-06-25 07:37:24 +02:00
if (has_lexical_declarations)
generator.end_variable_scope();
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
return {};
LibJS: Implement bytecode generation for switch
2021-06-11 00:36:16 +02:00
}
LibJS: Implement ClassExpression::generate_bytecode() ...and use that in ClassDeclaration::generate_bytecode().
2022-02-12 19:55:40 +03:30
Bytecode::CodeGenerationErrorOr<void> ClassDeclaration::generate_bytecode(Bytecode::Generator& generator) const
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 15:42:13 -03:00
{
LibJS: Implement ClassExpression::generate_bytecode() ...and use that in ClassDeclaration::generate_bytecode().
2022-02-12 19:55:40 +03:30
TRY(m_class_expression->generate_bytecode(generator));
generator.emit<Bytecode::Op::SetVariable>(generator.intern_identifier(m_class_expression.ptr()->name()), Bytecode::Op::SetVariable::InitializationMode::Initialize);
return {};
}
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
Bytecode::CodeGenerationErrorOr<void> ClassExpression::generate_bytecode_with_lhs_name(Bytecode::Generator& generator, Optional<DeprecatedFlyString const&> lhs_name) const
LibJS: Implement ClassExpression::generate_bytecode() ...and use that in ClassDeclaration::generate_bytecode().
2022-02-12 19:55:40 +03:30
{
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
generator.emit<Bytecode::Op::NewClass>(*this, lhs_name);
LibJS: Implement ClassExpression::generate_bytecode() ...and use that in ClassDeclaration::generate_bytecode().
2022-02-12 19:55:40 +03:30
return {};
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 15:42:13 -03:00
}
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
Bytecode::CodeGenerationErrorOr<void> ClassExpression::generate_bytecode(Bytecode::Generator& generator) const
{
return generate_bytecode_with_lhs_name(generator, {});
}
LibJS: Allow SpreadExpressions to generate bytecode
2022-09-02 23:39:04 +02:00
Bytecode::CodeGenerationErrorOr<void> SpreadExpression::generate_bytecode(Bytecode::Generator& generator) const
{
// NOTE: All users of this should handle the behaviour of this on their own,
// assuming it returns an Array-like object
return m_target->generate_bytecode(generator);
}
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
Bytecode::CodeGenerationErrorOr<void> ThisExpression::generate_bytecode(Bytecode::Generator& generator) const
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 14:43:00 +02:00
{
generator.emit<Bytecode::Op::ResolveThisBinding>();
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
return {};
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 14:43:00 +02:00
}
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
static void generate_await(Bytecode::Generator& generator)
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
{
VERIFY(generator.is_in_async_function());
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
// Transform `await expr` to `yield expr`, see AsyncFunctionDriverWrapper
// For that we just need to copy most of the code from YieldExpression
auto received_completion_register = generator.allocate_register();
auto received_completion_type_register = generator.allocate_register();
auto received_completion_value_register = generator.allocate_register();
auto type_identifier = generator.intern_identifier("type");
auto value_identifier = generator.intern_identifier("value");
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
auto& continuation_block = generator.make_block();
generator.emit<Bytecode::Op::Yield>(Bytecode::Label { continuation_block });
generator.switch_to_basic_block(continuation_block);
LibJS: Align codegen AwaitExpressions to YieldExpressions We use generators in bytecode to approximate async functions, but the code generated by AwaitExpressions did not have the value processing paths that Yield requires, eg the `generator.throw()` path, which is used by AsyncFunctionDriverWrapper to signal Promise rejections.
2022-12-25 17:15:29 +01:00
// The accumulator is set to an object, for example: { "type": 1 (normal), value: 1337 }
generator.emit<Bytecode::Op::Store>(received_completion_register);
generator.emit<Bytecode::Op::GetById>(type_identifier);
generator.emit<Bytecode::Op::Store>(received_completion_type_register);
generator.emit<Bytecode::Op::Load>(received_completion_register);
generator.emit<Bytecode::Op::GetById>(value_identifier);
generator.emit<Bytecode::Op::Store>(received_completion_value_register);
auto& normal_completion_continuation_block = generator.make_block();
auto& throw_value_block = generator.make_block();
generator.emit<Bytecode::Op::LoadImmediate>(Value(to_underlying(Completion::Type::Normal)));
generator.emit<Bytecode::Op::StrictlyEquals>(received_completion_type_register);
generator.emit<Bytecode::Op::JumpConditional>(
Bytecode::Label { normal_completion_continuation_block },
Bytecode::Label { throw_value_block });
// Simplification: The only abrupt completion we receive from AsyncFunctionDriverWrapper is Type::Throw
// So we do not need to account for the Type::Return path
generator.switch_to_basic_block(throw_value_block);
generator.emit<Bytecode::Op::Load>(received_completion_value_register);
generator.perform_needed_unwinds<Bytecode::Op::Throw>();
generator.emit<Bytecode::Op::Throw>();
generator.switch_to_basic_block(normal_completion_continuation_block);
generator.emit<Bytecode::Op::Load>(received_completion_value_register);
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
}
Bytecode::CodeGenerationErrorOr<void> AwaitExpression::generate_bytecode(Bytecode::Generator& generator) const
{
TRY(m_argument->generate_bytecode(generator));
generate_await(generator);
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
return {};
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
}
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
Bytecode::CodeGenerationErrorOr<void> WithStatement::generate_bytecode(Bytecode::Generator& generator) const
{
TRY(m_object->generate_bytecode(generator));
generator.emit<Bytecode::Op::EnterObjectEnvironment>();
LibJS/Bytecode: Setup lexical environment boundary for with statements This allows us to properly unwind the object environment for `with` on a block terminating instruction, e.g. an unconditional throw.
2022-03-14 02:35:45 +00:00
// EnterObjectEnvironment sets the running execution context's lexical_environment to a new Object Environment.
generator.start_boundary(Bytecode::Generator::BlockBoundaryType::LeaveLexicalEnvironment);
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
TRY(m_body->generate_bytecode(generator));
LibJS/Bytecode: Setup lexical environment boundary for with statements This allows us to properly unwind the object environment for `with` on a block terminating instruction, e.g. an unconditional throw.
2022-03-14 02:35:45 +00:00
generator.end_boundary(Bytecode::Generator::BlockBoundaryType::LeaveLexicalEnvironment);
if (!generator.is_current_block_terminated())
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
generator.emit<Bytecode::Op::LeaveLexicalEnvironment>();
LibJS/Bytecode: Setup lexical environment boundary for with statements This allows us to properly unwind the object environment for `with` on a block terminating instruction, e.g. an unconditional throw.
2022-03-14 02:35:45 +00:00
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
return {};
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
enum class LHSKind {
Assignment,
VarBinding,
LexicalBinding,
};
enum class IterationKind {
Enumerate,
Iterate,
AsyncIterate,
};
// 14.7.5.6 ForIn/OfHeadEvaluation ( uninitializedBoundNames, expr, iterationKind ), https://tc39.es/ecma262/#sec-runtime-semantics-forinofheadevaluation
struct ForInOfHeadEvaluationResult {
bool is_destructuring { false };
LHSKind lhs_kind { LHSKind::Assignment };
};
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
static Bytecode::CodeGenerationErrorOr<ForInOfHeadEvaluationResult> for_in_of_head_evaluation(Bytecode::Generator& generator, IterationKind iteration_kind, Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> const& lhs, NonnullRefPtr<ASTNode const> const& rhs)
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
ForInOfHeadEvaluationResult result {};
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
bool entered_lexical_scope = 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
if (auto* ast_ptr = lhs.get_pointer<NonnullRefPtr<ASTNode const>>(); ast_ptr && is<VariableDeclaration>(**ast_ptr)) {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// Runtime Semantics: ForInOfLoopEvaluation, for any of:
// ForInOfStatement : for ( var ForBinding in Expression ) Statement
// ForInOfStatement : for ( ForDeclaration in Expression ) Statement
// ForInOfStatement : for ( var ForBinding of AssignmentExpression ) Statement
// ForInOfStatement : for ( ForDeclaration of AssignmentExpression ) Statement
auto& variable_declaration = static_cast<VariableDeclaration const&>(**ast_ptr);
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
result.is_destructuring = variable_declaration.declarations().first()->target().has<NonnullRefPtr<BindingPattern const>>();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
result.lhs_kind = variable_declaration.is_lexical_declaration() ? LHSKind::LexicalBinding : LHSKind::VarBinding;
// 1. Let oldEnv be the running execution context's LexicalEnvironment.
// NOTE: 'uninitializedBoundNames' refers to the lexical bindings (i.e. Const/Let) present in the second and last form.
// 2. If uninitializedBoundNames is not an empty List, then
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
if (variable_declaration.declaration_kind() != DeclarationKind::Var) {
entered_lexical_scope = true;
// a. Assert: uninitializedBoundNames has no duplicate entries.
// b. Let newEnv be NewDeclarativeEnvironment(oldEnv).
generator.begin_variable_scope();
// c. For each String name of uninitializedBoundNames, do
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
MUST(variable_declaration.for_each_bound_name([&](auto const& name) {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// i. Perform ! newEnv.CreateMutableBinding(name, false).
auto identifier = generator.intern_identifier(name);
generator.emit<Bytecode::Op::CreateVariable>(identifier, Bytecode::Op::EnvironmentMode::Lexical, false);
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
}));
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// d. Set the running execution context's LexicalEnvironment to newEnv.
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
// NOTE: Done by CreateLexicalEnvironment.
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
} else {
// Runtime Semantics: ForInOfLoopEvaluation, for any of:
// ForInOfStatement : for ( LeftHandSideExpression in Expression ) Statement
// ForInOfStatement : for ( LeftHandSideExpression of AssignmentExpression ) Statement
result.lhs_kind = LHSKind::Assignment;
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// 3. Let exprRef be the result of evaluating expr.
TRY(rhs->generate_bytecode(generator));
// 4. Set the running execution context's LexicalEnvironment to oldEnv.
if (entered_lexical_scope)
generator.end_variable_scope();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// 5. Let exprValue be ? GetValue(exprRef).
// NOTE: No need to store this anywhere.
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
// 6. If iterationKind is enumerate, then
if (iteration_kind == IterationKind::Enumerate) {
// a. If exprValue is undefined or null, then
auto& nullish_block = generator.make_block();
auto& continuation_block = generator.make_block();
auto& jump = generator.emit<Bytecode::Op::JumpNullish>();
jump.set_targets(Bytecode::Label { nullish_block }, Bytecode::Label { continuation_block });
// i. Return Completion Record { [[Type]]: break, [[Value]]: empty, [[Target]]: empty }.
generator.switch_to_basic_block(nullish_block);
LibJS: Simplify `Generator::perform_needed_unwinds` This does not need to cater to the needs of `break` and `continue anymore, which allows us to simplify it a bit.
2022-11-25 16:42:29 +01:00
generator.generate_break();
LibJS: Support `for (x in obj)` iteration in bytecode VM We were mistakenly treating these as `for (x of obj)`. By reorganizing the code a little bit, we actually support both kinds of iteration with less duplication. :^) Fixes 17 tests in test262.
2022-10-19 17:42:54 +02:00
generator.switch_to_basic_block(continuation_block);
// b. Let obj be ! ToObject(exprValue).
// NOTE: GetObjectPropertyIterator does this.
// c. Let iterator be EnumerateObjectProperties(obj).
// d. Let nextMethod be ! GetV(iterator, "next").
// e. Return the Iterator Record { [[Iterator]]: iterator, [[NextMethod]]: nextMethod, [[Done]]: false }.
generator.emit<Bytecode::Op::GetObjectPropertyIterator>();
}
// 7. Else,
else {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// a. Assert: iterationKind is iterate or async-iterate.
// b. If iterationKind is async-iterate, let iteratorHint be async.
// c. Else, let iteratorHint be sync.
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
auto iterator_hint = iteration_kind == IterationKind::AsyncIterate ? IteratorHint::Async : IteratorHint::Sync;
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// d. Return ? GetIterator(exprValue, iteratorHint).
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
generator.emit<Bytecode::Op::GetIterator>(iterator_hint);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
return result;
}
// 14.7.5.7 ForIn/OfBodyEvaluation ( lhs, stmt, iteratorRecord, iterationKind, lhsKind, labelSet [ , iteratorKind ] ), https://tc39.es/ecma262/#sec-runtime-semantics-forin-div-ofbodyevaluation-lhs-stmt-iterator-lhskind-labelset
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
static Bytecode::CodeGenerationErrorOr<void> for_in_of_body_evaluation(Bytecode::Generator& generator, ASTNode const& node, Variant<NonnullRefPtr<ASTNode const>, NonnullRefPtr<BindingPattern const>> const& lhs, ASTNode const& body, ForInOfHeadEvaluationResult const& head_result, Vector<DeprecatedFlyString> const& label_set, Bytecode::BasicBlock& loop_end, Bytecode::BasicBlock& loop_update, IteratorHint iterator_kind = IteratorHint::Sync)
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
auto iterator_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(iterator_register);
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
// 1. If iteratorKind is not present, set iteratorKind to sync.
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 2. Let oldEnv be the running execution context's LexicalEnvironment.
bool has_lexical_binding = false;
// 3. Let V be undefined.
// NOTE: We don't need 'V' as the resulting value will naturally flow through via the accumulator register.
// 4. Let destructuring be IsDestructuring of lhs.
auto destructuring = head_result.is_destructuring;
// 5. If destructuring is true and if lhsKind is assignment, then
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
if (destructuring && head_result.lhs_kind == LHSKind::Assignment) {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// a. Assert: lhs is a LeftHandSideExpression.
// b. Let assignmentPattern be the AssignmentPattern that is covered by lhs.
// FIXME: Implement this.
return Bytecode::CodeGenerationError {
&node,
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
"Unimplemented: assignment destructuring in for/of"sv,
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
};
}
// 6. Repeat,
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { loop_update });
generator.switch_to_basic_block(loop_update);
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_continuable_scope(Bytecode::Label { loop_update }, label_set);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// a. Let nextResult be ? Call(iteratorRecord.[[NextMethod]], iteratorRecord.[[Iterator]]).
generator.emit<Bytecode::Op::Load>(iterator_register);
generator.emit<Bytecode::Op::IteratorNext>();
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
// b. If iteratorKind is async, set nextResult to ? Await(nextResult).
if (iterator_kind == IteratorHint::Async)
generate_await(generator);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// c. If Type(nextResult) is not Object, throw a TypeError exception.
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
generator.emit<Bytecode::Op::ThrowIfNotObject>();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// d. Let done be ? IteratorComplete(nextResult).
auto iterator_result_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(iterator_result_register);
generator.emit<Bytecode::Op::IteratorResultDone>();
// e. If done is true, return V.
auto& loop_continue = generator.make_block();
generator.emit<Bytecode::Op::JumpConditional>().set_targets(Bytecode::Label { loop_end }, Bytecode::Label { loop_continue });
generator.switch_to_basic_block(loop_continue);
// f. Let nextValue be ? IteratorValue(nextResult).
generator.emit<Bytecode::Op::Load>(iterator_result_register);
generator.emit<Bytecode::Op::IteratorResultValue>();
// g. If lhsKind is either assignment or varBinding, then
if (head_result.lhs_kind != LHSKind::LexicalBinding) {
// i. If destructuring is false, then
if (!destructuring) {
// 1. Let lhsRef be the result of evaluating lhs. (It may be evaluated repeatedly.)
// NOTE: We're skipping all the completion stuff that the spec does, as the unwinding mechanism will take case of doing that.
if (head_result.lhs_kind == LHSKind::VarBinding) {
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
auto& declaration = static_cast<VariableDeclaration const&>(*lhs.get<NonnullRefPtr<ASTNode const>>());
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
VERIFY(declaration.declarations().size() == 1);
TRY(assign_accumulator_to_variable_declarator(generator, declaration.declarations().first(), declaration));
} else {
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
if (auto ptr = lhs.get_pointer<NonnullRefPtr<ASTNode const>>()) {
LibJS: Don't assume that for-in/of target is a variable on LHS::Assign e.g. `for ([foo.bar] in ...)` is actually a binding pattern.
2022-03-31 03:09:36 +04:30
TRY(generator.emit_store_to_reference(**ptr));
} else {
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
auto& binding_pattern = lhs.get<NonnullRefPtr<BindingPattern const>>();
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
auto value_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(value_register);
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
TRY(generate_binding_pattern_bytecode(generator, *binding_pattern, Bytecode::Op::SetVariable::InitializationMode::Set, value_register, false));
LibJS: Don't assume that for-in/of target is a variable on LHS::Assign e.g. `for ([foo.bar] in ...)` is actually a binding pattern.
2022-03-31 03:09:36 +04:30
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
}
}
// h. Else,
else {
// i. Assert: lhsKind is lexicalBinding.
// ii. Assert: lhs is a ForDeclaration.
// iii. Let iterationEnv be NewDeclarativeEnvironment(oldEnv).
// iv. Perform ForDeclarationBindingInstantiation of lhs with argument iterationEnv.
// v. Set the running execution context's LexicalEnvironment to iterationEnv.
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
generator.begin_variable_scope();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
has_lexical_binding = true;
// 14.7.5.4 Runtime Semantics: ForDeclarationBindingInstantiation, https://tc39.es/ecma262/#sec-runtime-semantics-fordeclarationbindinginstantiation
// 1. Assert: environment is a declarative Environment Record.
// NOTE: We just made it.
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
auto& variable_declaration = static_cast<VariableDeclaration const&>(*lhs.get<NonnullRefPtr<ASTNode const>>());
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 2. For each element name of the BoundNames of ForBinding, do
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
MUST(variable_declaration.for_each_bound_name([&](auto const& name) {
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
auto identifier = generator.intern_identifier(name);
// a. If IsConstantDeclaration of LetOrConst is true, then
if (variable_declaration.is_constant_declaration()) {
// i. Perform ! environment.CreateImmutableBinding(name, true).
generator.emit<Bytecode::Op::CreateVariable>(identifier, Bytecode::Op::EnvironmentMode::Lexical, true);
}
// b. Else,
else {
// i. Perform ! environment.CreateMutableBinding(name, false).
generator.emit<Bytecode::Op::CreateVariable>(identifier, Bytecode::Op::EnvironmentMode::Lexical, false);
}
LibJS: Don't discard ThrowCompletionOr<void> from declaration iteration
2023-02-27 22:13:37 +00:00
}));
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 3. Return unused.
// NOTE: No need to do that as we've inlined this.
// vi. If destructuring is false, then
if (!destructuring) {
// 1. Assert: lhs binds a single name.
// 2. Let lhsName be the sole element of BoundNames of lhs.
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
auto lhs_name = variable_declaration.declarations().first()->target().get<NonnullRefPtr<Identifier const>>()->string();
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// 3. Let lhsRef be ! ResolveBinding(lhsName).
// NOTE: We're skipping all the completion stuff that the spec does, as the unwinding mechanism will take case of doing that.
auto identifier = generator.intern_identifier(lhs_name);
generator.emit<Bytecode::Op::SetVariable>(identifier, Bytecode::Op::SetVariable::InitializationMode::Initialize, Bytecode::Op::EnvironmentMode::Lexical);
}
}
// i. If destructuring is false, then
if (!destructuring) {
// i. If lhsRef is an abrupt completion, then
// 1. Let status be lhsRef.
// ii. Else if lhsKind is lexicalBinding, then
// 1. Let status be Completion(InitializeReferencedBinding(lhsRef, nextValue)).
// iii. Else,
// 1. Let status be Completion(PutValue(lhsRef, nextValue)).
// NOTE: This is performed above.
}
// j. Else,
else {
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
// FIXME: i. If lhsKind is assignment, then
// 1. Let status be Completion(DestructuringAssignmentEvaluation of assignmentPattern with argument nextValue).
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
// ii. Else if lhsKind is varBinding, then
// 1. Assert: lhs is a ForBinding.
// 2. Let status be Completion(BindingInitialization of lhs with arguments nextValue and undefined).
// iii. Else,
// 1. Assert: lhsKind is lexicalBinding.
// 2. Assert: lhs is a ForDeclaration.
// 3. Let status be Completion(ForDeclarationBindingInitialization of lhs with arguments nextValue and iterationEnv).
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
if (head_result.lhs_kind == LHSKind::VarBinding || head_result.lhs_kind == LHSKind::LexicalBinding) {
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
auto& declaration = static_cast<VariableDeclaration const&>(*lhs.get<NonnullRefPtr<ASTNode const>>());
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
VERIFY(declaration.declarations().size() == 1);
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
auto& binding_pattern = declaration.declarations().first()->target().get<NonnullRefPtr<BindingPattern const>>();
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
auto value_register = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(value_register);
LibJS/Bytecode: Support destructuring in try..catch 112 new passes in test262.
2023-06-24 20:29:30 +02:00
TRY(generate_binding_pattern_bytecode(generator, *binding_pattern, head_result.lhs_kind == LHSKind::VarBinding ? Bytecode::Op::SetVariable::InitializationMode::Set : Bytecode::Op::SetVariable::InitializationMode::Initialize, value_register, false));
LibJS/Bytecode: Implement var/lexical binding destructuring in for/of
2022-12-09 18:47:51 +00:00
} else {
return Bytecode::CodeGenerationError {
&node,
"Unimplemented: assignment destructuring in for/of"sv,
};
}
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
// FIXME: Implement iteration closure.
// k. If status is an abrupt completion, then
// i. Set the running execution context's LexicalEnvironment to oldEnv.
// ii. If iteratorKind is async, return ? AsyncIteratorClose(iteratorRecord, status).
// iii. If iterationKind is enumerate, then
// 1. Return ? status.
// iv. Else,
// 1. Assert: iterationKind is iterate.
// 2. Return ? IteratorClose(iteratorRecord, status).
// l. Let result be the result of evaluating stmt.
TRY(body.generate_bytecode(generator));
// m. Set the running execution context's LexicalEnvironment to oldEnv.
if (has_lexical_binding)
generator.end_variable_scope();
generator.end_continuable_scope();
generator.end_breakable_scope();
// NOTE: If we're here, then the loop definitely continues.
// n. If LoopContinues(result, labelSet) is false, then
// i. If iterationKind is enumerate, then
// 1. Return ? UpdateEmpty(result, V).
// ii. Else,
// 1. Assert: iterationKind is iterate.
// 2. Set status to Completion(UpdateEmpty(result, V)).
// 3. If iteratorKind is async, return ? AsyncIteratorClose(iteratorRecord, status).
// 4. Return ? IteratorClose(iteratorRecord, status).
// o. If result.[[Value]] is not empty, set V to result.[[Value]].
LibJS: Generate update Jump in for/in/of only if block is not terminated The body of for/in/of can contain an unconditional block terminator (e.g. return, throw), so we have to check for that before generating the Jump to the loop update block.
2022-03-27 18:46:25 +01:00
// The body can contain an unconditional block terminator (e.g. return, throw), so we have to check for that before generating the Jump.
if (!generator.is_current_block_terminated())
generator.emit<Bytecode::Op::Jump>().set_targets(Bytecode::Label { loop_update }, {});
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
generator.switch_to_basic_block(loop_end);
return {};
}
Bytecode::CodeGenerationErrorOr<void> ForInStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
return generate_labelled_evaluation(generator, {});
}
// 14.7.5.5 Runtime Semantics: ForInOfLoopEvaluation, https://tc39.es/ecma262/#sec-runtime-semantics-forinofloopevaluation
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
Bytecode::CodeGenerationErrorOr<void> ForInStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
auto& loop_end = generator.make_block();
auto& loop_update = generator.make_block();
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_breakable_scope(Bytecode::Label { loop_end }, label_set);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
auto head_result = TRY(for_in_of_head_evaluation(generator, IterationKind::Enumerate, m_lhs, m_rhs));
// Now perform the rest of ForInOfLoopEvaluation, given that the accumulator holds the iterator we're supposed to iterate over.
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return for_in_of_body_evaluation(generator, *this, m_lhs, body(), head_result, label_set, loop_end, loop_update);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
Bytecode::CodeGenerationErrorOr<void> ForOfStatement::generate_bytecode(Bytecode::Generator& generator) const
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
{
return generate_labelled_evaluation(generator, {});
}
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
Bytecode::CodeGenerationErrorOr<void> ForOfStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
{
auto& loop_end = generator.make_block();
auto& loop_update = generator.make_block();
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
generator.begin_breakable_scope(Bytecode::Label { loop_end }, label_set);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
auto head_result = TRY(for_in_of_head_evaluation(generator, IterationKind::Iterate, m_lhs, m_rhs));
// Now perform the rest of ForInOfLoopEvaluation, given that the accumulator holds the iterator we're supposed to iterate over.
LibJS/Bytecode: Implement break/continue labels This is done by keeping track of all the labels that apply to a given break/continue scope alongside their bytecode target. When a break/continue with a label is generated, we scan from the most inner scope to the most outer scope looking for the label, performing any necessary unwinds on the way. Once the label is found, it is then jumped to.
2022-06-11 23:09:37 +01:00
return for_in_of_body_evaluation(generator, *this, m_lhs, body(), head_result, label_set, loop_end, loop_update);
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 20:18:19 +03:30
}
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
Bytecode::CodeGenerationErrorOr<void> ForAwaitOfStatement::generate_bytecode(Bytecode::Generator& generator) const
{
return generate_labelled_evaluation(generator, {});
}
Bytecode::CodeGenerationErrorOr<void> ForAwaitOfStatement::generate_labelled_evaluation(Bytecode::Generator& generator, Vector<DeprecatedFlyString> const& label_set) const
{
auto& loop_end = generator.make_block();
auto& loop_update = generator.make_block();
generator.begin_breakable_scope(Bytecode::Label { loop_end }, label_set);
auto head_result = TRY(for_in_of_head_evaluation(generator, IterationKind::AsyncIterate, m_lhs, m_rhs));
// Now perform the rest of ForInOfLoopEvaluation, given that the accumulator holds the iterator we're supposed to iterate over.
return for_in_of_body_evaluation(generator, *this, m_lhs, m_body, head_result, label_set, loop_end, loop_update, IteratorHint::Async);
}
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
// 13.3.12.1 Runtime Semantics: Evaluation, https://tc39.es/ecma262/#sec-meta-properties-runtime-semantics-evaluation
Bytecode::CodeGenerationErrorOr<void> MetaProperty::generate_bytecode(Bytecode::Generator& generator) const
{
// NewTarget : new . target
if (m_type == MetaProperty::Type::NewTarget) {
// 1. Return GetNewTarget().
generator.emit<Bytecode::Op::GetNewTarget>();
return {};
}
// ImportMeta : import . meta
if (m_type == MetaProperty::Type::ImportMeta) {
return Bytecode::CodeGenerationError {
this,
"Unimplemented meta property: import.meta"sv,
};
}
VERIFY_NOT_REACHED();
}
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
Bytecode::CodeGenerationErrorOr<void> ClassFieldInitializerStatement::generate_bytecode(Bytecode::Generator& generator) const
{
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
TRY(generator.emit_named_evaluation_if_anonymous_function(*m_expression, m_class_field_identifier_name));
LibJS/Bytecode: Support class field initializers Fixes 513 test262 tests. :^)
2023-06-17 10:11:23 +02:00
generator.perform_needed_unwinds<Bytecode::Op::Return>();
generator.emit<Bytecode::Op::Return>();
return {};
}
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
static Bytecode::CodeGenerationErrorOr<void> generate_optional_chain(Bytecode::Generator& generator, OptionalChain const& optional_chain, Bytecode::Register current_value_register, Bytecode::Register current_base_register)
{
if (is<MemberExpression>(optional_chain.base())) {
auto& member_expression = static_cast<MemberExpression const&>(optional_chain.base());
TRY(get_base_and_value_from_member_expression(generator, member_expression, current_base_register));
} else if (is<OptionalChain>(optional_chain.base())) {
auto& sub_optional_chain = static_cast<OptionalChain const&>(optional_chain.base());
TRY(generate_optional_chain(generator, sub_optional_chain, current_value_register, current_base_register));
} else {
TRY(optional_chain.base().generate_bytecode(generator));
}
generator.emit<Bytecode::Op::Store>(current_value_register);
auto& load_undefined_and_jump_to_end_block = generator.make_block();
auto& end_block = generator.make_block();
for (auto& reference : optional_chain.references()) {
auto is_optional = reference.visit([](auto& ref) { return ref.mode; }) == OptionalChain::Mode::Optional;
if (is_optional) {
auto& not_nullish_block = generator.make_block();
generator.emit<Bytecode::Op::JumpNullish>(
Bytecode::Label { load_undefined_and_jump_to_end_block },
Bytecode::Label { not_nullish_block });
generator.switch_to_basic_block(not_nullish_block);
}
TRY(reference.visit(
[&](OptionalChain::Call const& call) -> Bytecode::CodeGenerationErrorOr<void> {
TRY(arguments_to_array_for_call(generator, call.arguments));
generator.emit<Bytecode::Op::Call>(Bytecode::Op::Call::CallType::Call, current_value_register, current_base_register);
generator.emit<Bytecode::Op::Store>(current_value_register);
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::Store>(current_base_register);
generator.emit<Bytecode::Op::Load>(current_value_register);
return {};
},
[&](OptionalChain::ComputedReference const& ref) -> Bytecode::CodeGenerationErrorOr<void> {
generator.emit<Bytecode::Op::Store>(current_base_register);
TRY(ref.expression->generate_bytecode(generator));
generator.emit<Bytecode::Op::GetByValue>(current_base_register);
generator.emit<Bytecode::Op::Store>(current_value_register);
return {};
},
[&](OptionalChain::MemberReference const& ref) -> Bytecode::CodeGenerationErrorOr<void> {
generator.emit<Bytecode::Op::Store>(current_base_register);
generator.emit<Bytecode::Op::GetById>(generator.intern_identifier(ref.identifier->string()));
generator.emit<Bytecode::Op::Store>(current_value_register);
return {};
},
LibJS/Bytecode: Support private identifiers in optional chaining Fixes 4 test262 tests :^)
2023-06-23 19:09:41 +01:00
[&](OptionalChain::PrivateMemberReference const& ref) -> Bytecode::CodeGenerationErrorOr<void> {
generator.emit<Bytecode::Op::Store>(current_base_register);
generator.emit<Bytecode::Op::GetPrivateById>(generator.intern_identifier(ref.private_identifier->string()));
generator.emit<Bytecode::Op::Store>(current_value_register);
return {};
LibJS/Bytecode: Implement optional chaining
2023-06-17 14:50:23 +01:00
}));
}
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(load_undefined_and_jump_to_end_block);
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::Jump>(Bytecode::Label { end_block });
generator.switch_to_basic_block(end_block);
return {};
}
Bytecode::CodeGenerationErrorOr<void> OptionalChain::generate_bytecode(Bytecode::Generator& generator) const
{
auto current_base_register = generator.allocate_register();
auto current_value_register = generator.allocate_register();
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
generator.emit<Bytecode::Op::Store>(current_base_register);
return generate_optional_chain(generator, *this, current_value_register, current_base_register);
}
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
Bytecode::CodeGenerationErrorOr<void> ImportCall::generate_bytecode(Bytecode::Generator& generator) const
{
TRY(m_specifier->generate_bytecode(generator));
auto specifier_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(specifier_reg);
if (m_options) {
TRY(m_options->generate_bytecode(generator));
} else {
generator.emit<Bytecode::Op::LoadImmediate>(js_undefined());
}
auto options_reg = generator.allocate_register();
generator.emit<Bytecode::Op::Store>(options_reg);
generator.emit<Bytecode::Op::ImportCall>(specifier_reg, options_reg);
return {};
}
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
Bytecode::CodeGenerationErrorOr<void> ExportStatement::generate_bytecode(Bytecode::Generator& generator) const
{
if (!is_default_export()) {
if (m_statement) {
return m_statement->generate_bytecode(generator);
}
return {};
}
VERIFY(m_statement);
if (is<FunctionDeclaration>(*m_statement) || is<ClassDeclaration>(*m_statement)) {
return m_statement->generate_bytecode(generator);
}
if (is<ClassExpression>(*m_statement)) {
TODO();
}
// ExportDeclaration : export default AssignmentExpression ;
VERIFY(is<Expression>(*m_statement));
TRY(generator.emit_named_evaluation_if_anonymous_function(static_cast<Expression const&>(*m_statement), DeprecatedFlyString("default"sv)));
generator.emit<Bytecode::Op::SetVariable>(generator.intern_identifier("default"sv));
return {};
}
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
Bytecode::CodeGenerationErrorOr<void> ImportStatement::generate_bytecode(Bytecode::Generator&) const
{
return {};
}
LibJS: Move AST bytecode generation virtuals to separate cpp file This will hopefully make it a bit more pleasant to edit this, as things will just get larger and larger.
2021-06-04 11:31:13 +02:00
}
Reference in a new issue Copy permalink