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

449 lines
19 KiB
C++
Raw Normal View History

LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
/*
Everywhere: Use s.unverwerth@serenityos.org :^)
2021-05-29 12:38:28 +02:00
* Copyright (c) 2020, Stephan Unverwerth <s.unverwerth@serenityos.org>
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
*/
LibJS: Move bytecode debug spam behind JS_BYTECODE_DEBUG :^)
2021-06-07 15:17:37 +02:00
#include <AK/Debug.h>
LibJS: Add length property to ScriptFunction
2020-04-04 14:34:27 +01:00
#include <AK/Function.h>
LibJS: Make the AST reference-counted This allows function objects to outlive the original parsed program without their ScopeNode disappearing.
2020-03-18 11:23:53 +01:00
#include <LibJS/AST.h>
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
#include <LibJS/Bytecode/BasicBlock.h>
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
#include <LibJS/Bytecode/Generator.h>
#include <LibJS/Bytecode/Interpreter.h>
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
#include <LibJS/Interpreter.h>
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
#include <LibJS/Runtime/AbstractOperations.h>
LibJS: Implement rest parameters
2020-05-04 16:05:13 +01:00
#include <LibJS/Runtime/Array.h>
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
#include <LibJS/Runtime/ECMAScriptFunctionObject.h>
LibJS: Add length property to ScriptFunction
2020-04-04 14:34:27 +01:00
#include <LibJS/Runtime/Error.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/FunctionEnvironment.h>
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
#include <LibJS/Runtime/GeneratorObject.h>
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
#include <LibJS/Runtime/GeneratorObjectPrototype.h>
LibJS: Pass prototype to Function constructors
2020-04-17 19:59:32 +02:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
#include <LibJS/Runtime/NativeFunction.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.h>
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
namespace JS {
LibJS: Rename ECMAScriptFunctionObject members to match spec names Also add the internal slot names as comments, and separate them into groups of spec and non-spec members. This will make it easier to compare the implementation code with the spec, as well as identify internal slots currently missing or only present on FunctionObject.
2021-09-24 23:10:21 +02:00
ECMAScriptFunctionObject* ECMAScriptFunctionObject::create(GlobalObject& global_object, FlyString name, Statement const& ecmascript_code, Vector<FunctionNode::Parameter> parameters, i32 m_function_length, Environment* parent_scope, FunctionKind kind, bool is_strict, bool is_arrow_function)
LibJS: Pass prototype to Function constructors
2020-04-17 19:59:32 +02:00
{
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
Object* prototype = nullptr;
switch (kind) {
case FunctionKind::Regular:
prototype = global_object.function_prototype();
break;
case FunctionKind::Generator:
prototype = global_object.generator_function_prototype();
break;
}
LibJS: Move [[BoundThis]] and [[BoundArguments]] to BoundFunction
2021-09-25 00:38:23 +02:00
return global_object.heap().allocate<ECMAScriptFunctionObject>(global_object, move(name), ecmascript_code, move(parameters), m_function_length, parent_scope, *prototype, kind, is_strict, is_arrow_function);
LibJS: Pass prototype to Function constructors
2020-04-17 19:59:32 +02:00
}
LibJS: Move [[BoundThis]] and [[BoundArguments]] to BoundFunction
2021-09-25 00:38:23 +02:00
ECMAScriptFunctionObject::ECMAScriptFunctionObject(FlyString name, Statement const& ecmascript_code, Vector<FunctionNode::Parameter> formal_parameters, i32 function_length, Environment* parent_scope, Object& prototype, FunctionKind kind, bool strict, bool is_arrow_function)
: FunctionObject(prototype)
LibJS: Rename ScriptFunction::m_parent_scope => m_environment This is for the [[Environment]] slot so let's have a matching name. :^)
2021-06-25 21:22:37 +02:00
, m_environment(parent_scope)
LibJS: Rename ECMAScriptFunctionObject members to match spec names Also add the internal slot names as comments, and separate them into groups of spec and non-spec members. This will make it easier to compare the implementation code with the spec, as well as identify internal slots currently missing or only present on FunctionObject.
2021-09-24 23:10:21 +02:00
, m_formal_parameters(move(formal_parameters))
, m_ecmascript_code(ecmascript_code)
LibJS: Set OrdinaryFunctionObject's realm from the Tnterpreter ...instead of relying on the VM having a current execution context. This was an incorrect assumption I made, and it caused onfoo attribute handler construction in LibWeb to crash. Just use the same mechanism as NativeFunction in the meantime.
2021-09-12 23:10:16 +01:00
, m_realm(vm().interpreter_if_exists() ? &vm().interpreter().realm() : nullptr)
LibJS: Rename ECMAScriptFunctionObject members to match spec names Also add the internal slot names as comments, and separate them into groups of spec and non-spec members. This will make it easier to compare the implementation code with the spec, as well as identify internal slots currently missing or only present on FunctionObject.
2021-09-24 23:10:21 +02:00
, m_strict(strict)
, m_name(move(name))
LibJS: Don't use m_ prefix for argument name in ScriptFunction
2021-06-24 13:29:25 +02:00
, m_function_length(function_length)
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11 03:38:05 +04:30
, m_kind(kind)
LibJS: Track whether ScriptFunctions and FunctionExpressions are arrow functions
2020-05-30 00:10:42 -05:00
, m_is_arrow_function(is_arrow_function)
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
{
LibJS: Add the Function.[[ThisMode]] field This is not a behavioral change in itself, just prep work for future spec-compliance changes.
2021-06-25 20:53:17 +02:00
// NOTE: This logic is from OrdinaryFunctionCreate, https://tc39.es/ecma262/#sec-ordinaryfunctioncreate
if (m_is_arrow_function)
LibJS: Move [[ThisMode]] to ECMAScriptFunctionObject
2021-09-24 23:19:36 +02:00
m_this_mode = ThisMode::Lexical;
LibJS: Rename ECMAScriptFunctionObject members to match spec names Also add the internal slot names as comments, and separate them into groups of spec and non-spec members. This will make it easier to compare the implementation code with the spec, as well as identify internal slots currently missing or only present on FunctionObject.
2021-09-24 23:10:21 +02:00
else if (m_strict)
LibJS: Move [[ThisMode]] to ECMAScriptFunctionObject
2021-09-24 23:19:36 +02:00
m_this_mode = ThisMode::Strict;
LibJS: Add the Function.[[ThisMode]] field This is not a behavioral change in itself, just prep work for future spec-compliance changes.
2021-06-25 20:53:17 +02:00
else
LibJS: Move [[ThisMode]] to ECMAScriptFunctionObject
2021-09-24 23:19:36 +02:00
m_this_mode = ThisMode::Global;
LibJS: Use CreateUnmappedArgumentsObject for non-simple parameter lists This patch implements the IsSimpleParameterList static semantics for ordinary function objects. We now also create an unmapped arguments object for callee contexts with non-simple parameter lists, instead of only doing it in strict mode. Covered by test262.
2021-06-28 11:18:32 +02:00
// 15.1.3 Static Semantics: IsSimpleParameterList, https://tc39.es/ecma262/#sec-static-semantics-issimpleparameterlist
LibJS: Move has_simple_parameter_list to ECMAScriptFunctionObject
2021-09-25 00:10:09 +02:00
m_has_simple_parameter_list = all_of(m_formal_parameters, [&](auto& parameter) {
LibJS: Use CreateUnmappedArgumentsObject for non-simple parameter lists This patch implements the IsSimpleParameterList static semantics for ordinary function objects. We now also create an unmapped arguments object for callee contexts with non-simple parameter lists, instead of only doing it in strict mode. Covered by test262.
2021-06-28 11:18:32 +02:00
if (parameter.is_rest)
return false;
if (parameter.default_value)
return false;
if (!parameter.binding.template has<FlyString>())
return false;
return true;
LibJS: Move has_simple_parameter_list to ECMAScriptFunctionObject
2021-09-25 00:10:09 +02:00
});
LibJS: Split more native object constructors into construct/initialize
2020-06-20 17:11:11 +02:00
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
void ECMAScriptFunctionObject::initialize(GlobalObject& global_object)
LibJS: Split more native object constructors into construct/initialize
2020-06-20 17:11:11 +02:00
{
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
auto& vm = this->vm();
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
Base::initialize(global_object);
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
if (!m_is_arrow_function) {
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
auto* prototype = vm.heap().allocate<Object>(global_object, *global_object.new_ordinary_function_prototype_object_shape());
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
switch (m_kind) {
case FunctionKind::Regular:
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
prototype->define_property_or_throw(vm.names.constructor, { .value = this, .writable = true, .enumerable = false, .configurable = true });
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
break;
case FunctionKind::Generator:
// prototype is "g1.prototype" in figure-2 (https://tc39.es/ecma262/img/figure-2.png)
LibJS+LibWeb: Use Object::set_prototype() in more places
2021-10-02 14:32:37 +01:00
set_prototype(global_object.generator_object_prototype());
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
break;
}
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
define_direct_property(vm.names.prototype, prototype, Attribute::Writable);
LibJS: Define the "constructor" property on ScriptFunction's prototype and set it to the current function
2020-06-08 13:24:15 -05:00
}
LibJS: Remove usage of define_native_property in OrdinaryFunctionObject The length & name properties are supposed to be normal data properties.
2021-07-05 18:02:27 +03:00
define_property_or_throw(vm.names.length, { .value = Value(m_function_length), .writable = false, .enumerable = false, .configurable = true });
define_property_or_throw(vm.names.name, { .value = js_string(vm, m_name.is_null() ? "" : m_name), .writable = false, .enumerable = false, .configurable = true });
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
ECMAScriptFunctionObject::~ECMAScriptFunctionObject()
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
{
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
void ECMAScriptFunctionObject::visit_edges(Visitor& visitor)
LibJS: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 21:58:22 +02:00
{
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
Base::visit_edges(visitor);
LibJS: Rename ScriptFunction::m_parent_scope => m_environment This is for the [[Environment]] slot so let's have a matching name. :^)
2021-06-25 21:22:37 +02:00
visitor.visit(m_environment);
LibJS: Visit OrdinaryFunctionObject's owning realm
2021-09-11 19:19:08 +03:00
visitor.visit(m_realm);
LibJS: Move [[HomeObject]] to ECMAScriptFunctionObject
2021-09-24 23:49:24 +02:00
visitor.visit(m_home_object);
LibJS: Move [[Fields]] to ECMAScriptFunctionObject
2021-09-25 00:01:09 +02:00
for (auto& field : m_fields) {
field.name.visit_edges(visitor);
visitor.visit(field.initializer);
}
LibJS: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 21:58:22 +02:00
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
// 9.1.2.4 NewFunctionEnvironment ( F, newTarget ), https://tc39.es/ecma262/#sec-newfunctionenvironment
FunctionEnvironment* ECMAScriptFunctionObject::new_function_environment(Object* new_target)
LibJS: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 21:58:22 +02:00
{
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
auto* environment = heap().allocate<FunctionEnvironment>(global_object(), m_environment);
environment->set_function_object(*this);
if (this_mode() == ThisMode::Lexical) {
environment->set_this_binding_status(FunctionEnvironment::ThisBindingStatus::Lexical);
}
environment->set_new_target(new_target ? new_target : js_undefined());
return environment;
}
// 10.2.11 FunctionDeclarationInstantiation ( func, argumentsList ), https://tc39.es/ecma262/#sec-functiondeclarationinstantiation
ThrowCompletionOr<void> ECMAScriptFunctionObject::function_declaration_instantiation(Interpreter* interpreter)
{
auto& vm = this->vm();
auto& callee_context = vm.running_execution_context();
// Needed to extract declarations and functions
ScopeNode const* scope_body = nullptr;
if (is<ScopeNode>(*m_ecmascript_code))
scope_body = static_cast<ScopeNode const*>(m_ecmascript_code.ptr());
bool has_parameter_expressions = false;
// FIXME: Maybe compute has duplicates at parse time? (We need to anyway since it's an error in some cases)
bool has_duplicates = false;
HashTable<FlyString> parameter_names;
LibJS: Rename ECMAScriptFunctionObject members to match spec names Also add the internal slot names as comments, and separate them into groups of spec and non-spec members. This will make it easier to compare the implementation code with the spec, as well as identify internal slots currently missing or only present on FunctionObject.
2021-09-24 23:10:21 +02:00
for (auto& parameter : m_formal_parameters) {
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
if (parameter.default_value)
has_parameter_expressions = true;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
parameter.binding.visit(
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
[&](FlyString const& name) {
if (parameter_names.set(name) != AK::HashSetResult::InsertedNewEntry)
has_duplicates = true;
},
[&](NonnullRefPtr<BindingPattern> const& pattern) {
if (pattern->contains_expression())
has_parameter_expressions = true;
pattern->for_each_bound_name([&](auto& name) {
if (parameter_names.set(name) != AK::HashSetResult::InsertedNewEntry)
has_duplicates = true;
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
});
});
LibJS: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 21:58:22 +02:00
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
auto needs_argument_object = this_mode() != ThisMode::Lexical;
if (parameter_names.contains(vm.names.arguments.as_string()))
needs_argument_object = false;
HashTable<FlyString> function_names;
Vector<FunctionDeclaration const&> functions_to_initialize;
if (scope_body) {
scope_body->for_each_var_function_declaration_in_reverse_order([&](FunctionDeclaration const& function) {
if (function_names.set(function.name()) == AK::HashSetResult::InsertedNewEntry)
functions_to_initialize.append(function);
});
auto arguments_name = vm.names.arguments.as_string();
if (!has_parameter_expressions && function_names.contains(arguments_name))
needs_argument_object = false;
if (!has_parameter_expressions && needs_argument_object) {
scope_body->for_each_lexically_declared_name([&](auto const& name) {
if (name == arguments_name)
needs_argument_object = false;
return IterationDecision::Continue;
});
LibJS: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 21:58:22 +02:00
}
}
LibJS: Initial class implementation; allow super expressions in object literal methods; add EnvrionmentRecord fields and methods to LexicalEnvironment Adding EnvrionmentRecord's fields and methods lets us throw an exception when |this| is not initialized, which occurs when the super constructor in a derived class has not yet been called, or when |this| has already been initialized (the super constructor was already called).
2020-06-08 13:31:21 -05:00
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
Environment* environment;
if (is_strict_mode() || !has_parameter_expressions) {
environment = callee_context.lexical_environment;
} else {
environment = new_declarative_environment(*callee_context.lexical_environment);
VERIFY(callee_context.variable_environment == callee_context.lexical_environment);
callee_context.lexical_environment = environment;
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01:00
}
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
for (auto const& parameter_name : parameter_names) {
if (environment->has_binding(parameter_name))
continue;
environment->create_mutable_binding(global_object(), parameter_name, false);
if (has_duplicates)
environment->initialize_binding(global_object(), parameter_name, js_undefined());
VERIFY(!vm.exception());
}
if (needs_argument_object) {
Object* arguments_object;
if (is_strict_mode() || !has_simple_parameter_list())
arguments_object = create_unmapped_arguments_object(global_object(), vm.running_execution_context().arguments);
else
arguments_object = create_mapped_arguments_object(global_object(), *this, formal_parameters(), vm.running_execution_context().arguments, *environment);
if (is_strict_mode())
environment->create_immutable_binding(global_object(), vm.names.arguments.as_string(), false);
else
environment->create_mutable_binding(global_object(), vm.names.arguments.as_string(), false);
environment->initialize_binding(global_object(), vm.names.arguments.as_string(), arguments_object);
parameter_names.set(vm.names.arguments.as_string());
}
// We now treat parameterBindings as parameterNames.
// The spec makes an iterator here to do IteratorBindingInitialization but we just do it manually
auto& execution_context_arguments = vm.running_execution_context().arguments;
for (size_t i = 0; i < m_formal_parameters.size(); ++i) {
auto& parameter = m_formal_parameters[i];
parameter.binding.visit(
[&](auto const& param) {
Value argument_value;
if (parameter.is_rest) {
auto* array = Array::create(global_object(), 0);
for (size_t rest_index = i; rest_index < execution_context_arguments.size(); ++rest_index)
array->indexed_properties().append(execution_context_arguments[rest_index]);
argument_value = move(array);
} else if (i < execution_context_arguments.size() && !execution_context_arguments[i].is_undefined()) {
argument_value = execution_context_arguments[i];
} else if (parameter.default_value) {
// FIXME: Support default arguments in the bytecode world!
if (interpreter)
argument_value = parameter.default_value->execute(*interpreter, global_object());
if (vm.exception())
return;
} else {
argument_value = js_undefined();
}
Environment* used_environment = has_duplicates ? nullptr : environment;
if constexpr (IsSame<FlyString const&, decltype(param)>) {
Reference reference = vm.resolve_binding(param, used_environment);
if (vm.exception())
return;
// Here the difference from hasDuplicates is important
if (has_duplicates)
reference.put_value(global_object(), argument_value);
else
reference.initialize_referenced_binding(global_object(), argument_value);
} else if (IsSame<NonnullRefPtr<BindingPattern> const&, decltype(param)>) {
// Here the difference from hasDuplicates is important
auto result = vm.binding_initialization(param, argument_value, used_environment, global_object());
if (result.is_error())
return;
}
if (vm.exception())
return;
});
if (auto* exception = vm.exception())
return throw_completion(exception->value());
}
Environment* var_environment;
HashTable<FlyString> instantiated_var_names;
if (!has_parameter_expressions) {
if (scope_body) {
scope_body->for_each_var_declared_name([&](auto const& name) {
if (!parameter_names.contains(name) && instantiated_var_names.set(name) == AK::HashSetResult::InsertedNewEntry) {
environment->create_mutable_binding(global_object(), name, false);
environment->initialize_binding(global_object(), name, js_undefined());
}
});
}
var_environment = environment;
} else {
var_environment = new_declarative_environment(*environment);
callee_context.variable_environment = var_environment;
if (scope_body) {
scope_body->for_each_var_declared_name([&](auto const& name) {
if (instantiated_var_names.set(name) != AK::HashSetResult::InsertedNewEntry)
return IterationDecision::Continue;
var_environment->create_mutable_binding(global_object(), name, false);
Value initial_value;
if (!parameter_names.contains(name) || function_names.contains(name))
initial_value = js_undefined();
else
initial_value = environment->get_binding_value(global_object(), name, false);
var_environment->initialize_binding(global_object(), name, initial_value);
return IterationDecision::Continue;
});
}
}
// B.3.2.1 Changes to FunctionDeclarationInstantiation, https://tc39.es/ecma262/#sec-web-compat-functiondeclarationinstantiation
if (!m_strict && scope_body) {
scope_body->for_each_function_hoistable_with_annexB_extension([&](FunctionDeclaration& function_declaration) {
auto& function_name = function_declaration.name();
if (parameter_names.contains(function_name))
return IterationDecision::Continue;
// The spec says 'initializedBindings' here but that does not exist and it then adds it to 'instantiatedVarNames' so it probably means 'instantiatedVarNames'.
if (!instantiated_var_names.contains(function_name) && function_name != vm.names.arguments.as_string()) {
var_environment->create_mutable_binding(global_object(), function_name, false);
VERIFY(!vm.exception());
var_environment->initialize_binding(global_object(), function_name, js_undefined());
instantiated_var_names.set(function_name);
}
function_declaration.set_should_do_additional_annexB_steps();
return IterationDecision::Continue;
});
}
Environment* lex_environment;
if (!is_strict_mode())
lex_environment = new_declarative_environment(*var_environment);
else
lex_environment = var_environment;
callee_context.lexical_environment = lex_environment;
if (!scope_body)
return {};
scope_body->for_each_lexically_scoped_declaration([&](Declaration const& declaration) {
declaration.for_each_bound_name([&](auto const& name) {
if (declaration.is_constant_declaration())
lex_environment->create_immutable_binding(global_object(), name, true);
else
lex_environment->create_mutable_binding(global_object(), name, false);
return IterationDecision::Continue;
});
});
VERIFY(!vm.exception());
for (auto& declaration : functions_to_initialize) {
auto* function = ECMAScriptFunctionObject::create(global_object(), declaration.name(), declaration.body(), declaration.parameters(), declaration.function_length(), lex_environment, declaration.kind(), declaration.is_strict_mode());
var_environment->set_mutable_binding(global_object(), declaration.name(), function, false);
}
return {};
LibJS: Introduce LexicalEnvironment This patch replaces the old variable lookup logic with a new one based on lexical environments. This brings us closer to the way JavaScript is actually specced, and also gives us some basic support for closures. The interpreter's call stack frames now have a pointer to the lexical environment for that frame. Each lexical environment can have a chain of parent environments. Before calling a Function, we first ask it to create_environment(). This gives us a new LexicalEnvironment for that function, which has the function's lexical parent's environment as its parent. This allows inner functions to access variables in their outer function: function foo() { <-- LexicalEnvironment A var x = 1; function() { <-- LexicalEnvironment B (parent: A) console.log(x); } } If we return the result of a function expression from a function, that new function object will keep a reference to its parent environment, which is how we get closures. :^) I'm pretty sure I didn't get everything right here, but it's a pretty good start. This is quite a bit slower than before, but also correcter!
2020-04-15 21:58:22 +02:00
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
Value ECMAScriptFunctionObject::execute_function_body()
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
{
LibJS: Refactor ScriptFunction::call() a bit - Get VM reference once - Less nesting - Better variable names
2020-11-11 21:37:23 +00:00
auto& vm = this->vm();
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
auto* bytecode_interpreter = Bytecode::Interpreter::current();
if (bytecode_interpreter) {
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
// FIXME: pass something to evaluate default arguments with
TRY_OR_DISCARD(function_declaration_instantiation(nullptr));
LibJS: Rename Bytecode::ExecutionUnit => Bytecode::Executable
2021-06-09 09:11:20 +02:00
if (!m_bytecode_executable.has_value()) {
LibJS: Rename ECMAScriptFunctionObject members to match spec names Also add the internal slot names as comments, and separate them into groups of spec and non-spec members. This will make it easier to compare the implementation code with the spec, as well as identify internal slots currently missing or only present on FunctionObject.
2021-09-24 23:10:21 +02:00
m_bytecode_executable = Bytecode::Generator::generate(m_ecmascript_code, m_kind == FunctionKind::Generator);
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 20:40:20 +04:30
auto& passes = JS::Bytecode::Interpreter::optimization_pipeline();
passes.perform(*m_bytecode_executable);
LibJS: Cache generated bytecode for ScriptFunction It's silly to generate new bytecode every time you call a function. Let's just cache the code instead. :^)
2021-06-07 15:19:48 +02:00
if constexpr (JS_BYTECODE_DEBUG) {
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 20:40:20 +04:30
dbgln("Optimisation passes took {}us", passes.elapsed());
LibJS: Cache generated bytecode for ScriptFunction It's silly to generate new bytecode every time you call a function. Let's just cache the code instead. :^)
2021-06-07 15:19:48 +02:00
dbgln("Compiled Bytecode::Block for function '{}':", m_name);
LibJS: Rename Bytecode::ExecutionUnit => Bytecode::Executable
2021-06-09 09:11:20 +02:00
for (auto& block : m_bytecode_executable->basic_blocks)
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
block.dump(*m_bytecode_executable);
LibJS: Cache generated bytecode for ScriptFunction It's silly to generate new bytecode every time you call a function. Let's just cache the code instead. :^)
2021-06-07 15:19:48 +02:00
}
LibJS: Move bytecode debug spam behind JS_BYTECODE_DEBUG :^)
2021-06-07 15:17:37 +02:00
}
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
auto result = bytecode_interpreter->run(*m_bytecode_executable);
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11 03:38:05 +04:30
if (m_kind != FunctionKind::Generator)
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
return result;
LibJS: Rename CallFrame => ExecutionContext This struct represents what the ECMAScript specification calls an "execution context" so let's use the same terminology. :^)
2021-06-24 19:17:45 +02:00
return GeneratorObject::create(global_object(), result, this, vm.running_execution_context().lexical_environment, bytecode_interpreter->snapshot_frame());
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
} else {
LibJS: Use an enum class instead of 'bool is_generator' This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11 03:38:05 +04:30
VERIFY(m_kind != FunctionKind::Generator);
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
OwnPtr<Interpreter> local_interpreter;
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
Interpreter* ast_interpreter = vm.interpreter_if_exists();
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
if (!ast_interpreter) {
LibJS: Change Interpreter::create_with_existing_{global_object => realm} We need both a GlobalObject and Realm now, but can get the former from the latter (once initialized). This also fixes JS execution in LibWeb, as we failed to set the Realm of the newly created Interpreter in this function.
2021-09-12 12:33:54 +01:00
local_interpreter = Interpreter::create_with_existing_realm(*realm());
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
ast_interpreter = local_interpreter.ptr();
}
LibJS: Make Function::call() not require an Interpreter& This makes a difference inside ScriptFunction::call(), which will now instantiate a temporary Interpreter if one is not attached to the VM.
2020-09-27 17:24:14 +02:00
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
VM::InterpreterExecutionScope scope(*ast_interpreter);
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
TRY_OR_DISCARD(function_declaration_instantiation(ast_interpreter));
LibJS: Move "strict mode" state to the call stack Each call frame now knows whether it's executing in strict mode. It's no longer necessary to access the scope stack to find this mode.
2020-10-04 13:54:44 +02:00
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
return m_ecmascript_code->execute(*ast_interpreter, global_object());
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: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
Value ECMAScriptFunctionObject::call()
LibJS: Throw TypeError when calling class constructor without 'new'
2020-11-11 21:37:40 +00:00
{
if (m_is_class_constructor) {
vm().throw_exception<TypeError>(global_object(), ErrorType::ClassConstructorWithoutNew, m_name);
return {};
}
return execute_function_body();
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
Value ECMAScriptFunctionObject::construct(FunctionObject&)
LibJS: Implement constructor/non-constructor function calls This adds Function::construct() for constructor function calls via `new` keyword. NativeFunction doesn't have constructor behaviour by default, ScriptFunction simply calls call() in construct()
2020-04-01 18:31:24 +01:00
{
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
if (m_is_arrow_function || m_kind == FunctionKind::Generator) {
LibJS: Use String::formatted() for throw_exception() message
2020-10-04 13:55:20 +01:00
vm().throw_exception<TypeError>(global_object(), ErrorType::NotAConstructor, m_name);
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 12:52:32 +02:00
return {};
}
LibJS: Throw TypeError when calling class constructor without 'new'
2020-11-11 21:37:40 +00:00
return execute_function_body();
LibJS: Implement constructor/non-constructor function calls This adds Function::construct() for constructor function calls via `new` keyword. NativeFunction doesn't have constructor behaviour by default, ScriptFunction simply calls call() in construct()
2020-04-01 18:31:24 +01:00
}
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
void ECMAScriptFunctionObject::set_name(const FlyString& name)
LibJS: Add length property to ScriptFunction
2020-04-04 14:34:27 +01:00
{
LibJS: Remove usage of define_native_property in OrdinaryFunctionObject The length & name properties are supposed to be normal data properties.
2021-07-05 18:02:27 +03:00
VERIFY(!name.is_null());
auto& vm = this->vm();
m_name = name;
auto success = define_property_or_throw(vm.names.name, { .value = js_string(vm, m_name), .writable = false, .enumerable = false, .configurable = true });
VERIFY(success);
LibJS: Add length property to ScriptFunction
2020-04-04 14:34:27 +01:00
}
LibJS: Move [[Fields]] to ECMAScriptFunctionObject
2021-09-25 00:01:09 +02:00
// 7.3.31 DefineField ( receiver, fieldRecord ), https://tc39.es/ecma262/#sec-definefield
void ECMAScriptFunctionObject::InstanceField::define_field(VM& vm, Object& receiver) const
{
Value init_value = js_undefined();
if (initializer) {
auto init_value_or_error = vm.call(*initializer, receiver.value_of());
if (init_value_or_error.is_error())
return;
init_value = init_value_or_error.release_value();
}
receiver.create_data_property_or_throw(name, init_value);
}
LibJS: Split Function into subclasses NativeFunction and ScriptFunction Both types of functions are now Function and implement calling via: virtual Value call(Interpreter&, Vector<Value> arguments); This removes the need for CallExpression::execute() to care about which kind of function it's calling. :^)
2020-03-13 10:08:52 +01:00
}
Reference in a new issue Copy permalink