Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/GlobalObject.h

177 lines
7.2 KiB
C
Raw Normal View History

Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
*/
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
#pragma once
LibJS: Fix build (GlobalObject::add_constructor not visible in LibWeb)
2020-05-02 20:43:44 +02:00
#include <LibJS/Heap/Heap.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/Environment.h>
LibJS: Remove a whole bunch of includes of <LibJS/Interpreter.h>
2020-09-27 20:18:30 +02:00
#include <LibJS/Runtime/VM.h>
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
namespace JS {
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
class GlobalObject : public Object {
JS_OBJECT(GlobalObject, Object);
LibJS+LibWeb: Add JS::Object::inherits(class_name) To allow implementing the DOM class hierarchy in JS bindings, this patch adds an inherits() function that can be used to ask an Object if it inherits from a specific C++ class (by name). The necessary overrides are baked into each Object subclass by the new JS_OBJECT macro, which works similarly to C_OBJECT in LibCore. Thanks to @Dexesttp for suggesting this approach. :^)
2020-06-21 15:14:02 +02:00
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
public:
LibJS: Add Object::put_native_function() for convenience This makes it a little bit nicer to add native function properties to JavaScript objects. Thanks to Sergey for suggesting it! :^)
2020-03-13 11:06:32 +01:00
explicit GlobalObject();
LibJS: Rename GlobalObject::initialize() => initialize_global_object() This function was shadowing Object::initialize() which cannot be called on global objects and has a different set of parameters.
2021-03-17 16:52:26 +01:00
virtual void initialize_global_object();
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 13:18:06 +02:00
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
virtual ~GlobalObject() override;
LibJS: Move Console from Interpreter to GlobalObject Each JS global object has its own "console", so it makes more sense to store it in GlobalObject. We'll need some smartness later to bundle up console messages from all the different frames that make up a page later, but this works for now.
2020-09-29 21:15:06 +02:00
Console& console() { return *m_console; }
LibJS: Add a way to get from a GlobalObject to its associated Realm This is just another workaround, but it should be much more reliable than Interpreter::realm(), especially when allocating NativeFunctions and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject at that point, and it likely was set as the GlobalObject of a Realm and can lead us back to it. We're however not guaranteed that the VM can give us an Interpreter, which is why functions in LibWeb can be a bit crashy at the moment. We use a WeakPtr<Realm> to properly handle the unlikely case where the Realm goes away after associating a GlobalObject to it. We'll always need _something_ of this sort if we want to support OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit realm argument while no JS is running, because they want to use the current Realm Record (always in the first and as fallback in the second case).
2021-10-14 12:04:10 +01:00
Realm* associated_realm();
void set_associated_realm(Badge<Realm>, Realm&);
LibJS: Move the empty object shape from Interpreter to GlobalObject The big remaining hurdle before a GlobalObject-agnostic Interpreter is the fact that Interpreter owns and vends the GlobalObject :^)
2020-04-18 13:56:13 +02:00
Shape* empty_object_shape() { return m_empty_object_shape; }
LibJS: Prebake the empty object ({}) with a prototype Instead of performing a prototype transition for every new object we create via {}, prebake the object returned by Object::create_empty() with a shape with ObjectPrototype as the prototype. We also prebake the shape for the object assigned to the "prototype" property of new ScriptFunction objects, since those are extremely common and that code broke from this change anyway. This avoid a large number of transitions and is a small speed-up on test-js.
2020-10-17 23:13:37 +02:00
Shape* new_object_shape() { return m_new_object_shape; }
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
Shape* new_ordinary_function_prototype_object_shape() { return m_new_ordinary_function_prototype_object_shape; }
LibJS: Prebake the empty object ({}) with a prototype Instead of performing a prototype transition for every new object we create via {}, prebake the object returned by Object::create_empty() with a shape with ObjectPrototype as the prototype. We also prebake the shape for the object assigned to the "prototype" property of new ScriptFunction objects, since those are extremely common and that code broke from this change anyway. This avoid a large number of transitions and is a small speed-up on test-js.
2020-10-17 23:13:37 +02:00
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct prototype
ProxyConstructor* proxy_constructor() { return m_proxy_constructor; }
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct constructor
LibJS: Rename GeneratorObjectPrototype to GeneratorPrototype Given we usually call objects Foo{Object,Constructor,Prototype} or Foo{,Constructor,Prototype}, this name was an odd choice. The new one matches the spec better, which calls it the "Generator Prototype Object", so we simply omit the Object suffix as usual as it's implied.
2022-01-16 14:14:42 +01:00
GeneratorPrototype* generator_prototype() { return m_generator_prototype; }
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
AsyncFromSyncIteratorPrototype* async_from_sync_iterator_prototype() { return m_async_from_sync_iterator_prototype; }
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
LibJS: Store the %Array.prototype.values% intrinsic on the global object Also group the getter functions for all the additional intrinsics (not generated via macros), and initialize the members.
2021-07-25 19:37:42 +01:00
FunctionObject* array_prototype_values_function() const { return m_array_prototype_values_function; }
LibJS: Add an accessor for the %Date.now% instrinsic property
2021-12-04 18:56:44 -05:00
FunctionObject* date_constructor_now_function() const { return m_date_constructor_now_function; }
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
FunctionObject* eval_function() const { return m_eval_function; }
LibJS: Add and use the %ThrowTypeError% intrinsic
2021-06-28 03:53:35 +03:00
FunctionObject* throw_type_error_function() const { return m_throw_type_error_function; }
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 21:05:25 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 13:18:06 +02:00
ConstructorName* snake_name##_constructor() { return m_##snake_name##_constructor; } \
Object* snake_name##_prototype() { return m_##snake_name##_prototype; }
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 14:06:52 +02:00
JS_ENUMERATE_BUILTIN_TYPES
#undef __JS_ENUMERATE
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 18:35:29 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
Intl::ConstructorName* intl_##snake_name##_constructor() { return m_intl_##snake_name##_constructor; } \
Object* intl_##snake_name##_prototype() { return m_intl_##snake_name##_prototype; }
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 20:39:55 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
Temporal::ConstructorName* temporal_##snake_name##_constructor() { return m_temporal_##snake_name##_constructor; } \
Object* temporal_##snake_name##_prototype() { return m_temporal_##snake_name##_prototype; }
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Start implementing iterable framework, add ArrayIterator With the addition of symbol keys, work can now be done on starting to implement the well-known symbol functionality. The most important of these well-known symbols is by far Symbol.iterator. This patch adds IteratorPrototype, as well as ArrayIterator and ArrayIteratorPrototype. In the future, sometime after StringIterator has also been added, this will allow us to use Symbol.iterator directly in for..of loops, enabling the use of custom iterator objects. Also makes adding iterator support to native objects much easier (as will have to be done for Map and Set, when they get added).
2020-07-09 14:58:20 -07:00
#define __JS_ENUMERATE(ClassName, snake_name) \
Object* snake_name##_prototype() { return m_##snake_name##_prototype; }
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibWeb: Add XMLHttpRequest object :^) This patch adds very basic XMLHttpRequest support to LibWeb. Here's an example that currently works: var callback = function() { alert(this.responseText); } var xhr = new XMLHttpRequest(); xhr.addEventListener("load", callback); xhr.open("GET", "http://serenityos.org/~kling/test/example.txt"); xhr.send(); There are many limitations and bugs, but it's pretty dang awesome that we have XHR. :^)
2020-04-08 21:11:51 +02:00
protected:
LibJS: Rename Cell::visit_children() => Cell::visit_edges() The GC heap is really a graph of cells, so "children" didn't quite feel appropriate here.
2020-11-28 14:33:36 +01:00
virtual void visit_edges(Visitor&) override;
LibWeb: Add XMLHttpRequest object :^) This patch adds very basic XMLHttpRequest support to LibWeb. Here's an example that currently works: var callback = function() { alert(this.responseText); } var xhr = new XMLHttpRequest(); xhr.addEventListener("load", callback); xhr.open("GET", "http://serenityos.org/~kling/test/example.txt"); xhr.send(); There are many limitations and bugs, but it's pretty dang awesome that we have XHR. :^)
2020-04-08 21:11:51 +02:00
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
template<typename ConstructorType>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
void initialize_constructor(PropertyKey const&, ConstructorType*&, Object* prototype);
LibJS: Add "name" property to functions
2020-05-02 19:18:55 +01:00
template<typename ConstructorType>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
void add_constructor(PropertyKey const&, ConstructorType*&, Object* prototype);
LibJS: Add "name" property to functions
2020-05-02 19:18:55 +01:00
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
private:
LibJS: Add fast_is<T> for StringObject and GlobalObject Both of these are quite hot in profiles.
2021-03-19 11:28:44 +01:00
virtual bool is_global_object() const final { return true; }
LibJS: Convert GlobalObject to ThrowCompletionOr
2021-10-29 17:04:01 -04:00
JS_DECLARE_NATIVE_FUNCTION(gc);
JS_DECLARE_NATIVE_FUNCTION(is_nan);
JS_DECLARE_NATIVE_FUNCTION(is_finite);
JS_DECLARE_NATIVE_FUNCTION(parse_float);
JS_DECLARE_NATIVE_FUNCTION(parse_int);
JS_DECLARE_NATIVE_FUNCTION(eval);
JS_DECLARE_NATIVE_FUNCTION(encode_uri);
JS_DECLARE_NATIVE_FUNCTION(decode_uri);
JS_DECLARE_NATIVE_FUNCTION(encode_uri_component);
JS_DECLARE_NATIVE_FUNCTION(decode_uri_component);
JS_DECLARE_NATIVE_FUNCTION(escape);
JS_DECLARE_NATIVE_FUNCTION(unescape);
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
LibJS: Move Console from Interpreter to GlobalObject Each JS global object has its own "console", so it makes more sense to store it in GlobalObject. We'll need some smartness later to bundle up console messages from all the different frames that make up a page later, but this works for now.
2020-09-29 21:15:06 +02:00
NonnullOwnPtr<Console> m_console;
LibJS: Add a way to get from a GlobalObject to its associated Realm This is just another workaround, but it should be much more reliable than Interpreter::realm(), especially when allocating NativeFunctions and ECMAScriptFunctionObjects: we're guaranteed to have a GlobalObject at that point, and it likely was set as the GlobalObject of a Realm and can lead us back to it. We're however not guaranteed that the VM can give us an Interpreter, which is why functions in LibWeb can be a bit crashy at the moment. We use a WeakPtr<Realm> to properly handle the unlikely case where the Realm goes away after associating a GlobalObject to it. We'll always need _something_ of this sort if we want to support OrdinaryFunctionCreate and CreateBuiltinFunction without the explicit realm argument while no JS is running, because they want to use the current Realm Record (always in the first and as fallback in the second case).
2021-10-14 12:04:10 +01:00
WeakPtr<Realm> m_associated_realm;
LibJS: Move the empty object shape from Interpreter to GlobalObject The big remaining hurdle before a GlobalObject-agnostic Interpreter is the fact that Interpreter owns and vends the GlobalObject :^)
2020-04-18 13:56:13 +02:00
Shape* m_empty_object_shape { nullptr };
LibJS: Prebake the empty object ({}) with a prototype Instead of performing a prototype transition for every new object we create via {}, prebake the object returned by Object::create_empty() with a shape with ObjectPrototype as the prototype. We also prebake the shape for the object assigned to the "prototype" property of new ScriptFunction objects, since those are extremely common and that code broke from this change anyway. This avoid a large number of transitions and is a small speed-up on test-js.
2020-10-17 23:13:37 +02:00
Shape* m_new_object_shape { nullptr };
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
Shape* m_new_ordinary_function_prototype_object_shape { nullptr };
LibJS: Move the empty object shape from Interpreter to GlobalObject The big remaining hurdle before a GlobalObject-agnostic Interpreter is the fact that Interpreter owns and vends the GlobalObject :^)
2020-04-18 13:56:13 +02:00
LibJS: Remove ProxyPrototype Proxy is an "exotic object" and doesn't have its own prototype. Use the regular object prototype instead, but most stuff is happening on the target object anyway. :^)
2020-11-30 22:50:43 +00:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct prototype
ProxyConstructor* m_proxy_constructor { nullptr };
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
// Not included in JS_ENUMERATE_NATIVE_OBJECTS due to missing distinct constructor
LibJS: Rename GeneratorObjectPrototype to GeneratorPrototype Given we usually call objects Foo{Object,Constructor,Prototype} or Foo{,Constructor,Prototype}, this name was an odd choice. The new one matches the spec better, which calls it the "Generator Prototype Object", so we simply omit the Object suffix as usual as it's implied.
2022-01-16 14:14:42 +01:00
GeneratorPrototype* m_generator_prototype { nullptr };
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
AsyncFromSyncIteratorPrototype* m_async_from_sync_iterator_prototype { nullptr };
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
LibJS: Store the %Array.prototype.values% intrinsic on the global object Also group the getter functions for all the additional intrinsics (not generated via macros), and initialize the members.
2021-07-25 19:37:42 +01:00
FunctionObject* m_array_prototype_values_function { nullptr };
LibJS: Add an accessor for the %Date.now% instrinsic property
2021-12-04 18:56:44 -05:00
FunctionObject* m_date_constructor_now_function { nullptr };
LibJS: Store the %Array.prototype.values% intrinsic on the global object Also group the getter functions for all the additional intrinsics (not generated via macros), and initialize the members.
2021-07-25 19:37:42 +01:00
FunctionObject* m_eval_function { nullptr };
FunctionObject* m_throw_type_error_function { nullptr };
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 21:05:25 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName, ArrayType) \
ConstructorName* m_##snake_name##_constructor { nullptr }; \
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 13:18:06 +02:00
Object* m_##snake_name##_prototype { nullptr };
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 14:06:52 +02:00
JS_ENUMERATE_BUILTIN_TYPES
#undef __JS_ENUMERATE
LibJS: Start implementing iterable framework, add ArrayIterator With the addition of symbol keys, work can now be done on starting to implement the well-known symbol functionality. The most important of these well-known symbols is by far Symbol.iterator. This patch adds IteratorPrototype, as well as ArrayIterator and ArrayIteratorPrototype. In the future, sometime after StringIterator has also been added, this will allow us to use Symbol.iterator directly in for..of loops, enabling the use of custom iterator objects. Also makes adding iterator support to native objects much easier (as will have to be done for Map and Set, when they get added).
2020-07-09 14:58:20 -07:00
LibJS: Add preparation for Intl constructors and prototypes Add a JS_ENUMERATE_INTL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-08-08 18:35:29 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
Intl::ConstructorName* m_intl_##snake_name##_constructor { nullptr }; \
Object* m_intl_##snake_name##_prototype { nullptr };
JS_ENUMERATE_INTL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Add preparation for Temporal constructors and prototypes Add a JS_ENUMERATE_TEMPORAL_OBJECTS macro and use it to generate: - Forward declarations - CommonPropertyNames class name members - Constructor and prototype GlobalObject members, getters, visitors, and initialize_constructor() calls
2021-07-06 20:39:55 +01:00
#define __JS_ENUMERATE(ClassName, snake_name, PrototypeName, ConstructorName) \
Temporal::ConstructorName* m_temporal_##snake_name##_constructor { nullptr }; \
Object* m_temporal_##snake_name##_prototype { nullptr };
JS_ENUMERATE_TEMPORAL_OBJECTS
#undef __JS_ENUMERATE
LibJS: Start implementing iterable framework, add ArrayIterator With the addition of symbol keys, work can now be done on starting to implement the well-known symbol functionality. The most important of these well-known symbols is by far Symbol.iterator. This patch adds IteratorPrototype, as well as ArrayIterator and ArrayIteratorPrototype. In the future, sometime after StringIterator has also been added, this will allow us to use Symbol.iterator directly in for..of loops, enabling the use of custom iterator objects. Also makes adding iterator support to native objects much easier (as will have to be done for Map and Set, when they get added).
2020-07-09 14:58:20 -07:00
#define __JS_ENUMERATE(ClassName, snake_name) \
Object* m_##snake_name##_prototype { nullptr };
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
};
LibJS: Fix build (GlobalObject::add_constructor not visible in LibWeb)
2020-05-02 20:43:44 +02:00
template<typename ConstructorType>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
inline void GlobalObject::initialize_constructor(PropertyKey const& property_name, ConstructorType*& constructor, Object* prototype)
LibJS: Fix build (GlobalObject::add_constructor not visible in LibWeb)
2020-05-02 20:43:44 +02:00
{
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 23:49:19 +02:00
auto& vm = this->vm();
LibJS: Move native objects towards two-pass construction To make sure that everything is set up correctly in objects before we start adding properties to them, we split cell allocation into 3 steps: 1. Allocate a cell of appropriate size from the Heap 2. Call the C++ constructor on the cell 3. Call initialize() on the constructed object The job of initialize() is to define all the initial properties. Doing it in a second pass guarantees that the Object has a valid Shape and can find its own GlobalObject.
2020-06-20 15:40:48 +02:00
constructor = heap().allocate<ConstructorType>(*this, *this);
LibJS: Remove transition avoidance & start caching prototype transitions The way that transition avoidance (foo_without_transition) was implemented led to shapes being unshareable and caused shape explosion instead, precisely what we were trying to avoid. This patch removes all the attempts to avoid transitioning shapes, and instead *adds* transitions when changing an object's prototype. This makes transitions flow naturally, and as a result we end up with way fewer shape objects in real-world situations. When we run out of big problems, we can get back to avoiding transitions as an optimization, but for now, let's avoid ballooning our processes with a unique shape for every object.
2021-10-01 02:43:57 +02:00
constructor->define_direct_property(vm.names.name, js_string(heap(), property_name.as_string()), Attribute::Configurable);
LibJS: Remove redundant exception checks from initialize_constructor() define_direct_property() simply wraps storage_set(), which cannot throw.
2021-11-14 12:21:48 +00:00
if (prototype)
LibJS: Remove transition avoidance & start caching prototype transitions The way that transition avoidance (foo_without_transition) was implemented led to shapes being unshareable and caused shape explosion instead, precisely what we were trying to avoid. This patch removes all the attempts to avoid transitioning shapes, and instead *adds* transitions when changing an object's prototype. This makes transitions flow naturally, and as a result we end up with way fewer shape objects in real-world situations. When we run out of big problems, we can get back to avoiding transitions as an optimization, but for now, let's avoid ballooning our processes with a unique shape for every object.
2021-10-01 02:43:57 +02:00
prototype->define_direct_property(vm.names.constructor, constructor, Attribute::Writable | Attribute::Configurable);
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
}
template<typename ConstructorType>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
inline void GlobalObject::add_constructor(PropertyKey const& property_name, ConstructorType*& constructor, Object* prototype)
LibJS: Clean up TypedArray constructors and prototypes The current implementation is not entirely correct yet. Two classes have been added: - TypedArrayConstructor, which the various typed array constructors now inherit from. Calling or constructing this class (from JS, that is) directly is not possible, we might want to move this abstract class functionality to NativeFunction at a later point. - TypedArrayPrototype, which the various typed array prototypes now have as their own prototype. This will be the place where most of the functionality is being shared. Relevant parts from the spec: 22.2.1 The %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - is a constructor function object that all of the TypedArray constructor objects inherit from. - along with its corresponding prototype object, provides common properties that are inherited by all TypedArray constructors and their instances. 22.2.2 Properties of the %TypedArray% Intrinsic Object The %TypedArray% intrinsic object: - has a [[Prototype]] internal slot whose value is %Function.prototype%. 22.2.2.3 %TypedArray%.prototype The initial value of %TypedArray%.prototype is the %TypedArray% prototype object. 22.2.6 Properties of the TypedArray Constructors Each TypedArray constructor: - has a [[Prototype]] internal slot whose value is %TypedArray%. 22.2.6.2 TypedArray.prototype The initial value of TypedArray.prototype is the corresponding TypedArray prototype intrinsic object (22.2.7). 22.2.7 Properties of the TypedArray Prototype Objects Each TypedArray prototype object: - has a [[Prototype]] internal slot whose value is %TypedArray.prototype%. 22.2.7.2 TypedArray.prototype.constructor The initial value of a TypedArray.prototype.constructor is the corresponding %TypedArray% intrinsic object.
2020-12-02 00:23:40 +00:00
{
LibJS: Only initialize in add_constructor() if not already done
2021-06-11 18:03:24 +01:00
// Some constructors are pre-initialized separately.
if (!constructor)
initialize_constructor(property_name, constructor, prototype);
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
define_direct_property(property_name, constructor, Attribute::Writable | Attribute::Configurable);
LibJS: Fix build (GlobalObject::add_constructor not visible in LibWeb)
2020-05-02 20:43:44 +02:00
}
LibJS: Fix UB downcast during GlobalObject construction When constructing a GlobalObject, it has to pass itself as the global object to its own Shape. Since this is done in the Object constructor, and Object is a base class of GlobalObject, it's not yet valid to cast "this" to a GlobalObject*. Fix this by having Shape store the global object as an Object& and move Shape::global_object() to GlobalObject.h where we can at least perform a valid static_cast in the getter. Found by oss-fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29267
2021-01-05 12:02:59 +01:00
inline GlobalObject* Shape::global_object() const
{
return static_cast<GlobalObject*>(m_global_object);
}
LibJS: Add fast_is<T> for StringObject and GlobalObject Both of these are quite hot in profiles.
2021-03-19 11:28:44 +01:00
template<>
inline bool Object::fast_is<GlobalObject>() const { return is_global_object(); }
LibJS: Move Object::invoke to Value::invoke and fix it for primitives This is a tiny difference and only changes anything for primitives in strict mode. However this is tested in test262 and can be noticed by overriding toString of primitive values. This does now require one to wrap an object in a Value to call invoke but all code using invoke has been migrated.
2021-08-09 16:45:43 +02:00
template<typename... Args>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
[[nodiscard]] ALWAYS_INLINE ThrowCompletionOr<Value> Value::invoke(GlobalObject& global_object, PropertyKey const& property_name, Args... args)
LibJS: Move Object::invoke to Value::invoke and fix it for primitives This is a tiny difference and only changes anything for primitives in strict mode. However this is tested in test262 and can be noticed by overriding toString of primitive values. This does now require one to wrap an object in a Value to call invoke but all code using invoke has been migrated.
2021-08-09 16:45:43 +02:00
{
if constexpr (sizeof...(Args) > 0) {
MarkedValueList arglist { global_object.vm().heap() };
(..., arglist.append(move(args)));
return invoke_internal(global_object, property_name, move(arglist));
}
return invoke_internal(global_object, property_name, Optional<MarkedValueList> {});
}
LibJS: Move GlobalObject to its own Object subclass This is mostly for tidiness at the moment.
2020-03-12 20:11:35 +01:00
}
Reference in a new issue Copy permalink