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/Libraries/LibJS/Runtime/ECMAScriptFunctionObject.cpp

932 lines
41 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: Use a Variant instead of two Optionals for ThrowCompletionOr Comes with the usual benefit of saving some space on the stack, as well as making a situation where both or neither Optionals hold a value impossible. The various unwrapping additions are required as we can no longer construct a ThrowCompletionOr<T> from an Optional<T> - rightfully so.
2023-03-01 14:52:31 +00:00
* Copyright (c) 2020-2023, Linus Groh <linusg@serenityos.org>
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
* Copyright (c) 2023-2025, Andreas Kling <andreas@ladybird.org>
LibJS: Allow AsyncBlockStart to accept a SafeFunction This is needed for the implementation of Array.fromAsync
2023-07-16 18:04:01 +12:00
* Copyright (c) 2023, Shannon Booth <shannon@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: 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: Implement async functions as generator functions in BC mode This applies a simple transformation, and adds a simple wrapper that translates the generator interface to the async function interface.
2021-11-11 00:46:07 +03:30
#include <LibJS/Runtime/AsyncFunctionDriverWrapper.h>
LibJS/Bytecode: Implement async generators
2023-07-14 21:57:49 +01:00
#include <LibJS/Runtime/AsyncGenerator.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: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
#include <LibJS/Runtime/ExecutionContext.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: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
#include <LibJS/Runtime/GlobalEnvironment.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: Move PromiseCapability into its own cpp/h file This is not strictly connected to PromiseReaction in any way. Preparation before doing some actual work on it :^)
2022-10-02 10:59:22 +01:00
#include <LibJS/Runtime/PromiseCapability.h>
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
#include <LibJS/Runtime/PromiseConstructor.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+LibWeb: Inline fast path for `Value::to_object()` Adds inline implementation for the most common case when `Value` is already an object. 1.47x improvement on the following benchmark: ```js const o = {}; for (let i = 0; i < 10_000_000; i++) { o.a = 1; o.b = 2; o.c = 3; } ```
2025-09-13 20:50:09 +02:00
#include <LibJS/Runtime/ValueInlines.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 {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_DEFINE_ALLOCATOR(ECMAScriptFunctionObject);
LibJS: Segregate GC-allocated objects by type This patch adds two macros to declare per-type allocators: - JS_DECLARE_ALLOCATOR(TypeName) - JS_DEFINE_ALLOCATOR(TypeName) When used, they add a type-specific CellAllocator that the Heap will delegate allocation requests to. The result of this is that GC objects of the same type always end up within the same HeapBlock, drastically reducing the ability to perform type confusion attacks. It also improves HeapBlock utilization, since each block now has cells sized exactly to the type used within that block. (Previously we only had a handful of block sizes available, and most GC allocations ended up with a large amount of slack in their tails.) There is a small performance hit from this, but I'm sure we can make up for it elsewhere. Note that the old size-based allocators still exist, and we fall back to them for any type that doesn't have its own CellAllocator.
2023-11-19 09:45:05 +01:00
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
GC::Ref<ECMAScriptFunctionObject> ECMAScriptFunctionObject::create(Realm& realm, Utf16FlyString name, ByteString source_text, Statement const& ecmascript_code, NonnullRefPtr<FunctionParameters const> parameters, i32 function_length, Vector<LocalVariable> local_variables_names, Environment* parent_environment, PrivateEnvironment* private_environment, FunctionKind kind, bool is_strict, FunctionParsingInsights parsing_insights, bool is_arrow_function, Variant<PropertyKey, PrivateName, Empty> class_field_initializer_name)
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) {
LibJS: Rename FunctionKind::{Regular => Normal} This is what CreateDynamicFunction calls it.
2022-01-15 00:30:02 +01:00
case FunctionKind::Normal:
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
prototype = realm.intrinsics().function_prototype();
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:
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
prototype = realm.intrinsics().generator_function_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 support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
case FunctionKind::Async:
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
prototype = realm.intrinsics().async_function_prototype();
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
break;
LibJS: Parse async generator functions
2021-11-15 01:53:24 +01:00
case FunctionKind::AsyncGenerator:
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
prototype = realm.intrinsics().async_generator_function_prototype();
LibJS: Parse async generator functions
2021-11-15 01:53:24 +01:00
break;
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
}
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
auto shared_data = adopt_ref(*new SharedFunctionInstanceData(
realm.vm(),
kind,
move(name),
function_length,
*parameters,
ecmascript_code,
source_text,
is_strict,
is_arrow_function,
parsing_insights,
move(local_variables_names)));
shared_data->m_class_field_initializer_name = move(class_field_initializer_name);
return realm.create<ECMAScriptFunctionObject>(
move(shared_data),
parent_environment,
private_environment,
*prototype);
LibJS: Pass prototype to Function constructors
2020-04-17 19:59:32 +02:00
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
GC::Ref<ECMAScriptFunctionObject> ECMAScriptFunctionObject::create(Realm& realm, Utf16FlyString name, Object& prototype, ByteString source_text, Statement const& ecmascript_code, NonnullRefPtr<FunctionParameters const> parameters, i32 function_length, Vector<LocalVariable> local_variables_names, Environment* parent_environment, PrivateEnvironment* private_environment, FunctionKind kind, bool is_strict, FunctionParsingInsights parsing_insights, bool is_arrow_function, Variant<PropertyKey, PrivateName, Empty> class_field_initializer_name)
LibJS: Allow passing prototype to ECMAScriptFunctionObject::create() This should have been the default as it roughly represents the OrdinaryFunctionCreate AO. For now, keep two overloads and continue to guess the required prototype from the function kind in most cases. The prototype needs to be passed in explicitly when it may be derived from user code, such as in the CreateDynamicFunction AO.
2022-01-15 17:18:12 +01:00
{
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
auto shared_data = adopt_ref(*new SharedFunctionInstanceData(
realm.vm(),
kind,
move(name),
function_length,
*parameters,
ecmascript_code,
source_text,
is_strict,
is_arrow_function,
parsing_insights,
move(local_variables_names)));
shared_data->m_class_field_initializer_name = move(class_field_initializer_name);
return realm.create<ECMAScriptFunctionObject>(
move(shared_data),
parent_environment,
private_environment,
prototype);
LibJS: Allow passing prototype to ECMAScriptFunctionObject::create() This should have been the default as it roughly represents the OrdinaryFunctionCreate AO. For now, keep two overloads and continue to guess the required prototype from the function kind in most cases. The prototype needs to be passed in explicitly when it may be derived from user code, such as in the CreateDynamicFunction AO.
2022-01-15 17:18:12 +01:00
}
LibJS: Add ECMAScriptFunctionObject::create_from_function_node() helper This gives us a shared entry point for every situation where we instantiate a function based on a FunctionNode from the AST.
2025-04-07 21:08:55 +02:00
GC::Ref<ECMAScriptFunctionObject> ECMAScriptFunctionObject::create_from_function_node(
FunctionNode const& function_node,
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
Utf16FlyString name,
LibJS: Add ECMAScriptFunctionObject::create_from_function_node() helper This gives us a shared entry point for every situation where we instantiate a function based on a FunctionNode from the AST.
2025-04-07 21:08:55 +02:00
GC::Ref<Realm> realm,
GC::Ptr<Environment> parent_environment,
GC::Ptr<PrivateEnvironment> private_environment)
{
GC::Ptr<Object> prototype = nullptr;
switch (function_node.kind()) {
case FunctionKind::Normal:
prototype = realm->intrinsics().function_prototype();
break;
case FunctionKind::Generator:
prototype = realm->intrinsics().generator_function_prototype();
break;
case FunctionKind::Async:
prototype = realm->intrinsics().async_function_prototype();
break;
case FunctionKind::AsyncGenerator:
prototype = realm->intrinsics().async_generator_function_prototype();
break;
}
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
RefPtr<SharedFunctionInstanceData> shared_data = function_node.shared_data();
if (!shared_data) {
shared_data = adopt_ref(*new SharedFunctionInstanceData(realm->vm(),
function_node.kind(),
move(name),
function_node.function_length(),
function_node.parameters(),
*function_node.body_ptr(),
function_node.source_text(),
function_node.is_strict_mode(),
function_node.is_arrow_function(),
function_node.parsing_insights(),
function_node.local_variables_names()));
function_node.set_shared_data(shared_data);
}
return realm->create<ECMAScriptFunctionObject>(
shared_data.release_nonnull(),
LibJS: Add ECMAScriptFunctionObject::create_from_function_node() helper This gives us a shared entry point for every situation where we instantiate a function based on a FunctionNode from the AST.
2025-04-07 21:08:55 +02:00
parent_environment,
private_environment,
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
*prototype);
LibJS: Add ECMAScriptFunctionObject::create_from_function_node() helper This gives us a shared entry point for every situation where we instantiate a function based on a FunctionNode from the AST.
2025-04-07 21:08:55 +02:00
}
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
SharedFunctionInstanceData::SharedFunctionInstanceData(
VM& vm,
FunctionKind kind,
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
Utf16FlyString name,
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
i32 function_length,
NonnullRefPtr<FunctionParameters const> formal_parameters,
NonnullRefPtr<Statement const> ecmascript_code,
ByteString source_text,
bool strict,
bool is_arrow_function,
FunctionParsingInsights const& parsing_insights,
LibJS: Preserve information about local variables declaration kind This is required for upcoming change where we want to emit ThrowIfTDZ for assignment expressions only for lexical declarations.
2025-05-05 21:53:19 +03:00
Vector<LocalVariable> local_variables_names)
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
: m_formal_parameters(move(formal_parameters))
, m_ecmascript_code(move(ecmascript_code))
LibJS: Make JS::ECMAScriptFunctionObject smaller by reordering members ...and making heavy use of bitfields.
2022-01-31 13:19:06 +01:00
, m_name(move(name))
LibJS: Pass source text to ECMAScriptFunctionObject::create()
2022-01-18 23:47:11 +00:00
, m_source_text(move(source_text))
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
, m_local_variables_names(move(local_variables_names))
, m_function_length(function_length)
, m_kind(kind)
LibJS: Make JS::ECMAScriptFunctionObject smaller by reordering members ...and making heavy use of bitfields.
2022-01-31 13:19:06 +01:00
, m_strict(strict)
LibJS+LibWeb: Pass function metadata collected in parsing using a struct By using separate struct we can avoid updating AST node and ECMAScriptFunctionObject constructors every time there is a need to add or remove some additional information colllected during parsing.
2024-05-22 11:04:50 +01:00
, m_might_need_arguments_object(parsing_insights.might_need_arguments_object)
, m_contains_direct_call_to_eval(parsing_insights.contains_direct_call_to_eval)
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: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
, m_uses_this(parsing_insights.uses_this)
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
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: Keep parsed function parameters in a shared data structure Instead of making a copy of the Vector<FunctionParameter> from the AST every time we instantiate an ECMAScriptFunctionObject, we now keep the parameters in a ref-counted FunctionParameters object. This reduces memory usage, and also allows us to cache the bytecode executables for default parameter expressions without recompiling them for every instantiation. :^)
2025-03-27 12:59:50 +00:00
m_has_simple_parameter_list = all_of(m_formal_parameters->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;
LibJS: Use Identifier to represent FunctionParameter name Using identifier instead of string allows to store supplemental information about whether it can be represented as local variable.
2023-07-06 17:49:38 +02:00
if (!parameter.binding.template has<NonnullRefPtr<Identifier const>>())
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
return false;
return true;
LibJS: Move has_simple_parameter_list to ECMAScriptFunctionObject
2021-09-25 00:10:09 +02:00
});
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// NOTE: The following steps are from FunctionDeclarationInstantiation that could be executed once
// and then reused in all subsequent function instantiations.
// 2. Let code be func.[[ECMAScriptCode]].
ScopeNode const* scope_body = nullptr;
if (is<ScopeNode>(*m_ecmascript_code))
scope_body = static_cast<ScopeNode const*>(m_ecmascript_code.ptr());
// 3. Let strict be func.[[Strict]].
// 4. Let formals be func.[[FormalParameters]].
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
auto const& formals = *m_formal_parameters;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// 5. Let parameterNames be the BoundNames of formals.
// 6. If parameterNames has any duplicate entries, let hasDuplicates be true. Otherwise, let hasDuplicates be false.
LibJS: Don't reserve space in function environment for parameter locals 3% speed-up on Octane/typescript.js (but basically improves performance on most JS.)
2024-01-21 16:30:25 +01:00
size_t parameters_in_environment = 0;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// NOTE: This loop performs step 5, 6, and 8.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
for (auto const& parameter : formals.parameters()) {
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
if (parameter.default_value)
m_has_parameter_expressions = true;
parameter.binding.visit(
[&](Identifier const& identifier) {
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
if (m_parameter_names.set(identifier.string(), identifier.is_local() ? ParameterIsLocal::Yes : ParameterIsLocal::No) != AK::HashSetResult::InsertedNewEntry)
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
m_has_duplicates = true;
LibJS: Don't reserve space in function environment for parameter locals 3% speed-up on Octane/typescript.js (but basically improves performance on most JS.)
2024-01-21 16:30:25 +01:00
else if (!identifier.is_local())
++parameters_in_environment;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
},
[&](NonnullRefPtr<BindingPattern const> const& pattern) {
if (pattern->contains_expression())
m_has_parameter_expressions = true;
// NOTE: Nothing in the callback throws an exception.
MUST(pattern->for_each_bound_identifier([&](auto& identifier) {
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
if (m_parameter_names.set(identifier.string(), identifier.is_local() ? ParameterIsLocal::Yes : ParameterIsLocal::No) != AK::HashSetResult::InsertedNewEntry)
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
m_has_duplicates = true;
LibJS: Don't reserve space in function environment for parameter locals 3% speed-up on Octane/typescript.js (but basically improves performance on most JS.)
2024-01-21 16:30:25 +01:00
else if (!identifier.is_local())
++parameters_in_environment;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
}));
});
}
// 15. Let argumentsObjectNeeded be true.
m_arguments_object_needed = m_might_need_arguments_object;
// 16. If func.[[ThisMode]] is lexical, then
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (m_this_mode == ThisMode::Lexical) {
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// a. NOTE: Arrow functions never have an arguments object.
// b. Set argumentsObjectNeeded to false.
m_arguments_object_needed = false;
}
// 17. Else if parameterNames contains "arguments", then
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
else if (m_parameter_names.contains(vm.names.arguments.as_string())) {
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// a. Set argumentsObjectNeeded to false.
m_arguments_object_needed = false;
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
HashTable<Utf16FlyString> function_names;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// 18. Else if hasParameterExpressions is false, then
// a. If functionNames contains "arguments" or lexicalNames contains "arguments", then
// i. Set argumentsObjectNeeded to false.
// NOTE: The block below is a combination of step 14 and step 18.
if (scope_body) {
// NOTE: Nothing in the callback throws an exception.
MUST(scope_body->for_each_var_function_declaration_in_reverse_order([&](FunctionDeclaration const& function) {
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
if (function_names.set(function.name()) == AK::HashSetResult::InsertedNewEntry)
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
m_functions_to_initialize.append(function);
}));
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
auto const& arguments_name = vm.names.arguments.as_string();
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
if (!m_has_parameter_expressions && function_names.contains(arguments_name))
m_arguments_object_needed = false;
if (!m_has_parameter_expressions && m_arguments_object_needed) {
// NOTE: Nothing in the callback throws an exception.
MUST(scope_body->for_each_lexically_declared_identifier([&](auto const& identifier) {
if (identifier.string() == arguments_name)
m_arguments_object_needed = false;
}));
}
} else {
m_arguments_object_needed = false;
}
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
size_t* environment_size = nullptr;
size_t parameter_environment_bindings_count = 0;
// 19. If strict is true or hasParameterExpressions is false, then
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (strict || !m_has_parameter_expressions) {
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
// a. NOTE: Only a single Environment Record is needed for the parameters, since calls to eval in strict mode code cannot create new bindings which are visible outside of the eval.
// b. Let env be the LexicalEnvironment of calleeContext
// NOTE: Here we are only interested in the size of the environment.
environment_size = &m_function_environment_bindings_count;
}
// 20. Else,
else {
// a. NOTE: A separate Environment Record is needed to ensure that bindings created by direct eval calls in the formal parameter list are outside the environment where parameters are declared.
// b. Let calleeEnv be the LexicalEnvironment of calleeContext.
// c. Let env be NewDeclarativeEnvironment(calleeEnv).
environment_size = &parameter_environment_bindings_count;
}
LibJS: Don't reserve space in function environment for parameter locals 3% speed-up on Octane/typescript.js (but basically improves performance on most JS.)
2024-01-21 16:30:25 +01:00
*environment_size += parameters_in_environment;
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
HashMap<Utf16FlyString, ParameterIsLocal> parameter_bindings;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
LibJS: Preserve information about local variables declaration kind This is required for upcoming change where we want to emit ThrowIfTDZ for assignment expressions only for lexical declarations.
2025-05-05 21:53:19 +03:00
auto arguments_object_needs_binding = m_arguments_object_needed && !m_local_variables_names.first_matching([](auto const& local) { return local.declaration_kind == LocalVariable::DeclarationKind::ArgumentsObject; }).has_value();
LibJS: Do not count arguments as env binding when local variable is used This is a follow up for 210a5d77dccdbbb53ab3fc705cd0c5bc07586ffc that actually allows to skip function environment allocation.
2024-05-21 14:27:15 +01:00
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// 22. If argumentsObjectNeeded is true, then
if (m_arguments_object_needed) {
// f. Let parameterBindings be the list-concatenation of parameterNames and « "arguments" ».
parameter_bindings = m_parameter_names;
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
parameter_bindings.set(vm.names.arguments.as_string(), ParameterIsLocal::No);
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
LibJS: Do not count arguments as env binding when local variable is used This is a follow up for 210a5d77dccdbbb53ab3fc705cd0c5bc07586ffc that actually allows to skip function environment allocation.
2024-05-21 14:27:15 +01:00
if (arguments_object_needs_binding)
(*environment_size)++;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
} else {
parameter_bindings = m_parameter_names;
// a. Let parameterBindings be parameterNames.
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
HashMap<Utf16FlyString, ParameterIsLocal> instantiated_var_names;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
size_t* var_environment_size = nullptr;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// 27. If hasParameterExpressions is false, then
if (!m_has_parameter_expressions) {
// b. Let instantiatedVarNames be a copy of the List parameterBindings.
instantiated_var_names = parameter_bindings;
if (scope_body) {
// c. For each element n of varNames, do
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
MUST(scope_body->for_each_var_declared_identifier([&](Identifier const& id) {
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// i. If instantiatedVarNames does not contain n, then
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
if (instantiated_var_names.set(id.string(), id.is_local() ? ParameterIsLocal::Yes : ParameterIsLocal::No) == AK::HashSetResult::InsertedNewEntry) {
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// 1. Append n to instantiatedVarNames.
// Following steps will be executed in function_declaration_instantiation:
// 2. Perform ! env.CreateMutableBinding(n, false).
// 3. Perform ! env.InitializeBinding(n, undefined).
m_var_names_to_initialize_binding.append({
.identifier = id,
LibJS: Remove some irrelevant hash lookups in ESFO constructor If we don't have parameter expressions, we don't need to collect metadata about whether instantiated var names collide with parameter names or function names, as these flags are only used in the parameter code path.
2025-03-27 17:07:40 +00:00
// NOTE: We don't have to set parameter_binding or function_name here
// since those are only relevant in the hasParameterExpressions==true path.
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
});
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
if (!id.is_local())
(*environment_size)++;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
}
}));
}
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
// d. Let varEnv be env
var_environment_size = environment_size;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
} else {
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
// a. NOTE: A separate Environment Record is needed to ensure that closures created by expressions in the formal parameter list do not have visibility of declarations in the function body.
// b. Let varEnv be NewDeclarativeEnvironment(env).
// NOTE: Here we are only interested in the size of the environment.
var_environment_size = &m_var_environment_bindings_count;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// 28. Else,
// NOTE: Steps a, b, c and d are executed in function_declaration_instantiation.
// e. For each element n of varNames, do
if (scope_body) {
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
MUST(scope_body->for_each_var_declared_identifier([&](Identifier const& id) {
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
auto const& name = id.string();
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
// 1. Append n to instantiatedVarNames.
// Following steps will be executed in function_declaration_instantiation:
// 2. Perform ! env.CreateMutableBinding(n, false).
// 3. Perform ! env.InitializeBinding(n, undefined).
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
if (instantiated_var_names.set(name, id.is_local() ? ParameterIsLocal::Yes : ParameterIsLocal::No) == AK::HashSetResult::InsertedNewEntry) {
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
m_var_names_to_initialize_binding.append({
.identifier = id,
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
.parameter_binding = parameter_bindings.contains(name),
.function_name = function_names.contains(name),
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
});
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
if (!id.is_local())
(*var_environment_size)++;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
}
}));
}
}
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
// 29. NOTE: Annex B.3.2.1 adds additional steps at this point.
// B.3.2.1 Changes to FunctionDeclarationInstantiation, https://tc39.es/ecma262/#sec-web-compat-functiondeclarationinstantiation
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
if (!m_strict && scope_body) {
MUST(scope_body->for_each_function_hoistable_with_annexB_extension([&](FunctionDeclaration& function_declaration) {
LibJS: Port the Identifier AST (and related) nodes to UTF-16 This eliminates quite a lot of UTF-8 / UTF-16 churn.
2025-08-06 11:12:58 -04:00
auto function_name = function_declaration.name();
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
if (parameter_bindings.contains(function_name))
return;
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (!instantiated_var_names.contains(function_name) && function_name != vm.names.arguments.as_string()) {
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
m_function_names_to_initialize_binding.append(function_name);
LibJS: Don't add uncaptured parameter bindings to environment For parameters that exist strictly as "locals", we can save time and space by not adding them to the function environment. This is a speed-up across the board on basically every test. For example, ~11% on Octane/typescript.js :^)
2024-01-21 16:06:18 +01:00
instantiated_var_names.set(function_name, ParameterIsLocal::No);
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
(*var_environment_size)++;
LibJS: Run reusable steps of FunctionDeclarationInstantiation only once This change moves steps that can be executed only once and then reused in subsequent function instantiations from `function_declaration_instantiation` to the ECMAScriptFunctionObject: - Determine if there are any parameters with duplicate names. - Determine if there are any parameters with expressions. - Determine if an arguments object needs to be created. - Create a list of distinct function names for which bindings need to be created. - Create a list of distinct variable names for which bindings need to be created. This change makes React-Redux-TodoMVC test in Speedometer run 10% faster :)
2023-09-19 02:46:28 +02:00
}
function_declaration.set_should_do_additional_annexB_steps();
}));
}
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
size_t* lex_environment_size = nullptr;
// 30. If strict is false, then
if (!m_strict) {
LibJS: Skip some declarative env allocations in function instantiation If all lexical declaration use local variables then there is no need to allocate declarative environment. With this change we skip ~3x more environment allocations on Github.
2024-05-04 22:36:56 +02:00
bool can_elide_declarative_environment = !m_contains_direct_call_to_eval && (!scope_body || !scope_body->has_non_local_lexical_declarations());
LibJS: Pre-calculate the number of bindings for function environments We can use `ensure_capacity` for binding vectors if we know their sizes in advance. This ensures that binding vectors aren't reallocated during the `function_declaration_instantiation` execution. With this change, `try_grow_capacity()` and `shrink_to_fit()` are no longer visible in the `function_declaration_instantiation()` profiles when running React-Redux-TodoMVC from Speedometer.
2023-09-20 01:32:07 +02:00
if (can_elide_declarative_environment) {
lex_environment_size = var_environment_size;
} else {
// a. Let lexEnv be NewDeclarativeEnvironment(varEnv).
lex_environment_size = &m_lex_environment_bindings_count;
}
} else {
// a. let lexEnv be varEnv.
// NOTE: Here we are only interested in the size of the environment.
lex_environment_size = var_environment_size;
}
if (scope_body) {
MUST(scope_body->for_each_lexically_declared_identifier([&](auto const& id) {
if (!id.is_local())
(*lex_environment_size)++;
}));
}
LibWeb+LibJS: Skip function environment allocation if possible If a function has the following properties: - uses only local variables and registers - does not use `this` - does not use `new.target` - does not use `super` - does not use direct eval() calls then it is possible to entirely skip function environment allocation because it will never be used This change adds gathering of information whether a function needs to access `this` from environment and updates `prepare_for_ordinary_call()` to skip allocation when possible. For now, this optimisation is too aggressively blocked; e.g. if `this` is used in a function scope, then all functions in outer scopes have to allocate an environment. It could be improved in the future, although this implementation already allows skipping >80% of environment allocations on Discord, GitHub and Twitter.
2024-05-03 22:54:12 +02:00
LibJS+LibWeb: Pass function metadata collected in parsing using a struct By using separate struct we can avoid updating AST node and ECMAScriptFunctionObject constructors every time there is a need to add or remove some additional information colllected during parsing.
2024-05-22 11:04:50 +01:00
m_function_environment_needed = arguments_object_needs_binding || m_function_environment_bindings_count > 0 || m_var_environment_bindings_count > 0 || m_lex_environment_bindings_count > 0 || parsing_insights.uses_this_from_environment || m_contains_direct_call_to_eval;
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
}
ECMAScriptFunctionObject::ECMAScriptFunctionObject(
NonnullRefPtr<SharedFunctionInstanceData> shared_data,
Environment* parent_environment,
PrivateEnvironment* private_environment,
Object& prototype)
: FunctionObject(prototype)
, m_shared_data(move(shared_data))
, m_environment(parent_environment)
, m_private_environment(private_environment)
{
if (!is_arrow_function() && kind() == FunctionKind::Normal)
LibJS: Simplify ECMAScriptFunctionObject.[[Realm]] slot handling Our engine already keeps track of the home realm for all objects. This is stored in Shape::realm(). We can use that instead of having a dedicated member in ESFO for the same pointer. Since there's always a home realm these days, we can also remove some outdated fallback code from the days when having a realm was not guaranteed due to LibWeb shenanigans.
2025-04-11 18:55:01 +02:00
unsafe_set_shape(realm()->intrinsics().normal_function_shape());
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
// 15. Set F.[[ScriptOrModule]] to GetActiveScriptOrModule().
m_script_or_module = vm().get_active_script_or_module();
LibJS: Split more native object constructors into construct/initialize
2020-06-20 17:11:11 +02:00
}
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 08:41:28 +02:00
void ECMAScriptFunctionObject::initialize(Realm& realm)
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: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 08:41:28 +02:00
Base::initialize(realm);
LibJS: Add comment clarifying the order of function properties
2021-10-15 15:05:02 +02:00
// Note: The ordering of these properties must be: length, name, prototype which is the order
// they are defined in the spec: https://tc39.es/ecma262/#sec-function-instances .
// This is observable through something like: https://tc39.es/ecma262/#sec-ordinaryownpropertykeys
// which must give the properties in chronological order which in this case is the order they
// are defined in the spec.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
m_name_string = PrimitiveString::create(vm, name());
LibJS: Make ExecutionContext::function_name a GCPtr<PrimitiveString> This required setting things up so that all function objects can plop a PrimitiveString there instead of an AK string. This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:38:19 +01:00
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (!is_arrow_function() && kind() == FunctionKind::Normal) {
put_direct(realm.intrinsics().normal_function_length_offset(), Value(function_length()));
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
put_direct(realm.intrinsics().normal_function_name_offset(), m_name_string);
auto prototype = Object::create_with_premade_shape(realm.intrinsics().normal_function_prototype_shape());
prototype->put_direct(realm.intrinsics().normal_function_prototype_constructor_offset(), this);
put_direct(realm.intrinsics().normal_function_prototype_offset(), prototype);
} else {
LibJS: Make `internal_define_own_property()` save added property offset ...in `PropertyDescriptor`. This is required for the upcoming change that needs to know offset of newly added properties to set up inline caching.
2025-09-15 16:43:27 +02:00
PropertyDescriptor length_descriptor { .value = Value(function_length()), .writable = false, .enumerable = false, .configurable = true };
MUST(define_property_or_throw(vm.names.length, length_descriptor));
PropertyDescriptor name_descriptor { .value = m_name_string, .writable = false, .enumerable = false, .configurable = true };
MUST(define_property_or_throw(vm.names.name, name_descriptor));
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (!is_arrow_function()) {
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
Object* prototype = nullptr;
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
switch (kind()) {
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
case FunctionKind::Normal:
VERIFY_NOT_REACHED();
break;
case FunctionKind::Generator:
// prototype is "g1.prototype" in figure-2 (https://tc39.es/ecma262/img/figure-2.png)
prototype = Object::create_prototype(realm, realm.intrinsics().generator_function_prototype_prototype());
break;
case FunctionKind::Async:
break;
case FunctionKind::AsyncGenerator:
prototype = Object::create_prototype(realm, realm.intrinsics().async_generator_function_prototype_prototype());
break;
}
// 27.7.4 AsyncFunction Instances, https://tc39.es/ecma262/#sec-async-function-instances
// AsyncFunction instances do not have a prototype property as they are not constructible.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (kind() != FunctionKind::Async)
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
define_direct_property(vm.names.prototype, prototype, Attribute::Writable);
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
}
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: 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: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
ThrowCompletionOr<void> ECMAScriptFunctionObject::get_stack_frame_size(size_t& registers_and_constants_and_locals_count, size_t& argument_count)
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
{
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
if (!m_bytecode_executable) {
if (!ecmascript_code().bytecode_executable()) {
if (is_module_wrapper()) {
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
const_cast<Statement&>(ecmascript_code()).set_bytecode_executable(TRY(Bytecode::compile(vm(), ecmascript_code(), kind(), name())));
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
} else {
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
const_cast<Statement&>(ecmascript_code()).set_bytecode_executable(TRY(Bytecode::compile(vm(), *this)));
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
}
}
m_bytecode_executable = ecmascript_code().bytecode_executable();
}
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
registers_and_constants_and_locals_count = m_bytecode_executable->number_of_registers + m_bytecode_executable->constants.size() + m_bytecode_executable->local_variable_names.size();
argument_count = max(argument_count, formal_parameters().size());
return {};
}
LibJS+LibWeb: Calculate count of regs+consts+locals before EC allocation This is a preparation step before joining arguments vector into vector of registers+constants+locals.
2025-04-22 21:49:41 +02:00
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
// 10.2.1 [[Call]] ( thisArgument, argumentsList ), https://tc39.es/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist
LibJS: Put FLATTEN on ECMAScriptFunctionObject.[[Call]] This makes function calls ~5% faster in micro-benchmarks on my MBP. Basically free money on the table. Let's take it!
2025-04-28 01:54:11 +02:00
FLATTEN ThrowCompletionOr<Value> ECMAScriptFunctionObject::internal_call(ExecutionContext& callee_context, Value this_argument)
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
{
auto& vm = this->vm();
LibJS: Demote some overly paranoid VERIFY()s in ESFO [[Call]] flow
2025-04-28 01:53:44 +02:00
ASSERT(m_bytecode_executable);
LibJS: Let invokers (callers) of [[Call]] allocate ExecutionContext Instead of letting every [[Call]] implementation allocate an ExecutionContext, we now make that a responsibility of the caller. The main point of this exercise is to allow the Call instruction to write function arguments directly into the callee ExecutionContext instead of copying them later. This makes function calls significantly faster: - 10-20% faster on micro-benchmarks (depending on argument count) - 4% speedup on Kraken - 2% speedup on Octane - 5% speedup on JetStream
2025-04-27 11:53:11 +02:00
// 1. Let callerContext be the running execution context.
// NOTE: No-op, kept by the VM in its execution context stack.
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 2. Let calleeContext be PrepareForOrdinaryCall(F, undefined).
LibJS: Skip stack overflow check in ESFO::prepare_for_ordinary_call() We already do a stack overflow check when entering run_bytecode(), which is the first thing that happens when we actually invoke the ESFO executable.
2025-04-28 21:12:10 +02:00
prepare_for_ordinary_call(vm, callee_context, nullptr);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 3. Assert: calleeContext is now the running execution context.
LibJS: Demote some overly paranoid VERIFY()s in ESFO [[Call]] flow
2025-04-28 01:53:44 +02:00
ASSERT(&vm.running_execution_context() == &callee_context);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 4. If F.[[IsClassConstructor]] is true, then
LibJS: Mark ESFO path for [[Call]] on a class constructor [[unlikely]] This is an exception path that's not supposed to be called normally, so let's mark it unlikely.
2025-04-28 02:04:54 +02:00
if (is_class_constructor()) [[unlikely]] {
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// a. Let error be a newly created TypeError object.
// b. NOTE: error is created in calleeContext with F's associated Realm Record.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
auto throw_completion = vm.throw_completion<TypeError>(ErrorType::ClassConstructorWithoutNew, name());
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// c. Remove calleeContext from the execution context stack and restore callerContext as the running execution context.
vm.pop_execution_context();
// d. Return ThrowCompletion(error).
return throw_completion;
}
// 5. Perform OrdinaryCallBindThis(F, calleeContext, thisArgument).
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (uses_this())
LibJS: Pass VM& to ECMAScriptFunctionObject [[Call]] helpers This avoids fetching the VM from the Cell::private_data() repeatedly.
2025-04-28 01:37:16 +02:00
ordinary_call_bind_this(vm, callee_context, this_argument);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 6. Let result be Completion(OrdinaryCallEvaluateBody(F, argumentsList)).
LibJS: Pass VM& to ECMAScriptFunctionObject [[Call]] helpers This avoids fetching the VM from the Cell::private_data() repeatedly.
2025-04-28 01:37:16 +02:00
auto result = ordinary_call_evaluate_body(vm);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 7. Remove calleeContext from the execution context stack and restore callerContext as the running execution context.
vm.pop_execution_context();
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 8. If result.[[Type]] is return, return result.[[Value]].
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 9. Assert: result is a throw completion.
// 10. Return ? result.
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
return result;
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
}
// 10.2.2 [[Construct]] ( argumentsList, newTarget ), https://tc39.es/ecma262/#sec-ecmascript-function-objects-construct-argumentslist-newtarget
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
ThrowCompletionOr<GC::Ref<Object>> ECMAScriptFunctionObject::internal_construct(ExecutionContext& callee_context, FunctionObject& new_target)
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
{
auto& vm = this->vm();
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
ASSERT(m_bytecode_executable);
LibJS: Fix UAF in ECMAScriptFunctionObject::internal_construct Currently, we create `this_argument` with `ordinary_create_from_constructor`, then we use `arguments_list` to build the callee_context. The issue is we don't properly model the side-effects of `ordinary_create_from_constructor`, if `new_target` is a proxy object then when we `get` the prototype, arbitrary javascript can run. This javascript could perform a function call with enough arguments to reallocate the interpreters m_argument_values_buffer vector. This is dangerous and leads to a use-after-free, as our stack frame maintains a pointer to m_argument_values_buffer (`arguments_list`).
2025-03-18 00:13:20 +13:00
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 1. Let callerContext be the running execution context.
// NOTE: No-op, kept by the VM in its execution context stack.
// 2. Let kind be F.[[ConstructorKind]].
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
auto kind = constructor_kind();
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Object> this_argument;
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 3. If kind is base, then
if (kind == ConstructorKind::Base) {
// a. Let thisArgument be ? OrdinaryCreateFromConstructor(newTarget, "%Object.prototype%").
LibJS: Remove Object(Object& prototype) footgun This constructor was easily confused with a copy constructor, and it was possible to accidentally copy-construct Objects in at least one way that we dicovered (via generic ThrowCompletionOr construction). This patch adds a mandatory ConstructWithPrototypeTag parameter to the constructor to disambiguate it.
2022-12-14 12:17:58 +01:00
this_argument = TRY(ordinary_create_from_constructor<Object>(vm, new_target, &Intrinsics::object_prototype, ConstructWithPrototypeTag::Tag));
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
}
// 4. Let calleeContext be PrepareForOrdinaryCall(F, newTarget).
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
prepare_for_ordinary_call(vm, callee_context, &new_target);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 5. Assert: calleeContext is now the running execution context.
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
VERIFY(&vm.running_execution_context() == &callee_context);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 6. If kind is base, then
if (kind == ConstructorKind::Base) {
// a. Perform OrdinaryCallBindThis(F, calleeContext, thisArgument).
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (uses_this())
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
ordinary_call_bind_this(vm, callee_context, this_argument);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// b. Let initializeResult be Completion(InitializeInstanceElements(thisArgument, F)).
LibJS: Move initialize_instance_elements() from VM to Object This makes more sense as an Object method rather than living within the VM class for no good reason. Most of the other 7.3.xx AOs already work the same way. Also add spec comments while we're here.
2022-12-07 00:22:23 +00:00
auto initialize_result = this_argument->initialize_instance_elements(*this);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// c. If initializeResult is an abrupt completion, then
if (initialize_result.is_throw_completion()) {
// i. Remove calleeContext from the execution context stack and restore callerContext as the running execution context.
vm.pop_execution_context();
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// ii. Return ? initializeResult.
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
return initialize_result.throw_completion();
}
}
// 7. Let constructorEnv be the LexicalEnvironment of calleeContext.
LibJS: Allocate Call{Construct,DirectEval,Builtin) contexts up front We already do this for normal Call contexts, so this is just continuing to propagate the same pattern to other instructions. Fixes #6026
2025-08-30 10:36:32 +02:00
auto constructor_env = callee_context.lexical_environment;
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 8. Let result be Completion(OrdinaryCallEvaluateBody(F, argumentsList)).
LibJS: Pass VM& to ECMAScriptFunctionObject [[Call]] helpers This avoids fetching the VM from the Cell::private_data() repeatedly.
2025-04-28 01:37:16 +02:00
auto result = ordinary_call_evaluate_body(vm);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 9. Remove calleeContext from the execution context stack and restore callerContext as the running execution context.
vm.pop_execution_context();
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 10. If result is a throw completion, then
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
if (result.is_error()) {
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// a. Return ? result.
return result.release_error();
}
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 11. Assert: result is a return completion.
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
// NOTE: We already checked !is_error() above.
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 12. If Type(result.[[Value]]) is Object, return result.[[Value]].
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
if (result.value().is_object())
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
return GC::Ref<Object> { const_cast<Object&>(result.value().as_object()) };
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 13. If kind is base, return thisArgument.
if (kind == ConstructorKind::Base)
return *this_argument;
// 14. If result.[[Value]] is not undefined, throw a TypeError exception.
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
if (!result.value().is_undefined())
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
return vm.throw_completion<TypeError>(ErrorType::DerivedConstructorReturningInvalidValue);
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 15. Let thisBinding be ? constructorEnv.GetThisBinding().
LibJS: Replace GlobalObject with VM in Environment AOs [Part 5/19]
2022-08-21 15:12:43 +01:00
auto this_binding = TRY(constructor_env->get_this_binding(vm));
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 16. Assert: Type(thisBinding) is Object.
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
VERIFY(this_binding.is_object());
LibJS: Adopt editorial fix of return types of algorithms returning empty See: https://github.com/tc39/ecma262/commit/35af90949
2025-01-02 02:16:33 +13:00
// 17. Return thisBinding.
LibJS: Convert FunctionObject::internal_construct() to NonnullGCPtr
2022-12-14 18:49:48 +00:00
return this_binding.as_object();
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +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: Mark Function object's private environment during GC
2021-12-08 10:14:36 +01:00
visitor.visit(m_private_environment);
LibJS: Move [[HomeObject]] to ECMAScriptFunctionObject
2021-09-24 23:49:24 +02:00
visitor.visit(m_home_object);
LibJS: Add missing visit of ECMAScriptFunctionObject::m_name_string
2024-04-01 10:33:56 +02:00
visitor.visit(m_name_string);
LibJS: Move [[Fields]] to ECMAScriptFunctionObject
2021-09-25 00:01:09 +02:00
LibJS: Make Bytecode::Executable GC-allocated This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:23:59 +01:00
visitor.visit(m_bytecode_executable);
LibJS: Make class-specific members of ESFO lazily allocated We don't need the [[Fields]] and [[PrivateMethods]] slots for most ESFO instances, so let's reduce their impact on class size! This shrinks ESFO from 200 bytes to 160 bytes, allowing more allocations before we have to collect garbage.
2025-04-08 13:39:07 +02:00
if (m_class_data) {
for (auto& field : m_class_data->fields) {
field.initializer.visit(
[&visitor](GC::Ref<ECMAScriptFunctionObject>& initializer) {
visitor.visit(initializer);
},
[&visitor](Value initializer) {
visitor.visit(initializer);
},
[](Empty) {});
if (auto* property_key_ptr = field.name.get_pointer<PropertyKey>(); property_key_ptr && property_key_ptr->is_symbol())
visitor.visit(property_key_ptr->as_symbol());
}
LibJS: Make Script and Module GC-allocated This ensures that code currently in any active or saved execution stack always stays alive.
2022-09-05 14:31:25 +02:00
LibJS: Make class-specific members of ESFO lazily allocated We don't need the [[Fields]] and [[PrivateMethods]] slots for most ESFO instances, so let's reduce their impact on class size! This shrinks ESFO from 200 bytes to 160 bytes, allowing more allocations before we have to collect garbage.
2025-04-08 13:39:07 +02:00
for (auto& private_element : m_class_data->private_methods)
visitor.visit(private_element.value);
}
LibJS: Don't use Handle<Value> for JS::Object private fields There's no reason to use handles here, we can just mark private element values from objects that store them.
2023-12-09 11:05:25 +01:00
LibJS: Make Script and Module GC-allocated This ensures that code currently in any active or saved execution stack always stays alive.
2022-09-05 14:31:25 +02:00
m_script_or_module.visit(
[](Empty) {},
[&](auto& script_or_module) {
LibWeb/LibJS: Avoid GC visit of raw pointers where possible This is mostly motivated for aesthetics, but also helps avoid some null checks when we have a NonnullGCPtr<T> or in some cases a T&.
2023-11-19 16:18:00 +13:00
visitor.visit(script_or_module);
LibJS: Make Script and Module GC-allocated This ensures that code currently in any active or saved execution stack always stays alive.
2022-09-05 14:31:25 +02:00
});
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: Implement and use the MakeMethod AO Two direct uses of the set_home_object() setter remain, we should fix those up and remove it eventually.
2021-12-29 10:33:46 +01:00
// 10.2.7 MakeMethod ( F, homeObject ), https://tc39.es/ecma262/#sec-makemethod
void ECMAScriptFunctionObject::make_method(Object& home_object)
{
// 1. Set F.[[HomeObject]] to homeObject.
m_home_object = &home_object;
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 2. Return unused.
LibJS: Implement and use the MakeMethod AO Two direct uses of the set_home_object() setter remain, we should fix those up and remove it eventually.
2021-12-29 10:33:46 +01:00
}
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
// 10.2.1.1 PrepareForOrdinaryCall ( F, newTarget ), https://tc39.es/ecma262/#sec-prepareforordinarycall
LibJS: Skip stack overflow check in ESFO::prepare_for_ordinary_call() We already do a stack overflow check when entering run_bytecode(), which is the first thing that happens when we actually invoke the ESFO executable.
2025-04-28 21:12:10 +02:00
void ECMAScriptFunctionObject::prepare_for_ordinary_call(VM& vm, ExecutionContext& callee_context, Object* new_target)
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
{
// Non-standard
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
callee_context.is_strict_mode = is_strict_mode();
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
// 1. Let callerContext be the running execution context.
// 2. Let calleeContext be a new ECMAScript code execution context.
// 3. Set the Function of calleeContext to F.
callee_context.function = this;
LibJS: Make ExecutionContext::function_name a GCPtr<PrimitiveString> This required setting things up so that all function objects can plop a PrimitiveString there instead of an AK string. This is a step towards making ExecutionContext easier to allocate.
2023-11-27 13:38:19 +01:00
callee_context.function_name = m_name_string;
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
// 4. Let calleeRealm be F.[[Realm]].
// 5. Set the Realm of calleeContext to calleeRealm.
LibJS: Simplify ECMAScriptFunctionObject.[[Realm]] slot handling Our engine already keeps track of the home realm for all objects. This is stored in Shape::realm(). We can use that instead of having a dedicated member in ESFO for the same pointer. Since there's always a home realm these days, we can also remove some outdated fallback code from the days when having a realm was not guaranteed due to LibWeb shenanigans.
2025-04-11 18:55:01 +02:00
callee_context.realm = realm();
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
// 6. Set the ScriptOrModule of calleeContext to F.[[ScriptOrModule]].
LibJS: Add ScriptOrModule to execution context and track it everywhere
2022-01-17 14:48:22 +01:00
callee_context.script_or_module = m_script_or_module;
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (function_environment_needed()) {
LibWeb+LibJS: Skip function environment allocation if possible If a function has the following properties: - uses only local variables and registers - does not use `this` - does not use `new.target` - does not use `super` - does not use direct eval() calls then it is possible to entirely skip function environment allocation because it will never be used This change adds gathering of information whether a function needs to access `this` from environment and updates `prepare_for_ordinary_call()` to skip allocation when possible. For now, this optimisation is too aggressively blocked; e.g. if `this` is used in a function scope, then all functions in outer scopes have to allocate an environment. It could be improved in the future, although this implementation already allows skipping >80% of environment allocations on Discord, GitHub and Twitter.
2024-05-03 22:54:12 +02:00
// 7. Let localEnv be NewFunctionEnvironment(F, newTarget).
auto local_environment = new_function_environment(*this, new_target);
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
local_environment->ensure_capacity(shared_data().m_function_environment_bindings_count);
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
LibWeb+LibJS: Skip function environment allocation if possible If a function has the following properties: - uses only local variables and registers - does not use `this` - does not use `new.target` - does not use `super` - does not use direct eval() calls then it is possible to entirely skip function environment allocation because it will never be used This change adds gathering of information whether a function needs to access `this` from environment and updates `prepare_for_ordinary_call()` to skip allocation when possible. For now, this optimisation is too aggressively blocked; e.g. if `this` is used in a function scope, then all functions in outer scopes have to allocate an environment. It could be improved in the future, although this implementation already allows skipping >80% of environment allocations on Discord, GitHub and Twitter.
2024-05-03 22:54:12 +02:00
// 8. Set the LexicalEnvironment of calleeContext to localEnv.
callee_context.lexical_environment = local_environment;
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
LibWeb+LibJS: Skip function environment allocation if possible If a function has the following properties: - uses only local variables and registers - does not use `this` - does not use `new.target` - does not use `super` - does not use direct eval() calls then it is possible to entirely skip function environment allocation because it will never be used This change adds gathering of information whether a function needs to access `this` from environment and updates `prepare_for_ordinary_call()` to skip allocation when possible. For now, this optimisation is too aggressively blocked; e.g. if `this` is used in a function scope, then all functions in outer scopes have to allocate an environment. It could be improved in the future, although this implementation already allows skipping >80% of environment allocations on Discord, GitHub and Twitter.
2024-05-03 22:54:12 +02:00
// 9. Set the VariableEnvironment of calleeContext to localEnv.
callee_context.variable_environment = local_environment;
} else {
callee_context.lexical_environment = environment();
callee_context.variable_environment = environment();
}
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
// 10. Set the PrivateEnvironment of calleeContext to F.[[PrivateEnvironment]].
LibJS: Add PrivateEnvironment
2021-10-11 20:29:31 +02:00
callee_context.private_environment = m_private_environment;
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
// 11. If callerContext is not already suspended, suspend callerContext.
// 12. Push calleeContext onto the execution context stack; calleeContext is now the running execution context.
LibJS: Skip stack overflow check in ESFO::prepare_for_ordinary_call() We already do a stack overflow check when entering run_bytecode(), which is the first thing that happens when we actually invoke the ESFO executable.
2025-04-28 21:12:10 +02:00
// NOTE: We don't check for stack overflow here. The bytecode interpreter will do it anyway
// when entering the function we're about to call.
vm.push_execution_context(callee_context);
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
// 13. NOTE: Any exception objects produced after this point are associated with calleeRealm.
LibJS: Move additional notes to spec comments onto their own line Having all spec comments verbatim on their own line with no additions made by us will make it easier to automate comparing said comments to their current spec counterparts.
2022-04-11 21:32:37 +01:00
// 14. Return calleeContext.
// NOTE: See the comment after step 2 above about how contexts are allocated on the C++ stack.
LibJS: Move prepare_for_ordinary_call() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:14:22 +01:00
}
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
// 10.2.1.2 OrdinaryCallBindThis ( F, calleeContext, thisArgument ), https://tc39.es/ecma262/#sec-ordinarycallbindthis
LibJS: Pass VM& to ECMAScriptFunctionObject [[Call]] helpers This avoids fetching the VM from the Cell::private_data() repeatedly.
2025-04-28 01:37:16 +02:00
void ECMAScriptFunctionObject::ordinary_call_bind_this(VM& vm, ExecutionContext& callee_context, Value this_argument)
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
{
// 1. Let thisMode be F.[[ThisMode]].
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// If thisMode is lexical, return unused.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (this_mode() == ThisMode::Lexical)
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
return;
// 3. Let calleeRealm be F.[[Realm]].
LibJS: Simplify ECMAScriptFunctionObject.[[Realm]] slot handling Our engine already keeps track of the home realm for all objects. This is stored in Shape::realm(). We can use that instead of having a dedicated member in ESFO for the same pointer. Since there's always a home realm these days, we can also remove some outdated fallback code from the days when having a realm was not guaranteed due to LibWeb shenanigans.
2025-04-11 18:55:01 +02:00
auto callee_realm = realm();
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
// 4. Let localEnv be the LexicalEnvironment of calleeContext.
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
auto local_env = callee_context.lexical_environment;
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
Value this_value;
// 5. If thisMode is strict, let thisValue be thisArgument.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (this_mode() == ThisMode::Strict) {
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
this_value = this_argument;
}
// 6. Else,
else {
// a. If thisArgument is undefined or null, then
if (this_argument.is_nullish()) {
// i. Let globalEnv be calleeRealm.[[GlobalEnv]].
// ii. Assert: globalEnv is a global Environment Record.
auto& global_env = callee_realm->global_environment();
// iii. Let thisValue be globalEnv.[[GlobalThisValue]].
this_value = &global_env.global_this_value();
}
// b. Else,
else {
// i. Let thisValue be ! ToObject(thisArgument).
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
this_value = MUST(this_argument.to_object(vm));
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
// ii. NOTE: ToObject produces wrapper objects using calleeRealm.
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
VERIFY(vm.current_realm() == callee_realm);
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
}
}
// 7. Assert: localEnv is a function Environment Record.
// 8. Assert: The next step never returns an abrupt completion because localEnv.[[ThisBindingStatus]] is not initialized.
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 9. Perform ! localEnv.BindThisValue(thisValue).
LibJS: Get `this` from execution context for non-arrow functions Allows to skip function environment allocation for non-arrow functions if the only reason it is needed is to hold `this` binding. The parser is changed to do following: - If a function is an arrow function and uses `this` then all functions in a scope chain are marked to allocate function environment for `this` binding. - If a function uses `new.target` then all functions in a scope chain are marked to allocate function environment. `ordinary_call_bind_this()` is changed to put `this` value in execution context when function environment allocation is skipped. 35% improvement in Octane/typescript.js 50% improvement in Octane/deltablue.js 19% improvement in Octane/raytrace.js
2024-05-21 16:51:21 +01:00
callee_context.this_value = this_value;
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (function_environment_needed())
AK+Everywhere: Rename `verify_cast` to `as` Follow-up to fc20e61e7249006247b43f84a3189d5a37fa103e.
2025-01-21 09:12:05 -05:00
MUST(as<FunctionEnvironment>(*local_env).bind_this_value(vm, this_value));
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 10. Return unused.
LibJS: Move ordinary_call_bind_this() to ECMAScriptFunctionObject Now that it only needs to deal with ECMAScriptFunctionObject via internal_call() / internal_construct(), we can: - Remove the generic FunctionObject parameter - Move it from the VM to ECMAScriptFunctionObject - Make it private
2021-10-08 21:15:53 +01:00
}
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
// 27.7.5.1 AsyncFunctionStart ( promiseCapability, asyncFunctionBody ), https://tc39.es/ecma262/#sec-async-functions-abstract-operations-async-function-start
LibJS: Make AsyncFunctionStart and AsyncBlockStart templates This will allow implementing a version of these functions that accepts a JS::SafeFunction, which is needed for the implementation of Array.fromAsync.
2023-07-16 17:54:26 +12:00
template<typename T>
void async_function_start(VM& vm, PromiseCapability const& promise_capability, T const& async_function_body)
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
{
// 1. Let runningContext be the running execution context.
auto& running_context = vm.running_execution_context();
// 2. Let asyncContext be a copy of runningContext.
auto async_context = running_context.copy();
// 3. NOTE: Copying the execution state is required for AsyncBlockStart to resume its execution. It is ill-defined to resume a currently executing context.
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 4. Perform AsyncBlockStart(promiseCapability, asyncFunctionBody, asyncContext).
LibJS: Always allocate ExecutionContext objects on the malloc heap Instead of allocating these in a mixture of ways, we now always put them on the malloc heap, and keep an intrusive linked list of them that we can iterate for GC marking purposes.
2023-11-27 16:45:45 +01:00
async_block_start(vm, async_function_body, promise_capability, *async_context);
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 5. Return unused.
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
}
// 27.7.5.2 AsyncBlockStart ( promiseCapability, asyncBody, asyncContext ), https://tc39.es/ecma262/#sec-asyncblockstart
LibJS: Make AsyncFunctionStart and AsyncBlockStart templates This will allow implementing a version of these functions that accepts a JS::SafeFunction, which is needed for the implementation of Array.fromAsync.
2023-07-16 17:54:26 +12:00
template<typename T>
void async_block_start(VM& vm, T const& async_body, PromiseCapability const& promise_capability, ExecutionContext& async_context)
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
{
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
auto& realm = *vm.current_realm();
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// 1. Let runningContext be the running execution context.
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
auto& running_context = vm.running_execution_context();
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// 2. Let closure be a new Abstract Closure with no parameters that captures promiseCapability and asyncBody and performs the following steps when called:
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
auto closure = NativeFunction::create(realm, {}, [&async_body, &promise_capability](auto& vm) -> ThrowCompletionOr<Value> {
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
Completion result;
LibJS: Allow AsyncBlockStart to accept a SafeFunction This is needed for the implementation of Array.fromAsync
2023-07-16 18:04:01 +12:00
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// a. Let acAsyncContext be the running execution context.
// b. If asyncBody is a Parse Node, then
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
if constexpr (!IsSame<T, GC::Function<Completion()>>) {
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// i. Let result be Completion(Evaluation of asyncBody).
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
auto maybe_executable = Bytecode::compile(vm, async_body, FunctionKind::Async, "AsyncBlockStart"_utf16_fly_string);
LibJS: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
if (maybe_executable.is_error())
result = maybe_executable.release_error();
else
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
result = vm.bytecode_interpreter().run_executable(*maybe_executable.value(), {}).value;
LibJS: Allow AsyncBlockStart to accept a SafeFunction This is needed for the implementation of Array.fromAsync
2023-07-16 18:04:01 +12:00
}
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// c. Else,
LibJS: Allow AsyncBlockStart to accept a SafeFunction This is needed for the implementation of Array.fromAsync
2023-07-16 18:04:01 +12:00
else {
// i. Assert: asyncBody is an Abstract Closure with no parameters.
// ii. Let result be asyncBody().
LibJS: Use HeapFunction for async body closure in Array.fromAsync
2024-10-31 06:21:59 +13:00
result = async_body.function()();
LibJS/Bytecode: Simplify Bytecode::Interpreter lifetime model The JS::VM now owns the one Bytecode::Interpreter. We no longer have multiple bytecode interpreters, and there is no concept of a "current" bytecode interpreter. If you ask for VM::bytecode_interpreter_if_exists(), it will return null if we're not running the program in "bytecode enabled" mode. If you ask for VM::bytecode_interpreter(), it will return a bytecode interpreter in all modes. This is used for situations where even the AST interpreter switches to bytecode mode (generators, etc.)
2023-06-22 15:59:18 +02:00
}
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// d. Assert: If we return here, the async function either threw an exception or performed an implicit or explicit return; all awaiting is done.
// e. Remove acAsyncContext from the execution context stack and restore the execution context that is at the top of the execution context stack as the running execution context.
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
vm.pop_execution_context();
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// f. If result is a normal completion, then
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01:00
if (result.type() == Completion::Type::Normal) {
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
// i. Perform ! Call(promiseCapability.[[Resolve]], undefined, « undefined »).
LibJS: Make PromiseCapability GC-allocated A struct with three raw pointers to other GC'd types is a pretty big liability, let's just turn this into a Cell itself. This comes with the additional benefit of being able to capture it in a lambda effortlessly, without having to create handles for individual members.
2022-10-02 12:11:30 +01:00
MUST(call(vm, *promise_capability.resolve(), js_undefined(), js_undefined()));
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
}
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// g. Else if result is a return completion, then
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01:00
else if (result.type() == Completion::Type::Return) {
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
// i. Perform ! Call(promiseCapability.[[Resolve]], undefined, « result.[[Value]] »).
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
MUST(call(vm, *promise_capability.resolve(), js_undefined(), result.value()));
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
}
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// h. Else,
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
else {
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// i. Assert: result is a throw completion.
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01:00
VERIFY(result.type() == Completion::Type::Throw);
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
// ii. Perform ! Call(promiseCapability.[[Reject]], undefined, « result.[[Value]] »).
LibJS: Make Completion.[[Value]] non-optional Instead, just use js_undefined() whenever the [[Value]] field is unused. This avoids a whole bunch of presence checks.
2025-04-04 18:11:45 +02:00
MUST(call(vm, *promise_capability.reject(), js_undefined(), result.value()));
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
}
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// i. Return unused.
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// NOTE: We don't support returning an empty/optional/unused value here.
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
return js_undefined();
});
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// 3. Set the code evaluation state of asyncContext such that when evaluation is resumed for that execution context, closure will be called with no arguments.
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
// 4. Push asyncContext onto the execution context stack; asyncContext is now the running execution context.
LibJS: Replace GlobalObject with VM in remaining AOs [Part 19/19]
2022-08-21 20:38:35 +01:00
auto push_result = vm.push_execution_context(async_context, {});
LibJS: Convert push_execution_context() to ThrowCompletionOr
2021-11-14 12:20:49 +00:00
if (push_result.is_error())
return;
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
// 5. Resume the suspended evaluation of asyncContext. Let result be the value returned by the resumed computation.
LibJS: Make Value() default-construct the undefined value The special empty value (that we use for array holes, Optional<Value> when empty and a few other other placeholder/sentinel tasks) still exists, but you now create one via JS::js_special_empty_value() and check for it with Value::is_special_empty_value(). The main idea here is to make it very unlikely to accidentally create an unexpected special empty value.
2025-04-04 23:16:34 +02:00
auto result = call(vm, *closure, *async_context.this_value);
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
// 6. Assert: When we return here, asyncContext has already been removed from the execution context stack and runningContext is the currently running execution context.
VERIFY(&vm.running_execution_context() == &running_context);
LibJS: Align `AsyncBlockStart` with the latest drafts `AsyncBlockStart` was still doing a `DisposeResources` call as specified in older drafts of the `explicit-resource-management` proposal, but the latest draft no longer does this, and it is causing crashes when combined with the `array-from-async` proposal.
2024-12-02 17:12:08 +01:00
// 7. Assert: result is a normal completion with a value of unused. The possible sources of this value are Await or, if the async function doesn't await anything, step 2.i above.
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
VERIFY(result.has_value() && result.value().is_undefined());
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
// 8. Return unused.
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
}
LibJS: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
template void async_block_start(VM&, NonnullRefPtr<Statement const> const& async_body, PromiseCapability const&, ExecutionContext&);
template void async_function_start(VM&, PromiseCapability const&, NonnullRefPtr<Statement const> const& async_function_body);
LibJS: Make AsyncFunctionStart and AsyncBlockStart templates This will allow implementing a version of these functions that accepts a JS::SafeFunction, which is needed for the implementation of Array.fromAsync.
2023-07-16 17:54:26 +12:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
template void async_block_start(VM&, GC::Function<Completion()> const& async_body, PromiseCapability const&, ExecutionContext&);
template void async_function_start(VM&, PromiseCapability const&, GC::Function<Completion()> const& async_function_body);
LibJS: Allow AsyncBlockStart to accept a SafeFunction This is needed for the implementation of Array.fromAsync
2023-07-16 18:04:01 +12:00
LibJS: Implement [[Call]] and [[Construct]] internal slots properly This patch implements: - Spec compliant [[Call]] and [[Construct]] internal slots, as virtual FunctionObject::internal_{call,construct}(). These effectively replace the old virtual FunctionObject::{call,construct}(), but with several advantages: - Clear and consistent naming, following the object internal methods - Use of completions - internal_construct() returns an Object, and not Value! This has been a source of confusion for a long time, since in the spec there's always an Object returned but the Value return type in LibJS meant that this could not be fully trusted and something could screw you over. - Arguments are passed explicitly in form of a MarkedValueList, allowing manipulation (BoundFunction). We still put them on the execution context as a lot of code depends on it (VM::arguments()), but not from the Call() / Construct() AOs anymore, which now allows for bypassing them and invoking [[Call]] / [[Construct]] directly. Nothing but Call() / Construct() themselves do that at the moment, but future additions to ECMA262 or already existing web specs might. - Spec compliant, standalone Call() and Construct() AOs: currently the closest we have is VM::{call,construct}(), but those try to cater to all the different function object subclasses at once, resulting in a horrible mess and calling AOs with functions they should never be called with; most prominently PrepareForOrdinaryCall and OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject. As a result this also contains an implicit optimization: we no longer need to create a new function environment for NativeFunctions - which, worth mentioning, is what started this whole crusade in the first place :^)
2021-10-08 20:37:21 +01:00
// 10.2.1.4 OrdinaryCallEvaluateBody ( F, argumentsList ), https://tc39.es/ecma262/#sec-ordinarycallevaluatebody
LibJS: Replace the custom unwind mechanism with completions :^) This includes: - Parsing proper LabelledStatements with try_parse_labelled_statement() - Removing LabelableStatement - Implementing the LoopEvaluation semantics via loop_evaluation() in each IterationStatement subclass; and IterationStatement evaluation via {For,ForIn,ForOf,ForAwaitOf,While,DoWhile}Statement::execute() - Updating ReturnStatement, BreakStatement and ContinueStatement to return the appropriate completion types - Basically reimplementing TryStatement and SwitchStatement according to the spec, using completions - Honoring result completion types in AsyncBlockStart and OrdinaryCallEvaluateBody - Removing any uses of the VM unwind mechanism - most importantly, VM::throw_exception() now exclusively sets an exception and no longer triggers any unwinding mechanism. However, we already did a good job updating all of LibWeb and userland applications to not use it, and the few remaining uses elsewhere don't rely on unwinding AFAICT.
2022-01-05 19:11:16 +01:00
// 15.8.4 Runtime Semantics: EvaluateAsyncFunctionBody, https://tc39.es/ecma262/#sec-runtime-semantics-evaluatefunctionbody
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
ThrowCompletionOr<Value> ECMAScriptFunctionObject::ordinary_call_evaluate_body(VM& vm)
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/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 06:44:08 +02:00
auto result_and_frame = vm.bytecode_interpreter().run_executable(*m_bytecode_executable, {});
LibJS: Implement destructuring assignments and function parameters
2021-05-29 16:03:19 +04:30
LibJS: Mark exception path [[unlikely]] in ordinary_call_evaluate_body()
2025-04-28 21:25:02 +02:00
if (result_and_frame.value.is_error()) [[unlikely]] {
LibJS: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
return result_and_frame.value.release_error();
LibJS: Mark exception path [[unlikely]] in ordinary_call_evaluate_body()
2025-04-28 21:25:02 +02:00
}
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: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
auto result = result_and_frame.value.release_value();
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
LibJS: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
// NOTE: Running the bytecode should eventually return a completion.
// Until it does, we assume "return" and include the undefined fallback from the call site.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (kind() == FunctionKind::Normal)
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
return result;
LibJS: Add using declaration support, RAII like operation in js In this patch only top level and not the more complicated for loop using statements are supported. Also, as noted in the latest meeting of tc39 async parts of the spec are not stage 3 thus not included.
2022-12-20 22:09:57 +01:00
LibJS: Defer looking up the realm in ordinary_call_evaluate_body() We don't actually need the realm for normal function calls, so we can avoid looking it up on the EC stack in that case.
2025-04-28 21:25:28 +02:00
auto& realm = *vm.current_realm();
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (kind() == FunctionKind::AsyncGenerator) {
LibJS: Merge CallFrame into ExecutionContext Before this change both ExecutionContext and CallFrame were created before executing function/module/script with a couple exceptions: - executable created for default function argument evaluation has to run in function's execution context. - `execute_ast_node()` where executable compiled for ASTNode has to be executed in running execution context. This change moves all members previously owned by CallFrame into ExecutionContext, and makes two exceptions where an executable that does not have a corresponding execution context saves and restores registers before running. Now, all execution state lives in a single entity, which makes it a bit easier to reason about and opens opportunities for optimizations, such as moving registers and local variables into a single array.
2024-05-01 19:33:49 +02:00
auto async_generator_object = TRY(AsyncGenerator::create(realm, result, this, vm.running_execution_context().copy()));
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
return async_generator_object;
LibJS: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
}
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
LibJS: Merge CallFrame into ExecutionContext Before this change both ExecutionContext and CallFrame were created before executing function/module/script with a couple exceptions: - executable created for default function argument evaluation has to run in function's execution context. - `execute_ast_node()` where executable compiled for ASTNode has to be executed in running execution context. This change moves all members previously owned by CallFrame into ExecutionContext, and makes two exceptions where an executable that does not have a corresponding execution context saves and restores registers before running. Now, all execution state lives in a single entity, which makes it a bit easier to reason about and opens opportunities for optimizations, such as moving registers and local variables into a single array.
2024-05-01 19:33:49 +02:00
auto generator_object = TRY(GeneratorObject::create(realm, result, this, vm.running_execution_context().copy()));
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
LibJS: Rip out the AST interpreter :^) This has been superseded by the bytecode VM, which is both faster and more capable.
2023-08-07 19:59:00 +02:00
// NOTE: Async functions are entirely transformed to generator functions, and wrapped in a custom driver that returns a promise
// See AwaitExpression::generate_bytecode() for the transformation.
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
if (kind() == FunctionKind::Async)
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
return AsyncFunctionDriverWrapper::create(realm, generator_object);
LibJS: Add support for async functions This commit adds support for the most bare bones version of async functions, support for async generator functions, async arrow functions and await expressions are TODO.
2021-11-09 20:39:22 +02:00
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
VERIFY(kind() == FunctionKind::Generator);
LibJS: Make ESFO::ordinary_call_evaluate_body() return TCO<Value> This matches what the caller wants to return and allows us to simplify a bunch of logic around returning a value or throwing.
2025-04-28 02:11:57 +02:00
return generator_object;
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+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
void ECMAScriptFunctionObject::set_name(Utf16FlyString const& 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
auto& vm = this->vm();
LibJS: Move computation out of the ECMAScriptFunctionObject constructor We were doing way too much computation every time an ESFO was instantiated. This was particularly sad, since the results of these computations were identical every time! This patch adds a new SharedFunctionInstanceData object that gets shared between all instances of an ESFO instantiated from some kind of AST FunctionNode. ~5% speedup on Speedometer 2.1 :^)
2025-04-08 00:45:27 +02:00
const_cast<SharedFunctionInstanceData&>(shared_data()).m_name = name;
m_name_string = PrimitiveString::create(vm, name);
LibJS: Make `internal_define_own_property()` save added property offset ...in `PropertyDescriptor`. This is required for the upcoming change that needs to know offset of newly added properties to set up inline caching.
2025-09-15 16:43:27 +02:00
PropertyDescriptor descriptor { .value = m_name_string, .writable = false, .enumerable = false, .configurable = true };
MUST(define_property_or_throw(vm.names.name, descriptor));
LibJS: Add length property to ScriptFunction
2020-04-04 14:34:27 +01:00
}
LibJS: Make class-specific members of ESFO lazily allocated We don't need the [[Fields]] and [[PrivateMethods]] slots for most ESFO instances, so let's reduce their impact on class size! This shrinks ESFO from 200 bytes to 160 bytes, allowing more allocations before we have to collect garbage.
2025-04-08 13:39:07 +02:00
ECMAScriptFunctionObject::ClassData& ECMAScriptFunctionObject::ensure_class_data() const
{
if (!m_class_data)
m_class_data = make<ClassData>();
return *m_class_data;
}
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