2020-04-19 20:03:02 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2020, Jack Karamanian <karamanian.jack@gmail.com>
|
2022-04-30 23:14:59 +00:00
|
|
|
* Copyright (c) 2021-2022, Linus Groh <linusg@serenityos.org>
|
2020-04-19 20:03:02 +00:00
|
|
|
*
|
2021-04-22 08:24:48 +00:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-04-19 20:03:02 +00: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 19:37:21 +00:00
|
|
|
#include <LibJS/Runtime/AbstractOperations.h>
|
2020-04-19 20:03:02 +00:00
|
|
|
#include <LibJS/Runtime/BoundFunction.h>
|
|
|
|
#include <LibJS/Runtime/GlobalObject.h>
|
|
|
|
|
|
|
|
namespace JS {
|
|
|
|
|
2024-11-14 15:01:23 +00:00
|
|
|
GC_DEFINE_ALLOCATOR(BoundFunction);
|
2023-11-19 08:45:05 +00:00
|
|
|
|
2022-04-11 18:44:56 +00:00
|
|
|
// 10.4.1.3 BoundFunctionCreate ( targetFunction, boundThis, boundArgs ), https://tc39.es/ecma262/#sec-boundfunctioncreate
|
2024-11-14 15:01:23 +00:00
|
|
|
ThrowCompletionOr<GC::Ref<BoundFunction>> BoundFunction::create(Realm& realm, FunctionObject& target_function, Value bound_this, Vector<Value> bound_arguments)
|
2022-02-09 19:41:23 +00:00
|
|
|
{
|
|
|
|
// 1. Let proto be ? targetFunction.[[GetPrototypeOf]]().
|
|
|
|
auto* prototype = TRY(target_function.internal_get_prototype_of());
|
|
|
|
|
2022-04-30 23:14:59 +00:00
|
|
|
// 2. Let internalSlotsList be the list-concatenation of « [[Prototype]], [[Extensible]] » and the internal slots listed in Table 34.
|
2022-05-02 18:54:39 +00:00
|
|
|
// 3. Let obj be MakeBasicObject(internalSlotsList).
|
2022-02-09 19:41:23 +00:00
|
|
|
// 4. Set obj.[[Prototype]] to proto.
|
|
|
|
// 5. Set obj.[[Call]] as described in 10.4.1.1.
|
|
|
|
// 6. If IsConstructor(targetFunction) is true, then
|
|
|
|
// a. Set obj.[[Construct]] as described in 10.4.1.2.
|
|
|
|
// 7. Set obj.[[BoundTargetFunction]] to targetFunction.
|
|
|
|
// 8. Set obj.[[BoundThis]] to boundThis.
|
|
|
|
// 9. Set obj.[[BoundArguments]] to boundArgs.
|
2024-11-13 16:50:17 +00:00
|
|
|
auto object = realm.create<BoundFunction>(realm, target_function, bound_this, move(bound_arguments), prototype);
|
2022-02-09 19:41:23 +00:00
|
|
|
|
|
|
|
// 10. Return obj.
|
2022-12-14 17:40:33 +00:00
|
|
|
return object;
|
2022-02-09 19:41:23 +00:00
|
|
|
}
|
|
|
|
|
2022-08-15 23:20:49 +00:00
|
|
|
BoundFunction::BoundFunction(Realm& realm, FunctionObject& bound_target_function, Value bound_this, Vector<Value> bound_arguments, Object* prototype)
|
|
|
|
: FunctionObject(realm, prototype)
|
2021-09-24 22:16:39 +00:00
|
|
|
, m_bound_target_function(&bound_target_function)
|
2021-09-24 22:38:23 +00:00
|
|
|
, m_bound_this(bound_this)
|
|
|
|
, m_bound_arguments(move(bound_arguments))
|
2022-02-09 19:41:23 +00:00
|
|
|
// FIXME: Non-standard and redundant, remove.
|
2023-12-16 14:19:34 +00:00
|
|
|
, m_name(ByteString::formatted("bound {}", bound_target_function.name()))
|
2020-06-20 15:11:11 +00:00
|
|
|
{
|
2020-04-19 20:03:02 +00: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 19:37:21 +00:00
|
|
|
// 10.4.1.1 [[Call]] ( thisArgument, argumentsList ), https://tc39.es/ecma262/#sec-bound-function-exotic-objects-call-thisargument-argumentslist
|
2023-11-27 11:56:20 +00:00
|
|
|
ThrowCompletionOr<Value> BoundFunction::internal_call([[maybe_unused]] Value this_argument, ReadonlySpan<Value> arguments_list)
|
2020-04-19 20:03:02 +00:00
|
|
|
{
|
2022-08-21 18:24:32 +00:00
|
|
|
auto& vm = this->vm();
|
|
|
|
|
LibJS: Implement [[Call]] and [[Construct]] internal slots properly
This patch implements:
- Spec compliant [[Call]] and [[Construct]] internal slots, as virtual
FunctionObject::internal_{call,construct}(). These effectively replace
the old virtual FunctionObject::{call,construct}(), but with several
advantages:
- Clear and consistent naming, following the object internal methods
- Use of completions
- internal_construct() returns an Object, and not Value! This has been
a source of confusion for a long time, since in the spec there's
always an Object returned but the Value return type in LibJS meant
that this could not be fully trusted and something could screw you
over.
- Arguments are passed explicitly in form of a MarkedValueList,
allowing manipulation (BoundFunction). We still put them on the
execution context as a lot of code depends on it (VM::arguments()),
but not from the Call() / Construct() AOs anymore, which now allows
for bypassing them and invoking [[Call]] / [[Construct]] directly.
Nothing but Call() / Construct() themselves do that at the moment,
but future additions to ECMA262 or already existing web specs might.
- Spec compliant, standalone Call() and Construct() AOs: currently the
closest we have is VM::{call,construct}(), but those try to cater to
all the different function object subclasses at once, resulting in a
horrible mess and calling AOs with functions they should never be
called with; most prominently PrepareForOrdinaryCall and
OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject.
As a result this also contains an implicit optimization: we no longer
need to create a new function environment for NativeFunctions - which,
worth mentioning, is what started this whole crusade in the first place
:^)
2021-10-08 19:37:21 +00:00
|
|
|
// 1. Let target be F.[[BoundTargetFunction]].
|
|
|
|
auto& target = *m_bound_target_function;
|
|
|
|
|
|
|
|
// 2. Let boundThis be F.[[BoundThis]].
|
|
|
|
auto bound_this = m_bound_this;
|
|
|
|
|
|
|
|
// 3. Let boundArgs be F.[[BoundArguments]].
|
|
|
|
auto& bound_args = m_bound_arguments;
|
|
|
|
|
|
|
|
// 4. Let args be the list-concatenation of boundArgs and argumentsList.
|
2023-11-27 11:56:20 +00:00
|
|
|
Vector<Value> args;
|
|
|
|
args.ensure_capacity(bound_args.size() + arguments_list.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 19:37:21 +00:00
|
|
|
args.extend(bound_args);
|
2023-11-27 11:56:20 +00:00
|
|
|
args.append(arguments_list.data(), arguments_list.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 19:37:21 +00:00
|
|
|
|
|
|
|
// 5. Return ? Call(target, boundThis, args).
|
2023-11-27 11:56:20 +00:00
|
|
|
return call(vm, &target, bound_this, args.span());
|
2020-04-19 20:03:02 +00: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 19:37:21 +00:00
|
|
|
// 10.4.1.2 [[Construct]] ( argumentsList, newTarget ), https://tc39.es/ecma262/#sec-bound-function-exotic-objects-construct-argumentslist-newtarget
|
2024-11-14 15:01:23 +00:00
|
|
|
ThrowCompletionOr<GC::Ref<Object>> BoundFunction::internal_construct(ReadonlySpan<Value> arguments_list, FunctionObject& new_target)
|
2020-04-19 20:03:02 +00:00
|
|
|
{
|
2022-08-21 18:24:32 +00:00
|
|
|
auto& vm = this->vm();
|
|
|
|
|
LibJS: Implement [[Call]] and [[Construct]] internal slots properly
This patch implements:
- Spec compliant [[Call]] and [[Construct]] internal slots, as virtual
FunctionObject::internal_{call,construct}(). These effectively replace
the old virtual FunctionObject::{call,construct}(), but with several
advantages:
- Clear and consistent naming, following the object internal methods
- Use of completions
- internal_construct() returns an Object, and not Value! This has been
a source of confusion for a long time, since in the spec there's
always an Object returned but the Value return type in LibJS meant
that this could not be fully trusted and something could screw you
over.
- Arguments are passed explicitly in form of a MarkedValueList,
allowing manipulation (BoundFunction). We still put them on the
execution context as a lot of code depends on it (VM::arguments()),
but not from the Call() / Construct() AOs anymore, which now allows
for bypassing them and invoking [[Call]] / [[Construct]] directly.
Nothing but Call() / Construct() themselves do that at the moment,
but future additions to ECMA262 or already existing web specs might.
- Spec compliant, standalone Call() and Construct() AOs: currently the
closest we have is VM::{call,construct}(), but those try to cater to
all the different function object subclasses at once, resulting in a
horrible mess and calling AOs with functions they should never be
called with; most prominently PrepareForOrdinaryCall and
OrdinaryCallBindThis, which are only for ECMAScriptFunctionObject.
As a result this also contains an implicit optimization: we no longer
need to create a new function environment for NativeFunctions - which,
worth mentioning, is what started this whole crusade in the first place
:^)
2021-10-08 19:37:21 +00:00
|
|
|
// 1. Let target be F.[[BoundTargetFunction]].
|
|
|
|
auto& target = *m_bound_target_function;
|
|
|
|
|
|
|
|
// 2. Assert: IsConstructor(target) is true.
|
|
|
|
VERIFY(Value(&target).is_constructor());
|
|
|
|
|
|
|
|
// 3. Let boundArgs be F.[[BoundArguments]].
|
|
|
|
auto& bound_args = m_bound_arguments;
|
|
|
|
|
|
|
|
// 4. Let args be the list-concatenation of boundArgs and argumentsList.
|
2024-11-14 15:01:23 +00:00
|
|
|
auto args = GC::MarkedVector<Value> { heap() };
|
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 19:37:21 +00:00
|
|
|
args.extend(bound_args);
|
2023-11-27 11:56:20 +00:00
|
|
|
args.append(arguments_list.data(), arguments_list.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 19:37:21 +00:00
|
|
|
|
|
|
|
// 5. If SameValue(F, newTarget) is true, set newTarget to target.
|
|
|
|
auto* final_new_target = &new_target;
|
|
|
|
if (this == &new_target)
|
|
|
|
final_new_target = ⌖
|
|
|
|
|
|
|
|
// 6. Return ? Construct(target, args, newTarget).
|
2023-11-27 11:56:20 +00:00
|
|
|
return construct(vm, target, args.span(), final_new_target);
|
2020-04-19 20:03:02 +00:00
|
|
|
}
|
|
|
|
|
2020-11-28 13:33:36 +00:00
|
|
|
void BoundFunction::visit_edges(Visitor& visitor)
|
2020-04-19 20:03:02 +00:00
|
|
|
{
|
2021-06-27 19:48:34 +00:00
|
|
|
Base::visit_edges(visitor);
|
2021-09-24 22:38:23 +00:00
|
|
|
|
2021-09-24 22:16:39 +00:00
|
|
|
visitor.visit(m_bound_target_function);
|
2021-09-24 22:38:23 +00:00
|
|
|
visitor.visit(m_bound_this);
|
2024-04-15 11:58:21 +00:00
|
|
|
visitor.visit(m_bound_arguments);
|
2020-04-19 20:03:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|