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

195 lines
8.3 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>
LibJS: Use Object* for 'manual' GlobalObject::foo_prototype() getters Not doing so only leads to problems down the line, e.g. not being able to pass them as function pointers to ordinary_create_from_constructor().
2022-05-05 20:43:51 +02:00
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
*
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: Use Object* for 'manual' GlobalObject::foo_prototype() getters Not doing so only leads to problems down the line, e.g. not being able to pass them as function pointers to ordinary_create_from_constructor().
2022-05-05 20:43:51 +02:00
Object* async_from_sync_iterator_prototype() { return m_async_from_sync_iterator_prototype; }
LibJS: Add AsyncGenerator / AsyncGeneratorPrototype Not implementing any prototype functions yet, but stubbing out async generator infrastructure will allow us to make some progress in that direction.
2022-05-05 08:47:36 +02:00
Object* async_generator_prototype() { return m_async_generator_prototype; }
LibJS: Use Object* for 'manual' GlobalObject::foo_prototype() getters Not doing so only leads to problems down the line, e.g. not being able to pass them as function pointers to ordinary_create_from_constructor().
2022-05-05 20:43:51 +02:00
Object* generator_prototype() { return m_generator_prototype; }
LibJS: Add the remaining generator objects - %GeneratorFunction% - %GeneratorFunction.prototype% - %GeneratorFunction.prototype.prototype% - %Generator%.prototype
2021-06-15 00:04:08 -07:00
LibJS: Add getters for %{Async,}GeneratorFunction.prototype.prototype% These exist as {Async,}GeneratorPrototype of course, but the spec doesn't always refer to them by the direct name.
2022-05-05 08:49:46 +02:00
// Alias for the AsyncGenerator Prototype Object used by the spec (%AsyncGeneratorFunction.prototype.prototype%)
Object* async_generator_function_prototype_prototype() { return m_async_generator_prototype; }
// Alias for the Generator Prototype Object used by the spec (%GeneratorFunction.prototype.prototype%)
Object* generator_function_prototype_prototype() { return m_generator_prototype; }
LibJS: Start implementing Intl Segments objects
2022-01-30 01:08:42 +02:00
// Not included in JS_ENUMERATE_INTL_OBJECTS due to missing distinct constructor
LibJS: Use Object* for 'manual' GlobalObject::foo_prototype() getters Not doing so only leads to problems down the line, e.g. not being able to pass them as function pointers to ordinary_create_from_constructor().
2022-05-05 20:43:51 +02:00
Object* intl_segments_prototype() { return m_intl_segments_prototype; }
LibJS: Start implementing Intl Segments objects
2022-01-30 01:08:42 +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* 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: Expose JSON.parse as an intrinsic value of the global object This will allow us to safely call it if we need to parse JSON within LibJS.
2022-01-27 14:49:55 +01:00
FunctionObject* json_parse_function() const { return m_json_parse_function; }
LibJS: Pass this value to fallback func in Array.prototype.toString() The existing code looks innocently correct, implementing the following step: 3. If IsCallable(func) is false, set func to the intrinsic function %Object.prototype.toString%. as return ObjectPrototype::to_string(vm, global_object); However, this misses the fact that the next step calls the function with the previously ToObject()'d this value (`array`): 4. Return ? Call(func, array). This doesn't happen in the current implementation, which will use the unaltered this value from the Array.prototype.toString() call, and make another, unequal object in %Object.prototype.toString%. Since both that and Array.prototype.toString() do a Get() call on said object, this behavior is observable (see newly added test). Fix this by actually doing what the spec says and calling the fallback function the regular way.
2022-04-11 22:47:50 +01:00
FunctionObject* object_prototype_to_string_function() const { return m_object_prototype_to_string_function; }
FunctionObject* throw_type_error_function() const { return m_throw_type_error_function; }
LibJS: Add and use the %ThrowTypeError% intrinsic
2021-06-28 03:53:35 +03:00
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: Initialize {Async,}{Generator,}Function constructors properly We were previously manually initializing them instead of just calling GlobalObject::initialize_constructor, which aside from duplicating code also meant we didn't set the required name property.
2022-02-19 17:49:25 +02:00
void initialize_constructor(PropertyKey const&, ConstructorType*&, Object* prototype, PropertyAttributes = Attribute::Writable | Attribute::Configurable);
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: Use Object* for 'manual' GlobalObject::foo_prototype() getters Not doing so only leads to problems down the line, e.g. not being able to pass them as function pointers to ordinary_create_from_constructor().
2022-05-05 20:43:51 +02:00
Object* m_async_from_sync_iterator_prototype { nullptr };
LibJS: Add AsyncGenerator / AsyncGeneratorPrototype Not implementing any prototype functions yet, but stubbing out async generator infrastructure will allow us to make some progress in that direction.
2022-05-05 08:47:36 +02:00
Object* m_async_generator_prototype { nullptr };
LibJS: Use Object* for 'manual' GlobalObject::foo_prototype() getters Not doing so only leads to problems down the line, e.g. not being able to pass them as function pointers to ordinary_create_from_constructor().
2022-05-05 20:43:51 +02:00
Object* m_generator_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: Start implementing Intl Segments objects
2022-01-30 01:08:42 +02:00
// Not included in JS_ENUMERATE_INTL_OBJECTS due to missing distinct constructor
LibJS: Use Object* for 'manual' GlobalObject::foo_prototype() getters Not doing so only leads to problems down the line, e.g. not being able to pass them as function pointers to ordinary_create_from_constructor().
2022-05-05 20:43:51 +02:00
Object* m_intl_segments_prototype { nullptr };
LibJS: Start implementing Intl Segments objects
2022-01-30 01:08:42 +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 };
LibJS: Expose JSON.parse as an intrinsic value of the global object This will allow us to safely call it if we need to parse JSON within LibJS.
2022-01-27 14:49:55 +01:00
FunctionObject* m_json_parse_function { nullptr };
LibJS: Pass this value to fallback func in Array.prototype.toString() The existing code looks innocently correct, implementing the following step: 3. If IsCallable(func) is false, set func to the intrinsic function %Object.prototype.toString%. as return ObjectPrototype::to_string(vm, global_object); However, this misses the fact that the next step calls the function with the previously ToObject()'d this value (`array`): 4. Return ? Call(func, array). This doesn't happen in the current implementation, which will use the unaltered this value from the Array.prototype.toString() call, and make another, unequal object in %Object.prototype.toString%. Since both that and Array.prototype.toString() do a Get() call on said object, this behavior is observable (see newly added test). Fix this by actually doing what the spec says and calling the fallback function the regular way.
2022-04-11 22:47:50 +01:00
FunctionObject* m_object_prototype_to_string_function { nullptr };
FunctionObject* m_throw_type_error_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
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: Initialize {Async,}{Generator,}Function constructors properly We were previously manually initializing them instead of just calling GlobalObject::initialize_constructor, which aside from duplicating code also meant we didn't set the required name property.
2022-02-19 17:49:25 +02:00
inline void GlobalObject::initialize_constructor(PropertyKey const& property_key, ConstructorType*& constructor, Object* prototype, PropertyAttributes attributes)
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);
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
constructor->define_direct_property(vm.names.name, js_string(heap(), property_key.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: Initialize {Async,}{Generator,}Function constructors properly We were previously manually initializing them instead of just calling GlobalObject::initialize_constructor, which aside from duplicating code also meant we didn't set the required name property.
2022-02-19 17:49:25 +02:00
prototype->define_direct_property(vm.names.constructor, constructor, attributes);
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>
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
inline void GlobalObject::add_constructor(PropertyKey const& property_key, 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)
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
initialize_constructor(property_key, constructor, prototype);
define_direct_property(property_key, 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>
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
[[nodiscard]] ALWAYS_INLINE ThrowCompletionOr<Value> Value::invoke(GlobalObject& global_object, PropertyKey const& property_key, 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) {
LibJS: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
MarkedVector<Value> arglist { global_object.vm().heap() };
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
(..., arglist.append(move(args)));
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
return invoke_internal(global_object, property_key, move(arglist));
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
}
LibJS: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
return invoke_internal(global_object, property_key, Optional<MarkedVector<Value>> {});
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
}
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