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

137 lines
4.8 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: Rename Environment Records so they match the spec :^) This patch makes the following name changes: - ScopeObject => EnvironmentRecord - LexicalEnvironment => DeclarativeEnvironmentRecord - WithScope => ObjectEnvironmentRecord
2021-06-21 23:17:24 +02:00
#include <LibJS/Runtime/EnvironmentRecord.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: 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
GlobalEnvironmentRecord& environment_record() { return *m_environment_record; }
LibJS: Add a scope object abstraction Both GlobalObject and LexicalEnvironment now inherit from ScopeObject, and the VM's call frames point to a ScopeObject chain rather than just a LexicalEnvironment chain. This gives us much more flexibility to implement things like "with", and also unifies some of the code paths that previously required special handling of the global object. There's a bunch of more cleanup that can be done in the wake of this change, and there might be some oversights in the handling of the "super" keyword, but this generally seems like a good architectural improvement. :^)
2020-11-28 16:02:27 +01: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
Console& console() { return *m_console; }
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; }
Shape* new_script_function_prototype_object_shape() { return m_new_script_function_prototype_object_shape; }
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
GeneratorObjectPrototype* generator_object_prototype() { return m_generator_object_prototype; }
LibJS: Correct behaviour of direct vs. indirect eval eval only has direct access to the local scope when accessed through the name eval. This includes locals named eval, because of course it does.
2021-06-19 20:13:53 -07:00
Function* eval_function() const { return m_eval_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: 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: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
void initialize_constructor(PropertyName const&, ConstructorType*&, Object* prototype);
LibJS: Add "name" property to functions
2020-05-02 19:18:55 +01:00
template<typename ConstructorType>
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
void add_constructor(PropertyName 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: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 13:55:34 +02:00
JS_DECLARE_NATIVE_FUNCTION(gc);
JS_DECLARE_NATIVE_FUNCTION(is_nan);
JS_DECLARE_NATIVE_FUNCTION(is_finite);
JS_DECLARE_NATIVE_FUNCTION(parse_float);
LibJS: Implement parseInt() Here's a reasonably faithful implementation of ECMAScript 2021 18.2.5. Some corner cases are not covered, I've left them as FIXME's in the included unit test. Also I had to tweak JS::Value::to_i32() to always convert infinity to zero, which is in accordance with ToInt32 AFAICT.
2020-12-05 13:51:09 +01:00
JS_DECLARE_NATIVE_FUNCTION(parse_int);
LibJS: Add naive implementation of eval() :^) This parses and executes a code string in the caller's lexical scope.
2021-03-14 16:20:01 +01:00
JS_DECLARE_NATIVE_FUNCTION(eval);
LibJS: Implement the encode/decodeURI(Component) family of functions These are generally useful and in particular needed for twitter.com
2021-04-13 22:50:29 +03:00
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);
LibJS: Add the global escape() & unescape() methods
2021-06-05 19:21:15 +03:00
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: 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 };
Shape* m_new_script_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
GeneratorObjectPrototype* m_generator_object_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
GlobalEnvironmentRecord* m_environment_record { 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
#define __JS_ENUMERATE(ClassName, snake_name) \
Object* m_##snake_name##_prototype { nullptr };
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Correct behaviour of direct vs. indirect eval eval only has direct access to the local scope when accessed through the name eval. This includes locals named eval, because of course it does.
2021-06-19 20:13:53 -07:00
Function* m_eval_function;
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: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
inline void GlobalObject::initialize_constructor(PropertyName 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: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
constructor->define_property(vm.names.name, js_string(heap(), property_name.as_string()), Attribute::Configurable);
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
if (vm.exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return;
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
if (prototype) {
prototype->define_property(vm.names.constructor, constructor, Attribute::Writable | Attribute::Configurable);
if (vm.exception())
return;
}
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: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
inline void GlobalObject::add_constructor(PropertyName 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: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
define_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 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