2020-03-13 10:08:52 +01:00
|
|
|
/*
|
2021-06-27 22:15:58 +02:00
|
|
|
* Copyright (c) 2020-2021, 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
|
|
|
*/
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
2020-05-02 11:46:39 -07:00
|
|
|
#include <LibJS/AST.h>
|
2021-06-09 06:49:58 +04:30
|
|
|
#include <LibJS/Bytecode/Generator.h>
|
2021-06-27 21:48:34 +02:00
|
|
|
#include <LibJS/Runtime/FunctionObject.h>
|
2020-03-13 10:08:52 +01:00
|
|
|
|
|
|
|
namespace JS {
|
|
|
|
|
2021-09-24 22:40:38 +02:00
|
|
|
// 10.2 ECMAScript Function Objects, https://tc39.es/ecma262/#sec-ecmascript-function-objects
|
|
|
|
class ECMAScriptFunctionObject final : public FunctionObject {
|
|
|
|
JS_OBJECT(ECMAScriptFunctionObject, FunctionObject);
|
2020-06-21 15:14:02 +02:00
|
|
|
|
2020-03-13 10:08:52 +01:00
|
|
|
public:
|
2021-09-24 23:34:13 +02:00
|
|
|
enum class ConstructorKind : u8 {
|
|
|
|
Base,
|
|
|
|
Derived,
|
|
|
|
};
|
|
|
|
|
2021-09-24 23:19:36 +02:00
|
|
|
enum class ThisMode : u8 {
|
|
|
|
Lexical,
|
|
|
|
Strict,
|
|
|
|
Global,
|
|
|
|
};
|
|
|
|
|
2021-10-11 20:29:31 +02:00
|
|
|
static ECMAScriptFunctionObject* create(GlobalObject&, FlyString name, Statement const& ecmascript_code, Vector<FunctionNode::Parameter> parameters, i32 m_function_length, Environment* parent_scope, PrivateEnvironment* private_scope, FunctionKind, bool is_strict, bool might_need_arguments_object = true, bool contains_direct_call_to_eval = true, bool is_arrow_function = false);
|
2020-04-17 19:59:32 +02:00
|
|
|
|
2021-10-11 20:29:31 +02:00
|
|
|
ECMAScriptFunctionObject(FlyString name, Statement const& ecmascript_code, Vector<FunctionNode::Parameter> parameters, i32 m_function_length, Environment* parent_scope, PrivateEnvironment* private_scope, Object& prototype, FunctionKind, bool is_strict, bool might_need_arguments_object, bool contains_direct_call_to_eval, bool is_arrow_function);
|
2020-07-22 17:50:18 +02:00
|
|
|
virtual void initialize(GlobalObject&) override;
|
2021-09-24 22:40:38 +02:00
|
|
|
virtual ~ECMAScriptFunctionObject();
|
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
|
|
|
virtual ThrowCompletionOr<Value> internal_call(Value this_argument, MarkedValueList arguments_list) override;
|
|
|
|
virtual ThrowCompletionOr<Object*> internal_construct(MarkedValueList arguments_list, FunctionObject& new_target) override;
|
|
|
|
|
2021-09-24 23:10:21 +02:00
|
|
|
Statement const& ecmascript_code() const { return m_ecmascript_code; }
|
|
|
|
Vector<FunctionNode::Parameter> const& formal_parameters() const { return m_formal_parameters; };
|
2020-03-13 10:08:52 +01:00
|
|
|
|
2020-04-11 12:56:20 +01:00
|
|
|
virtual const FlyString& name() const override { return m_name; };
|
2021-07-05 18:02:27 +03:00
|
|
|
void set_name(const FlyString& name);
|
2020-04-11 12:56:20 +01:00
|
|
|
|
2020-11-11 21:37:40 +00:00
|
|
|
void set_is_class_constructor() { m_is_class_constructor = true; };
|
|
|
|
|
2021-06-11 01:38:30 +04:30
|
|
|
auto& bytecode_executable() const { return m_bytecode_executable; }
|
|
|
|
|
2021-09-25 09:10:22 +02:00
|
|
|
Environment* environment() { return m_environment; }
|
2021-09-11 21:42:01 +01:00
|
|
|
virtual Realm* realm() const override { return m_realm; }
|
2021-06-30 17:54:47 +03:00
|
|
|
|
2021-09-24 23:34:13 +02:00
|
|
|
ConstructorKind constructor_kind() const { return m_constructor_kind; };
|
|
|
|
void set_constructor_kind(ConstructorKind constructor_kind) { m_constructor_kind = constructor_kind; }
|
|
|
|
|
2021-09-24 23:19:36 +02:00
|
|
|
ThisMode this_mode() const { return m_this_mode; }
|
|
|
|
|
2021-09-24 23:49:24 +02:00
|
|
|
Object* home_object() const { return m_home_object; }
|
|
|
|
void set_home_object(Object* home_object) { m_home_object = home_object; }
|
|
|
|
|
2021-09-25 00:01:09 +02:00
|
|
|
struct InstanceField {
|
2021-10-12 22:45:52 +02:00
|
|
|
Variant<PropertyName, PrivateName> name;
|
2021-09-25 00:01:09 +02:00
|
|
|
ECMAScriptFunctionObject* initializer { nullptr };
|
|
|
|
};
|
|
|
|
|
|
|
|
Vector<InstanceField> const& fields() const { return m_fields; }
|
2021-10-12 22:45:52 +02:00
|
|
|
void add_field(Variant<PropertyName, PrivateName> property_key, ECMAScriptFunctionObject* initializer);
|
|
|
|
|
|
|
|
Vector<PrivateElement> const& private_methods() const { return m_private_methods; }
|
|
|
|
void add_private_method(PrivateElement method) { m_private_methods.append(move(method)); };
|
2021-09-25 00:01:09 +02:00
|
|
|
|
2021-09-25 00:10:09 +02:00
|
|
|
// This is for IsSimpleParameterList (static semantics)
|
|
|
|
bool has_simple_parameter_list() const { return m_has_simple_parameter_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
|
|
|
// Equivalent to absence of [[Construct]]
|
|
|
|
virtual bool has_constructor() const override { return !(m_is_arrow_function || m_kind == FunctionKind::Generator); }
|
2021-09-25 09:52:49 +02:00
|
|
|
|
2020-10-04 13:54:44 +02:00
|
|
|
protected:
|
2021-09-24 23:10:21 +02:00
|
|
|
virtual bool is_strict_mode() const final { return m_strict; }
|
2020-10-04 13:54:44 +02:00
|
|
|
|
2020-03-13 10:08:52 +01:00
|
|
|
private:
|
2021-09-24 22:40:38 +02:00
|
|
|
virtual bool is_ecmascript_function_object() const override { return true; }
|
2020-11-28 14:33:36 +01:00
|
|
|
virtual void visit_edges(Visitor&) override;
|
2020-03-13 10:08:52 +01:00
|
|
|
|
2021-10-08 21:14:22 +01:00
|
|
|
void prepare_for_ordinary_call(ExecutionContext& callee_context, Object* new_target);
|
2021-10-08 21:15:53 +01:00
|
|
|
void ordinary_call_bind_this(ExecutionContext&, Value 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
|
|
|
Completion ordinary_call_evaluate_body();
|
2021-10-08 21:14:22 +01:00
|
|
|
ThrowCompletionOr<void> function_declaration_instantiation(Interpreter*);
|
2020-11-11 21:37:40 +00:00
|
|
|
|
2021-09-24 23:10:21 +02:00
|
|
|
// Internal Slots of ECMAScript Function Objects, https://tc39.es/ecma262/#table-internal-slots-of-ecmascript-function-objects
|
2021-09-24 23:34:13 +02:00
|
|
|
Environment* m_environment { nullptr }; // [[Environment]]
|
2021-10-11 20:29:31 +02:00
|
|
|
PrivateEnvironment* m_private_environment { nullptr }; // [[PrivateEnvironment]]
|
2021-09-24 23:34:13 +02:00
|
|
|
Vector<FunctionNode::Parameter> const m_formal_parameters; // [[FormalParameters]]
|
|
|
|
NonnullRefPtr<Statement> m_ecmascript_code; // [[ECMAScriptCode]]
|
|
|
|
ConstructorKind m_constructor_kind { ConstructorKind::Base }; // [[ConstructorKind]]
|
|
|
|
Realm* m_realm { nullptr }; // [[Realm]]
|
|
|
|
ThisMode m_this_mode { ThisMode::Global }; // [[ThisMode]]
|
|
|
|
bool m_strict { false }; // [[Strict]]
|
2021-09-24 23:49:24 +02:00
|
|
|
Object* m_home_object { nullptr }; // [[HomeObject]]
|
2021-09-25 00:01:09 +02:00
|
|
|
Vector<InstanceField> m_fields; // [[Fields]]
|
2021-10-12 22:45:52 +02:00
|
|
|
Vector<PrivateElement> m_private_methods; // [[PrivateMethods]]
|
2021-09-24 23:34:13 +02:00
|
|
|
bool m_is_class_constructor { false }; // [[IsClassConstructor]]
|
2021-09-24 23:10:21 +02:00
|
|
|
|
2020-04-11 12:56:20 +01:00
|
|
|
FlyString m_name;
|
2021-06-09 09:11:20 +02:00
|
|
|
Optional<Bytecode::Executable> m_bytecode_executable;
|
2020-10-04 13:54:44 +02:00
|
|
|
i32 m_function_length { 0 };
|
2021-06-11 03:38:05 +04:30
|
|
|
FunctionKind m_kind { FunctionKind::Regular };
|
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
|
|
|
bool m_might_need_arguments_object { true };
|
2021-10-08 12:43:38 +02:00
|
|
|
bool m_contains_direct_call_to_eval { true };
|
2020-10-04 13:54:44 +02:00
|
|
|
bool m_is_arrow_function { false };
|
2021-09-25 00:10:09 +02:00
|
|
|
bool m_has_simple_parameter_list { false };
|
2020-03-13 10:08:52 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|