2020-03-13 10:08:52 +01:00
/*
2021-05-29 12:38:28 +02:00
* Copyright ( c ) 2020 , Stephan Unverwerth < s . unverwerth @ serenityos . org >
2023-03-01 14:52:31 +00:00
* Copyright ( c ) 2020 - 2023 , Linus Groh < linusg @ serenityos . org >
2023-02-19 22:07:52 +01:00
* Copyright ( c ) 2023 , Andreas Kling < kling @ serenityos . org >
2020-03-13 10:08:52 +01:00
*
2021-04-22 01:24:48 -07:00
* SPDX - License - Identifier : BSD - 2 - Clause
2020-03-13 10:08:52 +01:00
*/
2021-06-07 15:17:37 +02:00
# include <AK/Debug.h>
2020-04-04 14:34:27 +01:00
# include <AK/Function.h>
2020-03-18 11:23:53 +01:00
# include <LibJS/AST.h>
2021-06-09 06:49:58 +04:30
# include <LibJS/Bytecode/BasicBlock.h>
2021-06-05 15:53:36 +02:00
# include <LibJS/Bytecode/Generator.h>
# include <LibJS/Bytecode/Interpreter.h>
2023-06-17 13:16:35 +02:00
# include <LibJS/Bytecode/PassManager.h>
2020-03-13 10:08:52 +01:00
# include <LibJS/Interpreter.h>
2021-09-22 12:44:56 +02:00
# include <LibJS/Runtime/AbstractOperations.h>
2020-05-04 16:05:13 +01:00
# include <LibJS/Runtime/Array.h>
2021-11-11 00:46:07 +03:30
# include <LibJS/Runtime/AsyncFunctionDriverWrapper.h>
2021-09-24 22:40:38 +02:00
# include <LibJS/Runtime/ECMAScriptFunctionObject.h>
2020-04-04 14:34:27 +01:00
# include <LibJS/Runtime/Error.h>
2021-11-09 20:39:22 +02:00
# include <LibJS/Runtime/ExecutionContext.h>
2021-07-01 12:24:46 +02:00
# include <LibJS/Runtime/FunctionEnvironment.h>
2021-06-11 01:38:30 +04:30
# include <LibJS/Runtime/GeneratorObject.h>
2020-04-17 19:59:32 +02:00
# include <LibJS/Runtime/GlobalObject.h>
2021-06-11 01:38:30 +04:30
# include <LibJS/Runtime/NativeFunction.h>
2022-10-02 10:59:22 +01:00
# include <LibJS/Runtime/PromiseCapability.h>
2021-11-09 20:39:22 +02:00
# include <LibJS/Runtime/PromiseConstructor.h>
2020-03-16 14:20:30 +01:00
# include <LibJS/Runtime/Value.h>
2020-03-13 10:08:52 +01:00
namespace JS {
2023-07-05 17:17:16 +02:00
NonnullGCPtr < ECMAScriptFunctionObject > ECMAScriptFunctionObject : : create ( Realm & realm , DeprecatedFlyString name , DeprecatedString source_text , Statement const & ecmascript_code , Vector < FunctionParameter > parameters , i32 m_function_length , Vector < DeprecatedFlyString > local_variables_names , Environment * parent_environment , PrivateEnvironment * private_environment , FunctionKind kind , bool is_strict , bool might_need_arguments_object , bool contains_direct_call_to_eval , bool is_arrow_function , Variant < PropertyKey , PrivateName , Empty > class_field_initializer_name )
2020-04-17 19:59:32 +02:00
{
2021-06-15 00:04:08 -07:00
Object * prototype = nullptr ;
switch ( kind ) {
2022-01-15 00:30:02 +01:00
case FunctionKind : : Normal :
2022-08-27 00:54:55 +01:00
prototype = realm . intrinsics ( ) . function_prototype ( ) ;
2021-06-15 00:04:08 -07:00
break ;
case FunctionKind : : Generator :
2022-08-27 00:54:55 +01:00
prototype = realm . intrinsics ( ) . generator_function_prototype ( ) ;
2021-06-15 00:04:08 -07:00
break ;
2021-11-09 20:39:22 +02:00
case FunctionKind : : Async :
2022-08-27 00:54:55 +01:00
prototype = realm . intrinsics ( ) . async_function_prototype ( ) ;
2021-11-09 20:39:22 +02:00
break ;
2021-11-15 01:53:24 +01:00
case FunctionKind : : AsyncGenerator :
2022-08-27 00:54:55 +01:00
prototype = realm . intrinsics ( ) . async_generator_function_prototype ( ) ;
2021-11-15 01:53:24 +01:00
break ;
2021-06-15 00:04:08 -07:00
}
2023-07-05 17:17:16 +02:00
return realm . heap ( ) . allocate < ECMAScriptFunctionObject > ( realm , move ( name ) , move ( source_text ) , ecmascript_code , move ( parameters ) , m_function_length , move ( local_variables_names ) , parent_environment , private_environment , * prototype , kind , is_strict , might_need_arguments_object , contains_direct_call_to_eval , is_arrow_function , move ( class_field_initializer_name ) ) . release_allocated_value_but_fixme_should_propagate_errors ( ) ;
2020-04-17 19:59:32 +02:00
}
2023-07-05 17:17:16 +02:00
NonnullGCPtr < ECMAScriptFunctionObject > ECMAScriptFunctionObject : : create ( Realm & realm , DeprecatedFlyString name , Object & prototype , DeprecatedString source_text , Statement const & ecmascript_code , Vector < FunctionParameter > parameters , i32 m_function_length , Vector < DeprecatedFlyString > local_variables_names , Environment * parent_environment , PrivateEnvironment * private_environment , FunctionKind kind , bool is_strict , bool might_need_arguments_object , bool contains_direct_call_to_eval , bool is_arrow_function , Variant < PropertyKey , PrivateName , Empty > class_field_initializer_name )
2022-01-15 17:18:12 +01:00
{
2023-07-05 17:17:16 +02:00
return realm . heap ( ) . allocate < ECMAScriptFunctionObject > ( realm , move ( name ) , move ( source_text ) , ecmascript_code , move ( parameters ) , m_function_length , move ( local_variables_names ) , parent_environment , private_environment , prototype , kind , is_strict , might_need_arguments_object , contains_direct_call_to_eval , is_arrow_function , move ( class_field_initializer_name ) ) . release_allocated_value_but_fixme_should_propagate_errors ( ) ;
2022-01-15 17:18:12 +01:00
}
2023-07-05 17:17:16 +02:00
ECMAScriptFunctionObject : : ECMAScriptFunctionObject ( DeprecatedFlyString name , DeprecatedString source_text , Statement const & ecmascript_code , Vector < FunctionParameter > formal_parameters , i32 function_length , Vector < DeprecatedFlyString > local_variables_names , Environment * parent_environment , PrivateEnvironment * private_environment , Object & prototype , FunctionKind kind , bool strict , bool might_need_arguments_object , bool contains_direct_call_to_eval , bool is_arrow_function , Variant < PropertyKey , PrivateName , Empty > class_field_initializer_name )
2021-09-25 00:38:23 +02:00
: FunctionObject ( prototype )
2022-01-31 13:19:06 +01:00
, m_name ( move ( name ) )
, m_function_length ( function_length )
2023-07-05 17:17:16 +02:00
, m_local_variables_names ( move ( local_variables_names ) )
2022-05-01 01:10:05 +02:00
, m_environment ( parent_environment )
, m_private_environment ( private_environment )
2021-09-24 23:10:21 +02:00
, m_formal_parameters ( move ( formal_parameters ) )
, m_ecmascript_code ( ecmascript_code )
2022-08-27 01:03:50 +01:00
, m_realm ( & prototype . shape ( ) . realm ( ) )
2022-01-18 23:47:11 +00:00
, m_source_text ( move ( source_text ) )
2022-04-10 00:55:45 +01:00
, m_class_field_initializer_name ( move ( class_field_initializer_name ) )
2022-01-31 13:19:06 +01:00
, m_strict ( strict )
LibJS: Add an optimization to avoid needless arguments object creation
This gives FunctionNode a "might need arguments object" boolean flag and
sets it based on the simplest possible heuristic for this: if we
encounter an identifier called "arguments" or "eval" up to the next
(nested) function declaration or expression, we won't need an arguments
object. Otherwise, we *might* need one - the final decision is made in
the FunctionDeclarationInstantiation AO.
Now, this is obviously not perfect. Even if you avoid eval, something
like `foo.arguments` will still trigger a false positive - but it's a
start and already massively cuts down on needlessly allocated objects,
especially in real-world code that is often minified, and so a full
"arguments" identifier will be an actual arguments object more often
than not.
To illustrate the actual impact of this change, here's the number of
allocated arguments objects during a full test-js run:
Before:
- Unmapped arguments objects: 78765
- Mapped arguments objects: 2455
After:
- Unmapped arguments objects: 18
- Mapped arguments objects: 37
This results in a ~5% speedup of test-js on my Linux host machine, and
about 3.5% on i686 Serenity in QEMU (warm runs, average of 5).
The following microbenchmark (calling an empty function 1M times) runs
25% faster on Linux and 45% on Serenity:
function foo() {}
for (var i = 0; i < 1_000_000; ++i)
foo();
test262 reports no changes in either direction, apart from a speedup :^)
2021-10-05 08:44:58 +01:00
, m_might_need_arguments_object ( might_need_arguments_object )
2021-10-08 12:43:38 +02:00
, m_contains_direct_call_to_eval ( contains_direct_call_to_eval )
2020-05-30 00:10:42 -05:00
, m_is_arrow_function ( is_arrow_function )
2022-01-31 13:19:06 +01:00
, m_kind ( kind )
2020-03-13 10:08:52 +01:00
{
2021-06-25 20:53:17 +02:00
// NOTE: This logic is from OrdinaryFunctionCreate, https://tc39.es/ecma262/#sec-ordinaryfunctioncreate
2022-01-17 14:48:22 +01:00
// 9. If thisMode is lexical-this, set F.[[ThisMode]] to lexical.
2021-06-25 20:53:17 +02:00
if ( m_is_arrow_function )
2021-09-24 23:19:36 +02:00
m_this_mode = ThisMode : : Lexical ;
2022-01-17 14:48:22 +01:00
// 10. Else if Strict is true, set F.[[ThisMode]] to strict.
2021-09-24 23:10:21 +02:00
else if ( m_strict )
2021-09-24 23:19:36 +02:00
m_this_mode = ThisMode : : Strict ;
2021-06-25 20:53:17 +02:00
else
2022-01-17 14:48:22 +01:00
// 11. Else, set F.[[ThisMode]] to global.
2021-09-24 23:19:36 +02:00
m_this_mode = ThisMode : : Global ;
2021-06-28 11:18:32 +02:00
2022-01-17 14:48:22 +01:00
// 15. Set F.[[ScriptOrModule]] to GetActiveScriptOrModule().
m_script_or_module = vm ( ) . get_active_script_or_module ( ) ;
2021-06-28 11:18:32 +02:00
// 15.1.3 Static Semantics: IsSimpleParameterList, https://tc39.es/ecma262/#sec-static-semantics-issimpleparameterlist
2021-09-25 00:10:09 +02:00
m_has_simple_parameter_list = all_of ( m_formal_parameters , [ & ] ( auto & parameter ) {
2021-06-28 11:18:32 +02:00
if ( parameter . is_rest )
return false ;
if ( parameter . default_value )
return false ;
2023-01-08 19:23:00 -05:00
if ( ! parameter . binding . template has < DeprecatedFlyString > ( ) )
2021-06-28 11:18:32 +02:00
return false ;
return true ;
2021-09-25 00:10:09 +02:00
} ) ;
2020-06-20 17:11:11 +02:00
}
2023-01-28 12:33:35 -05:00
ThrowCompletionOr < void > ECMAScriptFunctionObject : : initialize ( Realm & realm )
2020-06-20 17:11:11 +02:00
{
2020-10-13 23:49:19 +02:00
auto & vm = this - > vm ( ) ;
2023-01-28 12:33:35 -05:00
MUST_OR_THROW_OOM ( Base : : initialize ( realm ) ) ;
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.
2021-10-13 16:32:06 +02:00
MUST ( define_property_or_throw ( vm . names . length , { . value = Value ( m_function_length ) , . writable = false , . enumerable = false , . configurable = true } ) ) ;
2022-12-06 22:17:27 +00:00
MUST ( define_property_or_throw ( vm . names . name , { . value = PrimitiveString : : create ( vm , m_name . is_null ( ) ? " " : m_name ) , . writable = false , . enumerable = false , . configurable = true } ) ) ;
2021-10-13 16:32:06 +02:00
2020-06-08 13:31:21 -05:00
if ( ! m_is_arrow_function ) {
2021-11-10 19:23:12 +03:30
Object * prototype = nullptr ;
2021-06-15 00:04:08 -07:00
switch ( m_kind ) {
2022-01-15 00:30:02 +01:00
case FunctionKind : : Normal :
2023-04-13 00:47:15 +02:00
prototype = MUST_OR_THROW_OOM ( vm . heap ( ) . allocate < Object > ( realm , realm . intrinsics ( ) . new_ordinary_function_prototype_object_shape ( ) ) ) ;
2021-10-03 01:35:36 +01:00
MUST ( prototype - > define_property_or_throw ( vm . names . constructor , { . value = this , . writable = true , . enumerable = false , . configurable = true } ) ) ;
2021-06-15 00:04:08 -07:00
break ;
case FunctionKind : : Generator :
// prototype is "g1.prototype" in figure-2 (https://tc39.es/ecma262/img/figure-2.png)
2022-08-27 00:54:55 +01:00
prototype = Object : : create ( realm , realm . intrinsics ( ) . generator_function_prototype_prototype ( ) ) ;
2021-06-15 00:04:08 -07:00
break ;
2021-11-15 01:48:55 +01:00
case FunctionKind : : Async :
break ;
2021-11-15 01:53:24 +01:00
case FunctionKind : : AsyncGenerator :
2022-08-27 00:54:55 +01:00
prototype = Object : : create ( realm , realm . intrinsics ( ) . async_generator_function_prototype_prototype ( ) ) ;
2021-11-15 01:53:24 +01:00
break ;
2021-06-15 00:04:08 -07:00
}
2022-02-19 17:56:46 +02:00
// 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.
if ( m_kind ! = FunctionKind : : Async )
define_direct_property ( vm . names . prototype , prototype , Attribute : : Writable ) ;
2020-06-08 13:24:15 -05:00
}
2023-01-28 12:33:35 -05:00
return { } ;
2020-03-13 10:08:52 +01: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 [[Call]] ( thisArgument, argumentsList ), https://tc39.es/ecma262/#sec-ecmascript-function-objects-call-thisargument-argumentslist
2022-02-09 10:06:40 +00:00
ThrowCompletionOr < Value > ECMAScriptFunctionObject : : internal_call ( Value this_argument , MarkedVector < Value > arguments_list )
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 ( ) ;
// 1. Let callerContext be the running execution context.
// NOTE: No-op, kept by the VM in its execution context stack.
ExecutionContext callee_context ( heap ( ) ) ;
2023-07-05 02:12:39 +02:00
callee_context . local_variables . resize ( m_local_variables_names . size ( ) ) ;
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
// Non-standard
callee_context . arguments . extend ( move ( arguments_list ) ) ;
if ( auto * interpreter = vm . interpreter_if_exists ( ) )
callee_context . current_node = interpreter - > current_node ( ) ;
// 2. Let calleeContext be PrepareForOrdinaryCall(F, undefined).
// NOTE: We throw if the end of the native stack is reached, so unlike in the spec this _does_ need an exception check.
2021-11-14 12:10:34 +00:00
TRY ( prepare_for_ordinary_call ( 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.
VERIFY ( & vm . running_execution_context ( ) = = & callee_context ) ;
// 4. If F.[[IsClassConstructor]] is true, then
if ( m_is_class_constructor ) {
// a. Let error be a newly created TypeError object.
// b. NOTE: error is created in calleeContext with F's associated Realm Record.
2022-08-16 20:33:17 +01:00
auto throw_completion = vm . throw_completion < TypeError > ( ErrorType : : ClassConstructorWithoutNew , m_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).
2021-10-08 21:15:53 +01:00
ordinary_call_bind_this ( 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
2022-05-02 20:54:39 +02:00
// 6. Let result be Completion(OrdinaryCallEvaluateBody(F, argumentsList)).
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 result = ordinary_call_evaluate_body ( ) ;
// 7. Remove calleeContext from the execution context stack and restore callerContext as the running execution context.
vm . pop_execution_context ( ) ;
2022-05-02 20:54:39 +02:00
// 8. If result.[[Type]] is return, return result.[[Value]].
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
if ( result . type ( ) = = Completion : : Type : : Return )
2023-03-01 14:52:31 +00:00
return * result . value ( ) ;
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. ReturnIfAbrupt(result).
if ( result . is_abrupt ( ) ) {
VERIFY ( result . is_error ( ) ) ;
return result ;
}
2022-05-02 20:54:39 +02:00
// 10. Return undefined.
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 js_undefined ( ) ;
}
// 10.2.2 [[Construct]] ( argumentsList, newTarget ), https://tc39.es/ecma262/#sec-ecmascript-function-objects-construct-argumentslist-newtarget
2022-12-14 18:49:48 +00:00
ThrowCompletionOr < NonnullGCPtr < Object > > ECMAScriptFunctionObject : : internal_construct ( MarkedVector < Value > arguments_list , 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 ( ) ;
// 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]].
auto kind = m_constructor_kind ;
2022-12-14 18:34:32 +00:00
GCPtr < 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%").
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
}
ExecutionContext callee_context ( heap ( ) ) ;
2023-07-05 02:12:39 +02:00
callee_context . local_variables . resize ( m_local_variables_names . size ( ) ) ;
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
// Non-standard
callee_context . arguments . extend ( move ( arguments_list ) ) ;
if ( auto * interpreter = vm . interpreter_if_exists ( ) )
callee_context . current_node = interpreter - > current_node ( ) ;
// 4. Let calleeContext be PrepareForOrdinaryCall(F, newTarget).
// NOTE: We throw if the end of the native stack is reached, so unlike in the spec this _does_ need an exception check.
2021-11-14 12:10:34 +00:00
TRY ( prepare_for_ordinary_call ( 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.
VERIFY ( & vm . running_execution_context ( ) = = & callee_context ) ;
// 6. If kind is base, then
if ( kind = = ConstructorKind : : Base ) {
// a. Perform OrdinaryCallBindThis(F, calleeContext, thisArgument).
2021-10-08 21:15:53 +01:00
ordinary_call_bind_this ( 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
2022-05-02 20:54:39 +02:00
// b. Let initializeResult be Completion(InitializeInstanceElements(thisArgument, F)).
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 ( ) ;
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.
2023-02-26 16:09:02 -07: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
2022-05-02 20:54:39 +02:00
// 8. Let result be Completion(OrdinaryCallEvaluateBody(F, argumentsList)).
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 result = ordinary_call_evaluate_body ( ) ;
// 9. Remove calleeContext from the execution context stack and restore callerContext as the running execution context.
vm . pop_execution_context ( ) ;
// 10. If result.[[Type]] is return, then
if ( result . type ( ) = = Completion : : Type : : Return ) {
// FIXME: This is leftover from untangling the call/construct mess - doesn't belong here in any way, but removing it breaks derived classes.
// Likely fixed by making ClassDefinitionEvaluation fully spec compliant.
2021-12-28 17:42:14 +01:00
if ( kind = = ConstructorKind : : Derived & & result . value ( ) - > is_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
auto prototype = TRY ( new_target . get ( vm . names . prototype ) ) ;
if ( prototype . is_object ( ) )
2021-12-28 17:42:14 +01:00
TRY ( result . value ( ) - > as_object ( ) . internal_set_prototype_of ( & prototype . 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
}
// EOF (End of FIXME)
2022-05-02 20:54:39 +02:00
// a. If Type(result.[[Value]]) is Object, return result.[[Value]].
2021-12-28 17:42:14 +01:00
if ( result . value ( ) - > is_object ( ) )
2022-12-14 18:49:48 +00:00
return result . value ( ) - > 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
2022-05-02 20:54:39 +02:00
// b. If kind is base, return thisArgument.
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
if ( kind = = ConstructorKind : : Base )
2022-12-14 18:49:48 +00:00
return * 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
// c. If result.[[Value]] is not undefined, throw a TypeError exception.
2021-12-28 17:42:14 +01:00
if ( ! result . value ( ) - > is_undefined ( ) )
2022-08-16 20:33:17 +01: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
}
// 11. Else, ReturnIfAbrupt(result).
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 . is_abrupt ( ) ) {
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
VERIFY ( result . is_error ( ) ) ;
return result ;
}
2022-05-02 20:54:39 +02:00
// 12. Let thisBinding be ? constructorEnv.GetThisBinding().
2022-08-21 15:12:43 +01:00
auto this_binding = TRY ( constructor_env - > get_this_binding ( vm ) ) ;
2022-05-02 20:54:39 +02:00
// 13. Assert: Type(thisBinding) is Object.
VERIFY ( this_binding . is_object ( ) ) ;
// 14. Return thisBinding.
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
}
2021-09-24 22:40:38 +02:00
void ECMAScriptFunctionObject : : visit_edges ( Visitor & visitor )
2020-04-15 21:58:22 +02:00
{
2021-06-27 21:48:34 +02:00
Base : : visit_edges ( visitor ) ;
2021-06-25 21:22:37 +02:00
visitor . visit ( m_environment ) ;
2021-12-08 10:14:36 +01:00
visitor . visit ( m_private_environment ) ;
2021-09-11 19:19:08 +03:00
visitor . visit ( m_realm ) ;
2021-09-24 23:49:24 +02:00
visitor . visit ( m_home_object ) ;
2021-09-25 00:01:09 +02:00
for ( auto & field : m_fields ) {
2022-02-06 15:59:04 +00:00
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 ( ) ) ;
2021-09-25 00:01:09 +02:00
}
2022-09-05 14:31:25 +02:00
m_script_or_module . visit (
[ ] ( Empty ) { } ,
[ & ] ( auto & script_or_module ) {
visitor . visit ( script_or_module . ptr ( ) ) ;
} ) ;
2020-04-15 21:58:22 +02:00
}
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 ;
2022-05-02 20:54:39 +02:00
// 2. Return unused.
2021-12-29 10:33:46 +01:00
}
2021-09-22 12:44:56 +02:00
// 10.2.11 FunctionDeclarationInstantiation ( func, argumentsList ), https://tc39.es/ecma262/#sec-functiondeclarationinstantiation
ThrowCompletionOr < void > ECMAScriptFunctionObject : : function_declaration_instantiation ( Interpreter * interpreter )
{
auto & vm = this - > vm ( ) ;
2022-08-22 19:00:49 +01:00
auto & realm = * vm . current_realm ( ) ;
2021-09-22 12:44:56 +02:00
auto & callee_context = vm . running_execution_context ( ) ;
// Needed to extract declarations and functions
ScopeNode const * scope_body = nullptr ;
if ( is < ScopeNode > ( * m_ecmascript_code ) )
scope_body = static_cast < ScopeNode const * > ( m_ecmascript_code . ptr ( ) ) ;
bool has_parameter_expressions = false ;
// FIXME: Maybe compute has duplicates at parse time? (We need to anyway since it's an error in some cases)
bool has_duplicates = false ;
2023-01-08 19:23:00 -05:00
HashTable < DeprecatedFlyString > parameter_names ;
2021-09-24 23:10:21 +02:00
for ( auto & parameter : m_formal_parameters ) {
2021-09-22 12:44:56 +02:00
if ( parameter . default_value )
has_parameter_expressions = true ;
2021-05-29 16:03:19 +04:30
parameter . binding . visit (
2023-01-08 19:23:00 -05:00
[ & ] ( DeprecatedFlyString const & name ) {
2021-09-22 12:44:56 +02:00
if ( parameter_names . set ( name ) ! = AK : : HashSetResult : : InsertedNewEntry )
has_duplicates = true ;
} ,
2023-02-19 22:07:52 +01:00
[ & ] ( NonnullRefPtr < BindingPattern const > const & pattern ) {
2021-09-22 12:44:56 +02:00
if ( pattern - > contains_expression ( ) )
has_parameter_expressions = true ;
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
MUST ( pattern - > for_each_bound_name ( [ & ] ( auto & name ) {
2021-09-22 12:44:56 +02:00
if ( parameter_names . set ( name ) ! = AK : : HashSetResult : : InsertedNewEntry )
has_duplicates = true ;
2023-02-27 22:13:37 +00:00
} ) ) ;
2021-05-29 16:03:19 +04:30
} ) ;
2020-04-15 21:58:22 +02:00
}
LibJS: Add an optimization to avoid needless arguments object creation
This gives FunctionNode a "might need arguments object" boolean flag and
sets it based on the simplest possible heuristic for this: if we
encounter an identifier called "arguments" or "eval" up to the next
(nested) function declaration or expression, we won't need an arguments
object. Otherwise, we *might* need one - the final decision is made in
the FunctionDeclarationInstantiation AO.
Now, this is obviously not perfect. Even if you avoid eval, something
like `foo.arguments` will still trigger a false positive - but it's a
start and already massively cuts down on needlessly allocated objects,
especially in real-world code that is often minified, and so a full
"arguments" identifier will be an actual arguments object more often
than not.
To illustrate the actual impact of this change, here's the number of
allocated arguments objects during a full test-js run:
Before:
- Unmapped arguments objects: 78765
- Mapped arguments objects: 2455
After:
- Unmapped arguments objects: 18
- Mapped arguments objects: 37
This results in a ~5% speedup of test-js on my Linux host machine, and
about 3.5% on i686 Serenity in QEMU (warm runs, average of 5).
The following microbenchmark (calling an empty function 1M times) runs
25% faster on Linux and 45% on Serenity:
function foo() {}
for (var i = 0; i < 1_000_000; ++i)
foo();
test262 reports no changes in either direction, apart from a speedup :^)
2021-10-05 08:44:58 +01:00
auto arguments_object_needed = m_might_need_arguments_object ;
if ( this_mode ( ) = = ThisMode : : Lexical )
arguments_object_needed = false ;
2021-09-22 12:44:56 +02:00
if ( parameter_names . contains ( vm . names . arguments . as_string ( ) ) )
2021-10-04 23:59:54 +01:00
arguments_object_needed = false ;
2021-09-22 12:44:56 +02:00
2023-01-08 19:23:00 -05:00
HashTable < DeprecatedFlyString > function_names ;
2021-09-22 12:44:56 +02:00
Vector < FunctionDeclaration const & > functions_to_initialize ;
if ( scope_body ) {
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
MUST ( scope_body - > for_each_var_function_declaration_in_reverse_order ( [ & ] ( FunctionDeclaration const & function ) {
2021-09-22 12:44:56 +02:00
if ( function_names . set ( function . name ( ) ) = = AK : : HashSetResult : : InsertedNewEntry )
functions_to_initialize . append ( function ) ;
2023-02-27 22:13:37 +00:00
} ) ) ;
2021-09-22 12:44:56 +02:00
2021-10-08 01:31:39 +02:00
auto const & arguments_name = vm . names . arguments . as_string ( ) ;
2021-09-22 12:44:56 +02:00
if ( ! has_parameter_expressions & & function_names . contains ( arguments_name ) )
2021-10-04 23:59:54 +01:00
arguments_object_needed = false ;
2021-09-22 12:44:56 +02:00
2021-10-04 23:59:54 +01:00
if ( ! has_parameter_expressions & & arguments_object_needed ) {
2023-02-27 22:13:37 +00:00
// NOTE: Nothing in the callback throws an exception.
MUST ( scope_body - > for_each_lexically_declared_name ( [ & ] ( auto const & name ) {
2022-02-07 13:31:01 +01:00
if ( name = = arguments_name )
2021-10-04 23:59:54 +01:00
arguments_object_needed = false ;
2023-02-27 22:13:37 +00:00
} ) ) ;
2020-04-15 21:58:22 +02:00
}
2021-10-05 00:04:25 +01:00
} else {
arguments_object_needed = false ;
2020-04-15 21:58:22 +02:00
}
2020-06-08 13:31:21 -05:00
2022-12-15 19:59:47 +00:00
GCPtr < Environment > environment ;
2021-09-22 12:44:56 +02:00
if ( is_strict_mode ( ) | | ! has_parameter_expressions ) {
environment = callee_context . lexical_environment ;
} else {
environment = new_declarative_environment ( * callee_context . lexical_environment ) ;
VERIFY ( callee_context . variable_environment = = callee_context . lexical_environment ) ;
callee_context . lexical_environment = environment ;
2020-11-28 16:02:27 +01:00
}
2021-09-22 12:44:56 +02:00
for ( auto const & parameter_name : parameter_names ) {
2021-10-09 17:07:32 +01:00
if ( MUST ( environment - > has_binding ( parameter_name ) ) )
2021-09-22 12:44:56 +02:00
continue ;
2022-08-21 15:12:43 +01:00
MUST ( environment - > create_mutable_binding ( vm , parameter_name , false ) ) ;
2021-09-22 12:44:56 +02:00
if ( has_duplicates )
2022-12-14 13:26:10 +01:00
MUST ( environment - > initialize_binding ( vm , parameter_name , js_undefined ( ) , Environment : : InitializeBindingHint : : Normal ) ) ;
2021-09-22 12:44:56 +02:00
}
2021-10-04 23:59:54 +01:00
if ( arguments_object_needed ) {
2021-09-22 12:44:56 +02:00
Object * arguments_object ;
if ( is_strict_mode ( ) | | ! has_simple_parameter_list ( ) )
2022-08-21 19:24:32 +01:00
arguments_object = create_unmapped_arguments_object ( vm , vm . running_execution_context ( ) . arguments ) ;
2021-09-22 12:44:56 +02:00
else
2022-08-21 19:24:32 +01:00
arguments_object = create_mapped_arguments_object ( vm , * this , formal_parameters ( ) , vm . running_execution_context ( ) . arguments , * environment ) ;
2021-09-22 12:44:56 +02:00
if ( is_strict_mode ( ) )
2022-08-21 15:12:43 +01:00
MUST ( environment - > create_immutable_binding ( vm , vm . names . arguments . as_string ( ) , false ) ) ;
2021-09-22 12:44:56 +02:00
else
2022-08-21 15:12:43 +01:00
MUST ( environment - > create_mutable_binding ( vm , vm . names . arguments . as_string ( ) , false ) ) ;
2021-09-22 12:44:56 +02:00
2022-12-14 13:26:10 +01:00
MUST ( environment - > initialize_binding ( vm , vm . names . arguments . as_string ( ) , arguments_object , Environment : : InitializeBindingHint : : Normal ) ) ;
2021-09-22 12:44:56 +02:00
parameter_names . set ( vm . names . arguments . as_string ( ) ) ;
}
// We now treat parameterBindings as parameterNames.
// The spec makes an iterator here to do IteratorBindingInitialization but we just do it manually
auto & execution_context_arguments = vm . running_execution_context ( ) . arguments ;
2022-03-14 23:32:13 +03:30
size_t default_parameter_index = 0 ;
2021-09-22 12:44:56 +02:00
for ( size_t i = 0 ; i < m_formal_parameters . size ( ) ; + + i ) {
auto & parameter = m_formal_parameters [ i ] ;
2022-03-14 23:32:13 +03:30
if ( parameter . default_value )
+ + default_parameter_index ;
2021-11-02 19:20:21 +02:00
TRY ( parameter . binding . visit (
[ & ] ( auto const & param ) - > ThrowCompletionOr < void > {
2021-09-22 12:44:56 +02:00
Value argument_value ;
if ( parameter . is_rest ) {
2022-12-13 20:49:49 +00:00
auto array = MUST ( Array : : create ( realm , 0 ) ) ;
2021-09-22 12:44:56 +02:00
for ( size_t rest_index = i ; rest_index < execution_context_arguments . size ( ) ; + + rest_index )
array - > indexed_properties ( ) . append ( execution_context_arguments [ rest_index ] ) ;
2021-11-02 19:20:21 +02:00
argument_value = array ;
2021-09-22 12:44:56 +02:00
} else if ( i < execution_context_arguments . size ( ) & & ! execution_context_arguments [ i ] . is_undefined ( ) ) {
argument_value = execution_context_arguments [ i ] ;
} else if ( parameter . default_value ) {
2023-06-23 07:16:31 +02:00
auto * bytecode_interpreter = vm . bytecode_interpreter_if_exists ( ) ;
if ( static_cast < FunctionKind > ( m_kind ) = = FunctionKind : : Generator )
bytecode_interpreter = & vm . bytecode_interpreter ( ) ;
if ( bytecode_interpreter ) {
2023-06-22 15:59:18 +02:00
auto value_and_frame = bytecode_interpreter - > run_and_return_frame ( realm , * m_default_parameter_bytecode_executables [ default_parameter_index - 1 ] , nullptr ) ;
2022-03-14 23:32:13 +03:30
if ( value_and_frame . value . is_error ( ) )
return value_and_frame . value . release_error ( ) ;
// Resulting value is in the accumulator.
argument_value = value_and_frame . frame - > registers . at ( 0 ) ;
} else if ( interpreter ) {
2022-08-16 19:28:17 +01:00
argument_value = TRY ( parameter . default_value - > execute ( * interpreter ) ) . release_value ( ) ;
2022-03-14 23:32:13 +03:30
}
2021-09-22 12:44:56 +02:00
} else {
argument_value = js_undefined ( ) ;
}
Environment * used_environment = has_duplicates ? nullptr : environment ;
2023-01-08 19:23:00 -05:00
if constexpr ( IsSame < DeprecatedFlyString const & , decltype ( param ) > ) {
2021-12-30 14:13:20 +01:00
Reference reference = TRY ( vm . resolve_binding ( param , used_environment ) ) ;
2021-09-22 12:44:56 +02:00
// Here the difference from hasDuplicates is important
if ( has_duplicates )
2022-08-21 15:39:13 +01:00
return reference . put_value ( vm , argument_value ) ;
2021-09-22 12:44:56 +02:00
else
2022-08-21 15:39:13 +01:00
return reference . initialize_referenced_binding ( vm , argument_value ) ;
2023-02-19 22:07:52 +01:00
}
if constexpr ( IsSame < NonnullRefPtr < BindingPattern const > const & , decltype ( param ) > ) {
2021-09-22 12:44:56 +02:00
// Here the difference from hasDuplicates is important
2022-08-21 20:38:35 +01:00
return vm . binding_initialization ( param , argument_value , used_environment ) ;
2021-09-22 12:44:56 +02:00
}
2021-11-02 19:20:21 +02:00
} ) ) ;
2021-09-22 12:44:56 +02:00
}
2022-12-15 19:59:47 +00:00
GCPtr < Environment > var_environment ;
2021-09-22 12:44:56 +02:00
2023-01-08 19:23:00 -05:00
HashTable < DeprecatedFlyString > instantiated_var_names ;
2021-10-08 01:32:12 +02:00
if ( scope_body )
instantiated_var_names . ensure_capacity ( scope_body - > var_declaration_count ( ) ) ;
2021-09-22 12:44:56 +02:00
if ( ! has_parameter_expressions ) {
if ( scope_body ) {
2023-02-27 22:13:37 +00:00
// NOTE: Due to the use of MUST with `create_mutable_binding` and `initialize_binding` below,
// an exception should not result from `for_each_var_declared_name`.
2023-07-05 02:17:10 +02:00
MUST ( scope_body - > for_each_var_declared_identifier ( [ & ] ( auto const & id ) {
if ( ! parameter_names . contains ( id . string ( ) ) & & instantiated_var_names . set ( id . string ( ) ) = = AK : : HashSetResult : : InsertedNewEntry ) {
if ( vm . bytecode_interpreter_if_exists ( ) & & id . is_local ( ) ) {
callee_context . local_variables [ id . local_variable_index ( ) ] = js_undefined ( ) ;
} else {
MUST ( environment - > create_mutable_binding ( vm , id . string ( ) , false ) ) ;
MUST ( environment - > initialize_binding ( vm , id . string ( ) , js_undefined ( ) , Environment : : InitializeBindingHint : : Normal ) ) ;
}
2021-09-22 12:44:56 +02:00
}
2023-02-27 22:13:37 +00:00
} ) ) ;
2021-09-22 12:44:56 +02:00
}
var_environment = environment ;
} else {
var_environment = new_declarative_environment ( * environment ) ;
callee_context . variable_environment = var_environment ;
if ( scope_body ) {
2023-02-27 22:13:37 +00:00
// NOTE: Due to the use of MUST with `create_mutable_binding`, `get_binding_value` and `initialize_binding` below,
// an exception should not result from `for_each_var_declared_name`.
2023-07-05 02:17:10 +02:00
MUST ( scope_body - > for_each_var_declared_identifier ( [ & ] ( auto const & id ) {
if ( instantiated_var_names . set ( id . string ( ) ) ! = AK : : HashSetResult : : InsertedNewEntry )
2022-02-07 13:31:01 +01:00
return ;
2023-07-05 02:17:10 +02:00
MUST ( var_environment - > create_mutable_binding ( vm , id . string ( ) , false ) ) ;
2021-09-22 12:44:56 +02:00
Value initial_value ;
2023-07-05 02:17:10 +02:00
if ( ! parameter_names . contains ( id . string ( ) ) | | function_names . contains ( id . string ( ) ) )
2021-09-22 12:44:56 +02:00
initial_value = js_undefined ( ) ;
else
2023-07-05 02:17:10 +02:00
initial_value = MUST ( environment - > get_binding_value ( vm , id . string ( ) , false ) ) ;
2021-09-22 12:44:56 +02:00
2023-07-05 02:17:10 +02:00
if ( vm . bytecode_interpreter_if_exists ( ) & & id . is_local ( ) ) {
// NOTE: Local variables are supported only in bytecode interpreter
callee_context . local_variables [ id . local_variable_index ( ) ] = initial_value ;
} else {
MUST ( var_environment - > initialize_binding ( vm , id . string ( ) , initial_value , Environment : : InitializeBindingHint : : Normal ) ) ;
}
2023-02-27 22:13:37 +00:00
} ) ) ;
2021-09-22 12:44:56 +02:00
}
}
// B.3.2.1 Changes to FunctionDeclarationInstantiation, https://tc39.es/ecma262/#sec-web-compat-functiondeclarationinstantiation
if ( ! m_strict & & scope_body ) {
2023-02-27 22:13:37 +00:00
// NOTE: Due to the use of MUST with `create_mutable_binding` and `initialize_binding` below,
// an exception should not result from `for_each_function_hoistable_with_annexB_extension`.
MUST ( scope_body - > for_each_function_hoistable_with_annexB_extension ( [ & ] ( FunctionDeclaration & function_declaration ) {
2023-07-02 00:35:51 +03:00
auto function_name = function_declaration . name ( ) ;
2021-09-22 12:44:56 +02:00
if ( parameter_names . contains ( function_name ) )
2022-02-07 13:31:01 +01:00
return ;
2021-09-22 12:44:56 +02:00
// The spec says 'initializedBindings' here but that does not exist and it then adds it to 'instantiatedVarNames' so it probably means 'instantiatedVarNames'.
if ( ! instantiated_var_names . contains ( function_name ) & & function_name ! = vm . names . arguments . as_string ( ) ) {
2022-08-21 15:12:43 +01:00
MUST ( var_environment - > create_mutable_binding ( vm , function_name , false ) ) ;
2022-12-14 13:26:10 +01:00
MUST ( var_environment - > initialize_binding ( vm , function_name , js_undefined ( ) , Environment : : InitializeBindingHint : : Normal ) ) ;
2021-09-22 12:44:56 +02:00
instantiated_var_names . set ( function_name ) ;
}
function_declaration . set_should_do_additional_annexB_steps ( ) ;
2023-02-27 22:13:37 +00:00
} ) ) ;
2021-09-22 12:44:56 +02:00
}
2022-12-15 19:59:47 +00:00
GCPtr < Environment > lex_environment ;
2021-09-22 12:44:56 +02:00
2021-10-08 12:49:10 +02:00
// 30. If strict is false, then
if ( ! is_strict_mode ( ) ) {
// Optimization: We avoid creating empty top-level declarative environments in non-strict mode, if both of these conditions are true:
// 1. there is no direct call to eval() within this function
// 2. there are no lexical declarations that would go into the environment
bool can_elide_declarative_environment = ! m_contains_direct_call_to_eval & & ( ! scope_body | | ! scope_body - > has_lexical_declarations ( ) ) ;
if ( can_elide_declarative_environment ) {
lex_environment = var_environment ;
} else {
// a. Let lexEnv be NewDeclarativeEnvironment(varEnv).
// b. NOTE: Non-strict functions use a separate Environment Record for top-level lexical declarations so that a direct eval
// can determine whether any var scoped declarations introduced by the eval code conflict with pre-existing top-level
// lexically scoped declarations. This is not needed for strict functions because a strict direct eval always places
// all declarations into a new Environment Record.
lex_environment = new_declarative_environment ( * var_environment ) ;
}
} else {
// 31. Else, let lexEnv be varEnv.
2021-09-22 12:44:56 +02:00
lex_environment = var_environment ;
2021-10-08 12:49:10 +02:00
}
2021-09-22 12:44:56 +02:00
2021-10-08 12:49:10 +02:00
// 32. Set the LexicalEnvironment of calleeContext to lexEnv.
2021-09-22 12:44:56 +02:00
callee_context . lexical_environment = lex_environment ;
if ( ! scope_body )
return { } ;
2023-06-15 09:14:25 +02:00
// NOTE: Due to the use of MUST in the callback, an exception should not result from `for_each_lexically_scoped_declaration`.
MUST ( scope_body - > for_each_lexically_scoped_declaration ( [ & ] ( Declaration const & declaration ) {
// NOTE: Due to the use of MUST with `create_immutable_binding` and `create_mutable_binding` below,
// an exception should not result from `for_each_bound_name`.
2023-07-05 02:17:10 +02:00
MUST ( declaration . for_each_bound_identifier ( [ & ] ( auto const & id ) {
if ( vm . bytecode_interpreter_if_exists ( ) & & id . is_local ( ) ) {
// NOTE: Local variables are supported only in bytecode interpreter
return ;
}
2023-06-15 09:14:25 +02:00
if ( declaration . is_constant_declaration ( ) )
2023-07-05 02:17:10 +02:00
MUST ( lex_environment - > create_immutable_binding ( vm , id . string ( ) , true ) ) ;
2023-06-15 09:14:25 +02:00
else
2023-07-05 02:17:10 +02:00
MUST ( lex_environment - > create_mutable_binding ( vm , id . string ( ) , false ) ) ;
2023-02-27 22:13:37 +00:00
} ) ) ;
2023-06-15 09:14:25 +02:00
} ) ) ;
2021-09-22 12:44:56 +02:00
2023-02-26 16:09:02 -07:00
auto private_environment = callee_context . private_environment ;
2021-09-22 12:44:56 +02:00
for ( auto & declaration : functions_to_initialize ) {
2023-07-05 17:17:16 +02:00
auto function = ECMAScriptFunctionObject : : create ( realm , declaration . name ( ) , declaration . source_text ( ) , declaration . body ( ) , declaration . parameters ( ) , declaration . function_length ( ) , declaration . local_variables_names ( ) , lex_environment , private_environment , declaration . kind ( ) , declaration . is_strict_mode ( ) , declaration . might_need_arguments_object ( ) , declaration . contains_direct_call_to_eval ( ) ) ;
2022-08-21 15:12:43 +01:00
MUST ( var_environment - > set_mutable_binding ( vm , declaration . name ( ) , function , false ) ) ;
2021-09-22 12:44:56 +02:00
}
2022-11-26 20:33:52 +01:00
if ( is < DeclarativeEnvironment > ( * lex_environment ) )
2022-12-15 19:59:47 +00:00
static_cast < DeclarativeEnvironment * > ( lex_environment . ptr ( ) ) - > shrink_to_fit ( ) ;
2022-11-26 20:33:52 +01:00
if ( is < DeclarativeEnvironment > ( * var_environment ) )
2022-12-15 19:59:47 +00:00
static_cast < DeclarativeEnvironment * > ( var_environment . ptr ( ) ) - > shrink_to_fit ( ) ;
2022-11-26 20:33:52 +01:00
2021-09-22 12:44:56 +02:00
return { } ;
2020-04-15 21:58:22 +02:00
}
2021-10-08 21:14:22 +01:00
// 10.2.1.1 PrepareForOrdinaryCall ( F, newTarget ), https://tc39.es/ecma262/#sec-prepareforordinarycall
2021-11-14 12:10:34 +00:00
ThrowCompletionOr < void > ECMAScriptFunctionObject : : prepare_for_ordinary_call ( ExecutionContext & callee_context , Object * new_target )
2021-10-08 21:14:22 +01:00
{
auto & vm = this - > vm ( ) ;
// Non-standard
callee_context . is_strict_mode = m_strict ;
// 1. Let callerContext be the running execution context.
// 2. Let calleeContext be a new ECMAScript code execution context.
// NOTE: In the specification, PrepareForOrdinaryCall "returns" a new callee execution context.
// To avoid heap allocations, we put our ExecutionContext objects on the C++ stack instead.
// Whoever calls us should put an ExecutionContext on their stack and pass that as the `callee_context`.
// 3. Set the Function of calleeContext to F.
callee_context . function = this ;
callee_context . function_name = m_name ;
// 4. Let calleeRealm be F.[[Realm]].
2023-02-26 16:09:02 -07:00
auto callee_realm = m_realm ;
2021-10-08 21:14:22 +01:00
// NOTE: This non-standard fallback is needed until we can guarantee that literally
// every function has a realm - especially in LibWeb that's sometimes not the case
// when a function is created while no JS is running, as we currently need to rely on
// that (:acid2:, I know - see set_event_handler_attribute() for an example).
// If there's no 'current realm' either, we can't continue and crash.
if ( ! callee_realm )
callee_realm = vm . current_realm ( ) ;
VERIFY ( callee_realm ) ;
// 5. Set the Realm of calleeContext to calleeRealm.
callee_context . realm = callee_realm ;
// 6. Set the ScriptOrModule of calleeContext to F.[[ScriptOrModule]].
2022-01-17 14:48:22 +01:00
callee_context . script_or_module = m_script_or_module ;
2021-10-08 21:14:22 +01:00
// 7. Let localEnv be NewFunctionEnvironment(F, newTarget).
2022-12-15 20:03:46 +00:00
auto local_environment = new_function_environment ( * this , new_target ) ;
2021-10-08 21:14:22 +01:00
// 8. Set the LexicalEnvironment of calleeContext to localEnv.
callee_context . lexical_environment = local_environment ;
// 9. Set the VariableEnvironment of calleeContext to localEnv.
callee_context . variable_environment = local_environment ;
// 10. Set the PrivateEnvironment of calleeContext to F.[[PrivateEnvironment]].
2021-10-11 20:29:31 +02:00
callee_context . private_environment = m_private_environment ;
2021-10-08 21:14:22 +01:00
// 11. If callerContext is not already suspended, suspend callerContext.
// FIXME: We don't have this concept yet.
// 12. Push calleeContext onto the execution context stack; calleeContext is now the running execution context.
2022-08-21 20:38:35 +01:00
TRY ( vm . push_execution_context ( callee_context , { } ) ) ;
2021-10-08 21:14:22 +01:00
// 13. NOTE: Any exception objects produced after this point are associated with calleeRealm.
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.
2021-11-14 12:10:34 +00:00
return { } ;
2021-10-08 21:14:22 +01:00
}
2021-10-08 21:15:53 +01:00
// 10.2.1.2 OrdinaryCallBindThis ( F, calleeContext, thisArgument ), https://tc39.es/ecma262/#sec-ordinarycallbindthis
void ECMAScriptFunctionObject : : ordinary_call_bind_this ( ExecutionContext & callee_context , Value this_argument )
{
2021-10-09 15:18:29 +01:00
auto & vm = this - > vm ( ) ;
2021-10-08 21:15:53 +01:00
// 1. Let thisMode be F.[[ThisMode]].
auto this_mode = m_this_mode ;
2022-05-02 20:54:39 +02:00
// If thisMode is lexical, return unused.
2021-10-08 21:15:53 +01:00
if ( this_mode = = ThisMode : : Lexical )
return ;
// 3. Let calleeRealm be F.[[Realm]].
2023-02-26 16:09:02 -07:00
auto callee_realm = m_realm ;
2021-10-09 15:18:29 +01:00
// NOTE: This non-standard fallback is needed until we can guarantee that literally
// every function has a realm - especially in LibWeb that's sometimes not the case
// when a function is created while no JS is running, as we currently need to rely on
// that (:acid2:, I know - see set_event_handler_attribute() for an example).
// If there's no 'current realm' either, we can't continue and crash.
if ( ! callee_realm )
callee_realm = vm . current_realm ( ) ;
VERIFY ( callee_realm ) ;
2021-10-08 21:15:53 +01:00
// 4. Let localEnv be the LexicalEnvironment of calleeContext.
2023-02-26 16:09:02 -07:00
auto local_env = callee_context . lexical_environment ;
2021-10-08 21:15:53 +01:00
Value this_value ;
// 5. If thisMode is strict, let thisValue be thisArgument.
if ( this_mode = = ThisMode : : Strict ) {
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).
2022-08-21 14:00:56 +01:00
this_value = MUST ( this_argument . to_object ( vm ) ) ;
2021-10-08 21:15:53 +01:00
// ii. NOTE: ToObject produces wrapper objects using calleeRealm.
2022-08-21 14:00:56 +01:00
VERIFY ( vm . current_realm ( ) = = callee_realm ) ;
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.
2022-05-02 20:54:39 +02:00
// 9. Perform ! localEnv.BindThisValue(thisValue).
2023-02-26 16:09:02 -07:00
MUST ( verify_cast < FunctionEnvironment > ( * local_env ) . bind_this_value ( vm , this_value ) ) ;
2022-05-02 20:54:39 +02:00
// 10. Return unused.
2021-10-08 21:15:53 +01:00
}
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
void ECMAScriptFunctionObject : : async_function_start ( PromiseCapability const & promise_capability )
{
auto & vm = this - > vm ( ) ;
// 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.
2022-05-02 20:54:39 +02:00
// 4. Perform AsyncBlockStart(promiseCapability, asyncFunctionBody, asyncContext).
2022-01-18 18:50:39 +01:00
async_block_start ( vm , m_ecmascript_code , promise_capability , async_context ) ;
2022-05-02 20:54:39 +02:00
// 5. Return unused.
2021-11-09 20:39:22 +02:00
}
// 27.7.5.2 AsyncBlockStart ( promiseCapability, asyncBody, asyncContext ), https://tc39.es/ecma262/#sec-asyncblockstart
2023-02-19 22:07:52 +01:00
void async_block_start ( VM & vm , NonnullRefPtr < Statement const > const & async_body , PromiseCapability const & promise_capability , ExecutionContext & async_context )
2021-11-09 20:39:22 +02:00
{
2022-08-16 00:20:49 +01:00
auto & realm = * vm . current_realm ( ) ;
2021-11-09 20:39:22 +02:00
// 1. Assert: promiseCapability is a PromiseCapability Record.
// 2. Let runningContext be the running execution context.
auto & running_context = vm . running_execution_context ( ) ;
// 3. Set the code evaluation state of asyncContext such that when evaluation is resumed for that execution context the following steps will be performed:
2023-06-22 15:59:18 +02:00
auto execution_steps = NativeFunction : : create ( realm , " " , [ & realm , & async_body , & promise_capability , & async_context ] ( auto & vm ) - > ThrowCompletionOr < Value > {
2021-11-09 20:39:22 +02:00
// a. Let result be the result of evaluating asyncBody.
2023-06-22 15:59:18 +02:00
Completion result ;
if ( auto * bytecode_interpreter = vm . bytecode_interpreter_if_exists ( ) ) {
// FIXME: Cache this executable somewhere.
auto maybe_executable = Bytecode : : compile ( vm , async_body , FunctionKind : : Async , " AsyncBlockStart " sv ) ;
if ( maybe_executable . is_error ( ) )
result = maybe_executable . release_error ( ) ;
else
result = bytecode_interpreter - > run_and_return_frame ( realm , * maybe_executable . value ( ) , nullptr ) . value ;
} else {
result = async_body - > execute ( vm . interpreter ( ) ) ;
}
2021-11-09 20:39:22 +02:00
// b. Assert: If we return here, the async function either threw an exception or performed an implicit or explicit return; all awaiting is done.
// c. Remove asyncContext 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.
vm . pop_execution_context ( ) ;
2022-12-20 22:09:57 +01:00
// d. Let env be asyncContext's LexicalEnvironment.
2023-02-26 16:09:02 -07:00
auto env = async_context . lexical_environment ;
VERIFY ( is < DeclarativeEnvironment > ( * env ) ) ;
2022-12-20 22:09:57 +01:00
// e. Set result to DisposeResources(env, result).
2023-02-26 16:09:02 -07:00
result = dispose_resources ( vm , static_cast < DeclarativeEnvironment * > ( env . ptr ( ) ) , result ) ;
2022-12-20 22:09:57 +01:00
// f. If result.[[Type]] is normal, 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 ) {
2021-11-09 20:39:22 +02:00
// i. Perform ! Call(promiseCapability.[[Resolve]], undefined, « undefined »).
2022-10-02 12:11:30 +01:00
MUST ( call ( vm , * promise_capability . resolve ( ) , js_undefined ( ) , js_undefined ( ) ) ) ;
2021-11-09 20:39:22 +02:00
}
2022-12-20 22:09:57 +01:00
// g. Else if result.[[Type]] is return, 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 ) {
2021-11-09 20:39:22 +02:00
// i. Perform ! Call(promiseCapability.[[Resolve]], undefined, « result.[[Value]] »).
2022-10-02 12:11:30 +01:00
MUST ( call ( vm , * promise_capability . resolve ( ) , js_undefined ( ) , * result . value ( ) ) ) ;
2021-11-09 20:39:22 +02:00
}
2022-12-20 22:09:57 +01:00
// h. Else,
2021-11-09 20:39:22 +02:00
else {
// i. Assert: result.[[Type]] is throw.
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 ) ;
2021-11-09 20:39:22 +02:00
// ii. Perform ! Call(promiseCapability.[[Reject]], undefined, « result.[[Value]] »).
2022-10-02 12:11:30 +01:00
MUST ( call ( vm , * promise_capability . reject ( ) , js_undefined ( ) , * result . value ( ) ) ) ;
2021-11-09 20:39:22 +02:00
}
2022-12-20 22:09:57 +01:00
// i. Return unused.
2022-05-02 20:54:39 +02:00
// NOTE: We don't support returning an empty/optional/unused value here.
2021-11-09 20:39:22 +02:00
return js_undefined ( ) ;
} ) ;
// 4. Push asyncContext onto the execution context stack; asyncContext is now the running execution context.
2022-08-21 20:38:35 +01:00
auto push_result = vm . push_execution_context ( async_context , { } ) ;
2021-11-14 12:20:49 +00:00
if ( push_result . is_error ( ) )
return ;
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.
2022-08-21 19:24:32 +01:00
auto result = call ( vm , * execution_steps , async_context . this_value . is_empty ( ) ? js_undefined ( ) : async_context . this_value ) ;
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 ) ;
2022-05-03 21:23:12 +02: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 3.g above.
2021-11-09 20:39:22 +02:00
VERIFY ( result . has_value ( ) & & result . value ( ) . is_undefined ( ) ) ;
2022-05-02 20:54:39 +02:00
// 8. Return unused.
2021-11-09 20:39:22 +02: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: 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
Completion ECMAScriptFunctionObject : : ordinary_call_evaluate_body ( )
2020-03-13 10:08:52 +01:00
{
2020-11-11 21:37:23 +00:00
auto & vm = this - > vm ( ) ;
2022-08-22 19:00:49 +01:00
auto & realm = * vm . current_realm ( ) ;
2021-06-05 15:53:36 +02:00
2021-11-15 01:53:24 +01:00
if ( m_kind = = FunctionKind : : AsyncGenerator )
2022-08-16 20:33:17 +01:00
return vm . throw_completion < InternalError > ( ErrorType : : NotImplemented , " Async Generator function execution " ) ;
2021-11-15 01:53:24 +01:00
2023-06-22 15:59:18 +02:00
auto * bytecode_interpreter = vm . bytecode_interpreter_if_exists ( ) ;
2022-11-26 15:46:24 +00:00
// The bytecode interpreter can execute generator functions while the AST interpreter cannot.
// This simply makes it create a new bytecode interpreter when one doesn't exist when executing a generator function.
// Doing so makes it automatically switch to the bytecode interpreter to execute any future code until it exits the generator. See below.
// This allows us to keep all of the existing functionality that works in AST while adding generator support on top of it.
// However, this does cause an awkward situation with features not supported in bytecode, where features that work outside of generators with AST
// suddenly stop working inside of generators.
// This is a stop gap until bytecode mode becomes the default.
if ( m_kind = = FunctionKind : : Generator & & ! bytecode_interpreter ) {
2023-06-22 15:59:18 +02:00
bytecode_interpreter = & vm . bytecode_interpreter ( ) ;
2022-11-26 15:46:24 +00:00
}
2021-06-05 15:53:36 +02:00
if ( bytecode_interpreter ) {
2023-06-17 14:20:48 +02:00
// NOTE: There's a subtle ordering issue here:
// - We have to compile the default parameter values before instantiating the function.
// - We have to instantiate the function before compiling the function body.
// This is why FunctionDeclarationInstantiation is invoked in the middle.
// The issue is that FunctionDeclarationInstantiation may mark certain functions as hoisted
// per Annex B. This affects code generation for FunctionDeclaration nodes.
2022-03-14 23:32:13 +03:30
2023-06-17 14:20:48 +02:00
if ( ! m_bytecode_executable ) {
2022-03-14 23:32:13 +03:30
size_t default_parameter_index = 0 ;
for ( auto & parameter : m_formal_parameters ) {
if ( ! parameter . default_value )
continue ;
2023-06-22 15:59:18 +02:00
auto executable = TRY ( Bytecode : : compile ( vm , * parameter . default_value , FunctionKind : : Normal , DeprecatedString : : formatted ( " default parameter #{} for {} " , default_parameter_index , m_name ) ) ) ;
2022-03-14 23:32:13 +03:30
m_default_parameter_bytecode_executables . append ( move ( executable ) ) ;
2021-06-07 15:19:48 +02:00
}
2021-06-07 15:17:37 +02:00
}
2023-06-17 14:20:48 +02:00
2023-06-26 21:34:08 +02:00
auto declaration_result = function_declaration_instantiation ( nullptr ) ;
2023-06-17 14:20:48 +02:00
2023-06-26 21:34:08 +02:00
if ( m_kind = = FunctionKind : : Normal | | m_kind = = FunctionKind : : Generator ) {
if ( declaration_result . is_error ( ) )
return declaration_result . release_error ( ) ;
}
if ( ! m_bytecode_executable )
2023-06-22 15:59:18 +02:00
m_bytecode_executable = TRY ( Bytecode : : compile ( vm , * m_ecmascript_code , m_kind , m_name ) ) ;
2023-06-26 21:34:08 +02:00
if ( m_kind = = FunctionKind : : Async | | m_kind = = FunctionKind : : AsyncGenerator ) {
if ( declaration_result . is_throw_completion ( ) ) {
auto promise_capability = MUST ( new_promise_capability ( vm , realm . intrinsics ( ) . promise_constructor ( ) ) ) ;
MUST ( call ( vm , * promise_capability - > reject ( ) , js_undefined ( ) , * declaration_result . throw_completion ( ) . value ( ) ) ) ;
return Completion { Completion : : Type : : Return , promise_capability - > promise ( ) , { } } ;
}
2023-06-17 14:20:48 +02:00
}
2023-06-22 15:59:18 +02:00
auto result_and_frame = bytecode_interpreter - > run_and_return_frame ( realm , * m_bytecode_executable , nullptr ) ;
2021-11-11 00:34:44 +03:30
VERIFY ( result_and_frame . frame ! = nullptr ) ;
2022-02-07 15:12:41 +01:00
if ( result_and_frame . value . is_error ( ) )
return result_and_frame . value . release_error ( ) ;
2021-11-17 13:00:38 +01:00
auto result = result_and_frame . value . release_value ( ) ;
2021-11-11 00:34:44 +03:30
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
// NOTE: Running the bytecode should eventually return a completion.
// Until it does, we assume "return" and include the undefined fallback from the call site.
2022-01-15 00:30:02 +01:00
if ( m_kind = = FunctionKind : : Normal )
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 { Completion : : Type : : Return , result . value_or ( js_undefined ( ) ) , { } } ;
2021-06-11 01:38:30 +04:30
2022-08-16 00:20:49 +01:00
auto generator_object = TRY ( GeneratorObject : : create ( realm , result , this , vm . running_execution_context ( ) . copy ( ) , move ( * result_and_frame . frame ) ) ) ;
2021-11-11 00:46:07 +03:30
// 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.
if ( m_kind = = FunctionKind : : Async )
2022-08-16 00:20:49 +01:00
return { Completion : : Type : : Return , TRY ( AsyncFunctionDriverWrapper : : create ( realm , generator_object ) ) , { } } ;
2021-11-11 00:46:07 +03:30
VERIFY ( m_kind = = FunctionKind : : Generator ) ;
2021-11-10 19:25:50 +03:30
return { Completion : : Type : : Return , generator_object , { } } ;
2021-06-05 15:53:36 +02:00
} else {
2021-11-09 20:39:22 +02:00
if ( m_kind = = FunctionKind : : Generator )
2022-08-16 20:33:17 +01:00
return vm . throw_completion < InternalError > ( ErrorType : : NotImplemented , " Generator function execution in AST interpreter " ) ;
2021-06-05 15:53:36 +02:00
OwnPtr < Interpreter > local_interpreter ;
2021-09-22 12:44:56 +02:00
Interpreter * ast_interpreter = vm . interpreter_if_exists ( ) ;
2021-06-05 15:53:36 +02:00
if ( ! ast_interpreter ) {
2022-08-16 00:20:49 +01:00
local_interpreter = Interpreter : : create_with_existing_realm ( realm ) ;
2021-06-05 15:53:36 +02:00
ast_interpreter = local_interpreter . ptr ( ) ;
}
2020-09-27 17:24:14 +02:00
2021-06-05 15:53:36 +02:00
VM : : InterpreterExecutionScope scope ( * ast_interpreter ) ;
2021-05-29 16:03:19 +04:30
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
// FunctionBody : FunctionStatementList
2022-01-15 00:30:02 +01:00
if ( m_kind = = FunctionKind : : Normal ) {
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
// 1. Perform ? FunctionDeclarationInstantiation(functionObject, argumentsList).
2021-11-09 20:39:22 +02:00
TRY ( function_declaration_instantiation ( ast_interpreter ) ) ;
2020-10-04 13:54:44 +02:00
2022-12-20 22:09:57 +01:00
// 2. Let result be result of evaluating FunctionStatementList.
auto result = m_ecmascript_code - > execute ( * ast_interpreter ) ;
// 3. Let env be the running execution context's LexicalEnvironment.
2023-02-26 16:09:02 -07:00
auto env = vm . running_execution_context ( ) . lexical_environment ;
VERIFY ( is < DeclarativeEnvironment > ( * env ) ) ;
2022-12-20 22:09:57 +01:00
// 4. Return ? DisposeResources(env, result).
2023-02-26 16:09:02 -07:00
return dispose_resources ( vm , static_cast < DeclarativeEnvironment * > ( env . ptr ( ) ) , result ) ;
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
}
// AsyncFunctionBody : FunctionBody
else if ( m_kind = = FunctionKind : : Async ) {
2021-11-09 20:39:22 +02:00
// 1. Let promiseCapability be ! NewPromiseCapability(%Promise%).
2022-08-27 00:54:55 +01:00
auto promise_capability = MUST ( new_promise_capability ( vm , realm . intrinsics ( ) . promise_constructor ( ) ) ) ;
2021-11-09 20:39:22 +02:00
2022-05-02 20:54:39 +02:00
// 2. Let declResult be Completion(FunctionDeclarationInstantiation(functionObject, argumentsList)).
2021-11-09 20:39:22 +02:00
auto declaration_result = function_declaration_instantiation ( ast_interpreter ) ;
2022-05-02 20:54:39 +02:00
// 3. If declResult is an abrupt completion, then
if ( declaration_result . is_throw_completion ( ) ) {
// a. Perform ! Call(promiseCapability.[[Reject]], undefined, « declResult.[[Value]] »).
2022-10-02 12:11:30 +01:00
MUST ( call ( vm , * promise_capability - > reject ( ) , js_undefined ( ) , * declaration_result . throw_completion ( ) . value ( ) ) ) ;
2021-11-09 20:39:22 +02:00
}
// 4. Else,
else {
2022-05-02 20:54:39 +02:00
// a. Perform AsyncFunctionStart(promiseCapability, FunctionBody).
async_function_start ( promise_capability ) ;
2021-11-09 20:39:22 +02:00
}
2022-05-01 01:24:05 +02:00
// 5. Return Completion Record { [[Type]]: return, [[Value]]: promiseCapability.[[Promise]], [[Target]]: empty }.
2022-10-02 12:11:30 +01:00
return Completion { Completion : : Type : : Return , promise_capability - > promise ( ) , { } } ;
2021-11-09 20:39:22 +02:00
}
2020-08-25 12:52:32 +02: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
VERIFY_NOT_REACHED ( ) ;
2020-04-01 18:31:24 +01:00
}
2023-01-08 19:23:00 -05:00
void ECMAScriptFunctionObject : : set_name ( DeprecatedFlyString const & name )
2020-04-04 14:34:27 +01:00
{
2021-07-05 18:02:27 +03:00
VERIFY ( ! name . is_null ( ) ) ;
auto & vm = this - > vm ( ) ;
m_name = name ;
2022-12-06 22:17:27 +00:00
MUST ( define_property_or_throw ( vm . names . name , { . value = PrimitiveString : : create ( vm , m_name ) , . writable = false , . enumerable = false , . configurable = true } ) ) ;
2020-04-04 14:34:27 +01:00
}
2020-03-13 10:08:52 +01:00
}