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

311 lines
11 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: Add parseFloat()
2020-05-17 15:12:34 +01:00
* Copyright (c) 2020, Linus Groh <mail@linusgroh.de>
Meta: Add missing copyright headers
2020-04-06 11:09:01 +02:00
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
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
#include <AK/Utf8View.h>
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
#include <LibJS/Console.h>
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
#include <LibJS/Heap/DeferGC.h>
LibJS: Add ArrayBuffer
2020-12-02 20:49:31 +00:00
#include <LibJS/Runtime/ArrayBufferConstructor.h>
#include <LibJS/Runtime/ArrayBufferPrototype.h>
LibJS: Add basic Array constructor We only support Array() with 0 or 1 parameters so far.
2020-04-04 22:28:21 +02:00
#include <LibJS/Runtime/ArrayConstructor.h>
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
#include <LibJS/Runtime/ArrayIteratorPrototype.h>
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
#include <LibJS/Runtime/ArrayPrototype.h>
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
#include <LibJS/Runtime/BigIntConstructor.h>
#include <LibJS/Runtime/BigIntPrototype.h>
LibJS: Add Boolean constructor object
2020-04-06 22:51:16 -05:00
#include <LibJS/Runtime/BooleanConstructor.h>
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
#include <LibJS/Runtime/BooleanPrototype.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/ConsoleObject.h>
LibJS: Start implementing Date :^) This adds: - A global Date object (with `length` property and `now` function) - The Date constructor (no arguments yet) - The Date prototype (with `get*` functions)
2020-03-30 00:21:56 +01:00
#include <LibJS/Runtime/DateConstructor.h>
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
#include <LibJS/Runtime/DatePrototype.h>
LibJS: Implement Error function/constructor
2020-04-01 19:42:07 +01:00
#include <LibJS/Runtime/ErrorConstructor.h>
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
#include <LibJS/Runtime/ErrorPrototype.h>
LibJS: Add Function() and Function.prototype
2020-04-04 14:34:31 +01:00
#include <LibJS/Runtime/FunctionConstructor.h>
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
#include <LibJS/Runtime/FunctionPrototype.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/GlobalObject.h>
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
#include <LibJS/Runtime/IteratorPrototype.h>
LibJS: Add JSON.stringify
2020-06-10 11:01:00 -07:00
#include <LibJS/Runtime/JSONObject.h>
LibJS: Add Math.random() :^)
2020-03-21 17:52:12 +01:00
#include <LibJS/Runtime/MathObject.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/NativeFunction.h>
LibJS: Add Number()
2020-04-07 16:17:23 +01:00
#include <LibJS/Runtime/NumberConstructor.h>
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
#include <LibJS/Runtime/NumberPrototype.h>
#include <LibJS/Runtime/Object.h>
LibJS: Add a global "Object" constructor This patch adds an "Object" constructor to the global object. The only function it implements so far is Object.getPrototypeOf().
2020-03-28 17:23:54 +01:00
#include <LibJS/Runtime/ObjectConstructor.h>
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
#include <LibJS/Runtime/ObjectPrototype.h>
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
#include <LibJS/Runtime/ProxyConstructor.h>
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
#include <LibJS/Runtime/ReflectObject.h>
LibJS: Lex and parse regex literals, add RegExp objects This adds regex parsing/lexing, as well as a relatively empty RegExpObject. The purpose of this patch is to allow the engine to not get hung up on parsing regexes. This will aid in finding new syntax errors (say, from google or twitter) without having to replace all of their regexes first!
2020-06-03 16:05:49 -07:00
#include <LibJS/Runtime/RegExpConstructor.h>
#include <LibJS/Runtime/RegExpPrototype.h>
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
#include <LibJS/Runtime/Shape.h>
LibJS: Add String constructor :^)
2020-04-10 14:14:02 +02:00
#include <LibJS/Runtime/StringConstructor.h>
LibJS: Add StringIterator
2020-07-11 20:23:01 -07:00
#include <LibJS/Runtime/StringIteratorPrototype.h>
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
#include <LibJS/Runtime/StringPrototype.h>
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
#include <LibJS/Runtime/SymbolConstructor.h>
#include <LibJS/Runtime/SymbolPrototype.h>
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
#include <LibJS/Runtime/TypedArray.h>
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
#include <LibJS/Runtime/TypedArrayConstructor.h>
#include <LibJS/Runtime/TypedArrayPrototype.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.h>
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
#include <ctype.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: 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
GlobalObject::GlobalObject()
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
: ScopeObject(GlobalObjectTag::Tag)
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
, m_console(make<Console>(*this))
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: 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
}
void GlobalObject::initialize()
{
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: Make global objects have unique shape from the start There's no point in trying to achieve shape sharing for global objects, so we can simply make the shape unique from the start and avoid making a transition chain.
2020-10-04 22:56:45 +02:00
ensure_shape_is_unique();
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
// These are done first since other prototypes depend on their presence.
LibJS: Use allocate_without_global_object for allocating Shapes
2020-10-17 23:47:07 +02:00
m_empty_object_shape = heap().allocate_without_global_object<Shape>(*this);
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
m_object_prototype = heap().allocate_without_global_object<ObjectPrototype>(*this);
m_function_prototype = heap().allocate_without_global_object<FunctionPrototype>(*this);
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: Use allocate_without_global_object for allocating Shapes
2020-10-17 23:47:07 +02:00
m_new_object_shape = vm.heap().allocate_without_global_object<Shape>(*this);
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
m_new_object_shape->set_prototype_without_transition(m_object_prototype);
LibJS: Use allocate_without_global_object for allocating Shapes
2020-10-17 23:47:07 +02:00
m_new_script_function_prototype_object_shape = vm.heap().allocate_without_global_object<Shape>(*this);
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
m_new_script_function_prototype_object_shape->set_prototype_without_transition(m_object_prototype);
m_new_script_function_prototype_object_shape->add_property_without_transition(vm.names.constructor, Attribute::Writable | Attribute::Configurable);
LibJS: Simplify Cell::initialize() Remove the Interpreter& argument and pass only GlobalObject&. We can find everything we need via the global object anyway.
2020-07-22 17:50:18 +02:00
static_cast<FunctionPrototype*>(m_function_prototype)->initialize(*this);
static_cast<ObjectPrototype*>(m_object_prototype)->initialize(*this);
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: Set prototype of GlobalObject to ObjectPrototype As the global object is constructed and initialized in a different way than most other objects we were not setting its prototype! This made things like "globalThis.toString()" fail unexpectedly.
2020-11-06 18:56:54 +00:00
set_prototype(m_object_prototype);
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) \
if (!m_##snake_name##_prototype) \
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
m_##snake_name##_prototype = heap().allocate<PrototypeName>(*this, *this);
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
JS_ENUMERATE_BUILTIN_TYPES
#undef __JS_ENUMERATE
LibJS+Clients: Add JS::VM object, separate Heap from Interpreter Taking a big step towards a world of multiple global object, this patch adds a new JS::VM object that houses the JS::Heap. This means that the Heap moves out of Interpreter, and the same Heap can now be used by multiple Interpreters, and can also outlive them. The VM keeps a stack of Interpreter pointers. We push/pop on this stack when entering/exiting execution with a given Interpreter. This allows us to make this change without disturbing too much of the existing code. There is still a 1-to-1 relationship between Interpreter and the global object. This will change in the future. Ultimately, the goal here is to make Interpreter a transient object that only needs to exist while you execute some code. Getting there will take a lot more work though. :^) Note that in LibWeb, the global JS::VM is called main_thread_vm(), to distinguish it from future worker VM's.
2020-09-20 19:24:44 +02:00
#define __JS_ENUMERATE(ClassName, snake_name) \
if (!m_##snake_name##_prototype) \
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
m_##snake_name##_prototype = heap().allocate<ClassName##Prototype>(*this, *this);
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Implement correct attributes for (almost) all properties Added the ability to include a u8 attributes parameter with all of the various put methods in the Object class. They can be omitted, in which case it defaults to "Writable | Enumerable | Configurable", just like before this commit. All of the attribute values for each property were gathered from SpiderMonkey in the Firefox console. Some properties (e.g. all of the canvas element properties) have undefined property descriptors... not quite sure what that means. Those were left as the default specified above.
2020-04-27 23:05:02 -07:00
u8 attr = Attribute::Writable | 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
define_native_function(vm.names.gc, gc, 0, attr);
define_native_function(vm.names.isNaN, is_nan, 1, attr);
define_native_function(vm.names.isFinite, is_finite, 1, attr);
define_native_function(vm.names.parseFloat, parse_float, 1, attr);
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
define_native_function(vm.names.parseInt, parse_int, 1, attr);
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
define_property(vm.names.NaN, js_nan(), 0);
define_property(vm.names.Infinity, js_infinity(), 0);
define_property(vm.names.undefined, js_undefined(), 0);
define_property(vm.names.globalThis, this, attr);
define_property(vm.names.console, heap().allocate<ConsoleObject>(*this, *this), attr);
define_property(vm.names.Math, heap().allocate<MathObject>(*this, *this), attr);
define_property(vm.names.JSON, heap().allocate<JSONObject>(*this, *this), attr);
define_property(vm.names.Reflect, heap().allocate<ReflectObject>(*this, *this), attr);
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
add_constructor(vm.names.Array, m_array_constructor, m_array_prototype);
LibJS: Add ArrayBuffer
2020-12-02 20:49:31 +00:00
add_constructor(vm.names.ArrayBuffer, m_array_buffer_constructor, m_array_buffer_prototype);
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
add_constructor(vm.names.BigInt, m_bigint_constructor, m_bigint_prototype);
add_constructor(vm.names.Boolean, m_boolean_constructor, m_boolean_prototype);
add_constructor(vm.names.Date, m_date_constructor, m_date_prototype);
add_constructor(vm.names.Error, m_error_constructor, m_error_prototype);
add_constructor(vm.names.Function, m_function_constructor, m_function_prototype);
add_constructor(vm.names.Number, m_number_constructor, m_number_prototype);
add_constructor(vm.names.Object, m_object_constructor, m_object_prototype);
add_constructor(vm.names.Proxy, m_proxy_constructor, nullptr);
add_constructor(vm.names.RegExp, m_regexp_constructor, m_regexp_prototype);
add_constructor(vm.names.String, m_string_constructor, m_string_prototype);
add_constructor(vm.names.Symbol, m_symbol_constructor, m_symbol_prototype);
LibJS: Add all the Error subclasses This patch adds instance, constructor and prototype classes for: - EvalError - InternalError - RangeError - ReferenceError - SyntaxError - TypeError - URIError Enumerator macros are used to reduce the amount of typing. :^)
2020-04-10 12:42:33 +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
initialize_constructor(vm.names.TypedArray, m_typed_array_constructor, m_typed_array_prototype);
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: 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
add_constructor(vm.names.ClassName, m_##snake_name##_constructor, m_##snake_name##_prototype);
LibJS: Add all the Error subclasses This patch adds instance, constructor and prototype classes for: - EvalError - InternalError - RangeError - ReferenceError - SyntaxError - TypeError - URIError Enumerator macros are used to reduce the amount of typing. :^)
2020-04-10 12:42:33 +02:00
JS_ENUMERATE_ERROR_SUBCLASSES
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
JS_ENUMERATE_TYPED_ARRAYS
LibJS: Use enumerator macros for boilerplate code around native types
2020-04-10 14:06:52 +02:00
#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
}
GlobalObject::~GlobalObject()
{
}
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
void GlobalObject::visit_edges(Visitor& visitor)
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
{
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
Base::visit_edges(visitor);
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
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
visitor.visit(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
visitor.visit(m_new_object_shape);
visitor.visit(m_new_script_function_prototype_object_shape);
LibJS: Make sure GlobalObject marks the Proxy constructor
2020-12-08 13:32:15 +01:00
visitor.visit(m_proxy_constructor);
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: 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: Use enumerator macro to mark all constructors in GlobalObject We were forgetting to mark the String constructor! So this patch fixes that and ensures we won't forget anyone in the future.
2020-04-18 11:02:05 +02:00
visitor.visit(m_##snake_name##_constructor);
JS_ENUMERATE_ERROR_SUBCLASSES
#undef __JS_ENUMERATE
LibJS: GlobalObject needs to mark the iterator prototypes Otherwise they all disappear in the first garbage collection.
2020-09-08 15:37:39 +02:00
#define __JS_ENUMERATE(ClassName, snake_name) \
visitor.visit(m_##snake_name##_prototype);
JS_ENUMERATE_ITERATOR_PROTOTYPES
#undef __JS_ENUMERATE
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
}
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_DEFINE_NATIVE_FUNCTION(GlobalObject::gc)
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
{
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
dbgln("Forced garbage collection requested!");
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
vm.heap().collect_garbage();
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
return js_undefined();
}
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_DEFINE_NATIVE_FUNCTION(GlobalObject::is_nan)
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
{
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
auto number = vm.argument(0).to_number(global_object);
if (vm.exception())
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
return {};
return Value(number.is_nan());
LibJS+LibWeb: Move native JS functions into dedicated member functions Instead of implementing every native function as a lambda function, use static member functions instead. This makes it easier to navigate the code + backtraces look nicer. :^)
2020-03-28 23:10:37 +01:00
}
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_DEFINE_NATIVE_FUNCTION(GlobalObject::is_finite)
LibJS: Add isFinite()
2020-04-22 18:07:24 +01:00
{
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
auto number = vm.argument(0).to_number(global_object);
if (vm.exception())
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
return {};
return Value(number.is_finite_number());
LibJS: Add isFinite()
2020-04-22 18:07:24 +01:00
}
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_DEFINE_NATIVE_FUNCTION(GlobalObject::parse_float)
LibJS: Add parseFloat()
2020-05-17 15:12:34 +01:00
{
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
if (vm.argument(0).is_number())
return vm.argument(0);
auto string = vm.argument(0).to_string(global_object);
if (vm.exception())
LibJS: Add parseFloat()
2020-05-17 15:12:34 +01:00
return {};
for (size_t length = string.length(); length > 0; --length) {
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
// This can't throw, so no exception check is fine.
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
auto number = Value(js_string(vm, string.substring(0, length))).to_number(global_object);
LibJS: Add parseFloat()
2020-05-17 15:12:34 +01:00
if (!number.is_nan())
return number;
}
return js_nan();
}
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_DEFINE_NATIVE_FUNCTION(GlobalObject::parse_int)
{
// 18.2.5 parseInt ( string, radix )
auto input_string = vm.argument(0).to_string(global_object);
if (vm.exception())
return {};
// FIXME: There's a bunch of unnecessary string copying here.
double sign = 1;
auto s = input_string.trim_whitespace(TrimMode::Left);
if (!s.is_empty() && s[0] == '-')
sign = -1;
if (!s.is_empty() && (s[0] == '+' || s[0] == '-'))
s = s.substring(1, s.length() - 1);
auto radix = vm.argument(1).to_i32(global_object);
if (vm.exception())
return {};
bool strip_prefix = true;
if (radix != 0) {
if (radix < 2 || radix > 36)
return js_nan();
if (radix != 16)
strip_prefix = false;
} else {
radix = 10;
}
if (strip_prefix) {
if (s.length() >= 2 && s[0] == '0' && (s[1] == 'x' || s[1] == 'X')) {
s = s.substring(2, s.length() - 2);
radix = 16;
}
}
auto parse_digit = [&](u32 codepoint, i32 radix) -> Optional<i32> {
i32 digit = -1;
if (isdigit(codepoint))
digit = codepoint - '0';
else if (islower(codepoint))
digit = 10 + (codepoint - 'a');
else if (isupper(codepoint))
digit = 10 + (codepoint - 'A');
if (digit == -1 || digit >= radix)
return {};
return digit;
};
bool had_digits = false;
double number = 0;
for (auto codepoint : Utf8View(s)) {
auto digit = parse_digit(codepoint, radix);
if (!digit.has_value())
break;
had_digits = true;
number *= radix;
number += digit.value();
}
if (!had_digits)
return js_nan();
return Value(sign * number);
}
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
Optional<Variable> GlobalObject::get_from_scope(const FlyString& name) const
{
auto value = get(name);
if (value.is_empty())
return {};
return Variable { value, DeclarationKind::Var };
}
void GlobalObject::put_to_scope(const FlyString& name, Variable variable)
{
put(name, variable.value);
}
bool GlobalObject::has_this_binding() const
{
return true;
}
Value GlobalObject::get_this_binding(GlobalObject&) const
{
return Value(this);
}
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