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/Object.cpp

1061 lines
40 KiB
C++
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
Everywhere: Use linusg@serenityos.org for my copyright headers
2021-04-22 22:51:19 +02:00
* Copyright (c) 2020-2021, Linus Groh <linusg@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01: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
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*/
Everywhere: Hook up remaining debug macros to Debug.h.
2021-01-24 15:28:26 +01:00
#include <AK/Debug.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
#include <AK/String.h>
Everywhere: Add missing <AK/TemporaryChange.h> includes Don't rely on HashTable.h pulling this in.
2020-10-15 20:46:52 +02:00
#include <AK/TemporaryChange.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/Heap/Heap.h>
LibJS: Move AST node stack from VM to Interpreter
2021-03-21 12:18:56 +01:00
#include <LibJS/Interpreter.h>
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
#include <LibJS/Runtime/Accessor.h>
LibJS: Support reading/writing elements in an Array via Object get/put I'm not completely thrilled about Object::get() and Object::put() doing special-case stuff for arrays, and we should probably come up with a better abstraction for it. But at least it works for now, which is really nice. :^)
2020-03-20 20:51:59 +01:00
#include <LibJS/Runtime/Array.h>
LibJS: Add Object.defineProperty() and start caring about attributes We now care (a little bit) about the "configurable" and "writable" property attributes. Property attributes are stored together with the property name in the Shape object. Forward transitions are not attribute-savvy and will cause poor Shape reuse in the case of multiple same-name properties with different attributes. Oh, and this patch also adds Object.getOwnPropertyDescriptor() :^)
2020-04-09 22:15:26 +02:00
#include <LibJS/Runtime/Error.h>
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
#include <LibJS/Runtime/GlobalObject.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>
#include <LibJS/Runtime/NativeProperty.h>
#include <LibJS/Runtime/Object.h>
LibJS: Add missing cyclic prototype check to Object.setPrototypeOf()
2021-06-07 22:56:16 +01:00
#include <LibJS/Runtime/ProxyObject.h>
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
#include <LibJS/Runtime/Shape.h>
LibJS: Implement correct object property ordering This commit introduces a way to get an object's own properties in the correct order. The "correct order" for JS object properties is first all array-like index properties (numeric keys) sorted by insertion order, followed by all string properties sorted by insertion order. Objects also now print correctly in the repl! Before this commit: courage ~/js-tests $ js > ({ foo: 1, bar: 2, baz: 3 }) { bar: 2, foo: 1, baz: 3 } After: courage ~/js-tests $ js > ({ foo: 1, bar: 2, baz: 3 }) { foo: 1, bar: 2, baz: 3 }
2020-04-28 19:19:31 -07:00
#include <LibJS/Runtime/StringObject.h>
LibJS: Temporarily clear exception in Object::get_without_side_effects() This would return an empty value once it hits an exception check otherwise. Considering that this mostly is used in situations where we already *do* have an exception (traceback printing, for example), let's make this easier for ourselves to use.
2021-04-24 17:59:28 +02:00
#include <LibJS/Runtime/TemporaryClearException.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: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
namespace JS {
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
PropertyDescriptor PropertyDescriptor::from_dictionary(VM& vm, const Object& object)
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
{
PropertyAttributes attributes;
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 (object.has_property(vm.names.configurable)) {
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
attributes.set_has_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 (object.get(vm.names.configurable).value_or(Value(false)).to_boolean())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
attributes.set_configurable();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm.exception())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return {};
}
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 (object.has_property(vm.names.enumerable)) {
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
attributes.set_has_enumerable();
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 (object.get(vm.names.enumerable).value_or(Value(false)).to_boolean())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
attributes.set_enumerable();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm.exception())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return {};
}
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 (object.has_property(vm.names.writable)) {
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
attributes.set_has_writable();
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 (object.get(vm.names.writable).value_or(Value(false)).to_boolean())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
attributes.set_writable();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm.exception())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return {};
}
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
PropertyDescriptor descriptor { attributes, object.get(vm.names.value), nullptr, nullptr };
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm.exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
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 getter = object.get(vm.names.get);
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm.exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
if (getter.is_function())
descriptor.getter = &getter.as_function();
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 setter = object.get(vm.names.set);
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm.exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
if (setter.is_function())
descriptor.setter = &setter.as_function();
return descriptor;
}
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
Object* Object::create_empty(GlobalObject& global_object)
LibJS+LibWeb: Pass prototype to Object constructor Everyone who constructs an Object must now pass a prototype object when applicable. There's still a fair amount of code that passes something fetched from the Interpreter, but this brings us closer to being able to detach prototypes from Interpreter eventually.
2020-04-18 10:27:57 +02:00
{
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
return global_object.heap().allocate<Object>(global_object, *global_object.new_object_shape());
LibJS+LibWeb: Pass prototype to Object constructor Everyone who constructs an Object must now pass a prototype object when applicable. There's still a fair amount of code that passes something fetched from the Interpreter, but this brings us closer to being able to detach prototypes from Interpreter eventually.
2020-04-18 10:27:57 +02:00
}
LibJS: Clarify Object (base class) construction somewhat Divide the Object constructor into three variants: - The regular one (takes an Object& prototype) - One for use by GlobalObject - One for use by objects without a prototype (e.g ObjectPrototype)
2020-06-23 17:21:53 +02:00
Object::Object(GlobalObjectTag)
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
{
LibJS: Clarify Object (base class) construction somewhat Divide the Object constructor into three variants: - The regular one (takes an Object& prototype) - One for use by GlobalObject - One for use by objects without a prototype (e.g ObjectPrototype)
2020-06-23 17:21:53 +02:00
// This is the global object
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
m_shape = heap().allocate_without_global_object<Shape>(*this);
LibJS: Clarify Object (base class) construction somewhat Divide the Object constructor into three variants: - The regular one (takes an Object& prototype) - One for use by GlobalObject - One for use by objects without a prototype (e.g ObjectPrototype)
2020-06-23 17:21:53 +02:00
}
Object::Object(ConstructWithoutPrototypeTag, GlobalObject& global_object)
{
LibJS: Use allocate_without_global_object for allocating Shapes
2020-10-17 23:47:07 +02:00
m_shape = heap().allocate_without_global_object<Shape>(global_object);
LibJS: Clarify Object (base class) construction somewhat Divide the Object constructor into three variants: - The regular one (takes an Object& prototype) - One for use by GlobalObject - One for use by objects without a prototype (e.g ObjectPrototype)
2020-06-23 17:21:53 +02:00
}
Object::Object(Object& prototype)
{
m_shape = prototype.global_object().empty_object_shape();
set_prototype(&prototype);
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
}
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
Object::Object(Shape& shape)
: m_shape(&shape)
{
m_storage.resize(shape.property_count());
}
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
void Object::initialize(GlobalObject&)
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
{
}
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
Object::~Object()
{
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
Object* Object::prototype()
{
return shape().prototype();
}
const Object* Object::prototype() const
{
return shape().prototype();
}
LibJS: Add missing cyclic prototype check to Object.setPrototypeOf()
2021-06-07 22:56:16 +01:00
// 10.1.2.1 OrdinarySetPrototypeOf, https://tc39.es/ecma262/#sec-ordinarysetprototypeof
LibJS: Disallow changing the prototype of non-extensible objects Object::set_prototype() now returns a boolean indicating success. Setting the prototype to an identical object is always considered successful, even if the object is non-extensible.
2020-06-02 12:32:54 +01:00
bool Object::set_prototype(Object* new_prototype)
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
{
LibJS+LibWeb: Pass prototype to Object constructor Everyone who constructs an Object must now pass a prototype object when applicable. There's still a fair amount of code that passes something fetched from the Interpreter, but this brings us closer to being able to detach prototypes from Interpreter eventually.
2020-04-18 10:27:57 +02:00
if (prototype() == new_prototype)
LibJS: Disallow changing the prototype of non-extensible objects Object::set_prototype() now returns a boolean indicating success. Setting the prototype to an identical object is always considered successful, even if the object is non-extensible.
2020-06-02 12:32:54 +01:00
return true;
if (!m_is_extensible)
return false;
LibJS: Add missing cyclic prototype check to Object.setPrototypeOf()
2021-06-07 22:56:16 +01:00
auto* prototype = new_prototype;
while (prototype) {
if (prototype == this)
return false;
// NOTE: This is a best-effort implementation of the following step:
// "If p.[[GetPrototypeOf]] is not the ordinary object internal method defined in 10.1.1,
// set done to true."
// We don't have a good way of detecting whether certain virtual Object methods have been
// overridden by a given object, but as ProxyObject is the only one doing that, this check
// does the trick.
if (is<ProxyObject>(prototype))
break;
prototype = prototype->prototype();
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
}
LibJS: Add missing cyclic prototype check to Object.setPrototypeOf()
2021-06-07 22:56:16 +01:00
auto& shape = this->shape();
if (shape.is_unique())
shape.set_prototype_without_transition(new_prototype);
else
m_shape = shape.create_prototype_transition(new_prototype);
LibJS: Disallow changing the prototype of non-extensible objects Object::set_prototype() now returns a boolean indicating success. Setting the prototype to an identical object is always considered successful, even if the object is non-extensible.
2020-06-02 12:32:54 +01:00
return true;
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
}
LibJS: Oops, "instanceof" was backwards! Fix the "instanceof" operator to check if the constructor's prototype property occurs anywhere in the prototype chain of the instance object. This patch also adds Object.setPrototypeOf() to make it possible to create a test for this bug. Thanks to DexesTTP for pointing this out! :^)
2020-03-28 19:48:12 +01:00
bool Object::has_prototype(const Object* prototype) const
{
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
for (auto* object = this->prototype(); object; object = object->prototype()) {
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return false;
LibJS: Oops, "instanceof" was backwards! Fix the "instanceof" operator to check if the constructor's prototype property occurs anywhere in the prototype chain of the instance object. This patch also adds Object.setPrototypeOf() to make it possible to create a test for this bug. Thanks to DexesTTP for pointing this out! :^)
2020-03-28 19:48:12 +01:00
if (object == prototype)
return true;
}
return false;
}
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
bool Object::prevent_extensions()
{
m_is_extensible = false;
return true;
}
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
// 7.3.15 SetIntegrityLevel, https://tc39.es/ecma262/#sec-setintegritylevel
bool Object::set_integrity_level(IntegrityLevel level)
{
// FIXME: This feels clunky and should get nicer abstractions.
LibJS: Fix crash in Object.{freeze,seal}() with indexed properties This was failing to take two things into account: - When constructing a PropertyName from a value, it won't automatically convert to Type::Number for something like string "0", even though that's how things work internally, since indexed properties are stored separately. This will be improved in a future patch, it's a footgun and should happen automatically. - Those can't be looked up on the shape, we have to go through the indexed properties instead. Additionally it now operates on the shape or indexed properties directly as define_property() was overly strict and would throw if a property was already non-configurable. Fixes #6469.
2021-04-20 09:08:40 +02:00
auto update_property = [this](auto& property_name, auto new_attributes) {
if (property_name.is_number()) {
auto value_and_attributes = m_indexed_properties.get(nullptr, property_name.as_number(), false).value();
auto value = value_and_attributes.value;
auto attributes = value_and_attributes.attributes.bits() & new_attributes;
m_indexed_properties.put(nullptr, property_name.as_number(), value, attributes, false);
} else {
auto metadata = shape().lookup(property_name.to_string_or_symbol()).value();
auto attributes = metadata.attributes.bits() & new_attributes;
if (m_shape->is_unique())
m_shape->reconfigure_property_in_unique_shape(property_name.to_string_or_symbol(), attributes);
else
set_shape(*m_shape->create_configure_transition(property_name.to_string_or_symbol(), attributes));
}
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
};
auto& vm = this->vm();
auto status = prevent_extensions();
if (vm.exception())
return false;
if (!status)
return false;
auto keys = get_own_properties(PropertyKind::Key);
if (vm.exception())
return false;
switch (level) {
case IntegrityLevel::Sealed:
for (auto& key : keys) {
LibJS: Take PropertyName in Object::set_integrity_level() internal lambda At least for IntegrityLevel::Frozen we already construct a PropertyName from the key value, let's reuse that.
2021-04-20 09:00:11 +02:00
auto property_name = PropertyName::from_value(global_object(), key);
LibJS: Fix crash in Object.{freeze,seal}() with indexed properties This was failing to take two things into account: - When constructing a PropertyName from a value, it won't automatically convert to Type::Number for something like string "0", even though that's how things work internally, since indexed properties are stored separately. This will be improved in a future patch, it's a footgun and should happen automatically. - Those can't be looked up on the shape, we have to go through the indexed properties instead. Additionally it now operates on the shape or indexed properties directly as define_property() was overly strict and would throw if a property was already non-configurable. Fixes #6469.
2021-04-20 09:08:40 +02:00
if (property_name.is_string()) {
i32 property_index = property_name.as_string().to_int().value_or(-1);
if (property_index >= 0)
property_name = property_index;
}
LibJS: Take PropertyName in Object::set_integrity_level() internal lambda At least for IntegrityLevel::Frozen we already construct a PropertyName from the key value, let's reuse that.
2021-04-20 09:00:11 +02:00
update_property(property_name, ~Attribute::Configurable);
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
if (vm.exception())
return {};
}
break;
case IntegrityLevel::Frozen:
for (auto& key : keys) {
auto property_name = PropertyName::from_value(global_object(), key);
LibJS: Fix crash in Object.{freeze,seal}() with indexed properties This was failing to take two things into account: - When constructing a PropertyName from a value, it won't automatically convert to Type::Number for something like string "0", even though that's how things work internally, since indexed properties are stored separately. This will be improved in a future patch, it's a footgun and should happen automatically. - Those can't be looked up on the shape, we have to go through the indexed properties instead. Additionally it now operates on the shape or indexed properties directly as define_property() was overly strict and would throw if a property was already non-configurable. Fixes #6469.
2021-04-20 09:08:40 +02:00
if (property_name.is_string()) {
i32 property_index = property_name.as_string().to_int().value_or(-1);
if (property_index >= 0)
property_name = property_index;
}
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
auto property_descriptor = get_own_property_descriptor(property_name);
VERIFY(property_descriptor.has_value());
u8 attributes = property_descriptor->is_accessor_descriptor()
? ~Attribute::Configurable
: ~Attribute::Configurable & ~Attribute::Writable;
LibJS: Take PropertyName in Object::set_integrity_level() internal lambda At least for IntegrityLevel::Frozen we already construct a PropertyName from the key value, let's reuse that.
2021-04-20 09:00:11 +02:00
update_property(property_name, attributes);
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
if (vm.exception())
return {};
}
break;
default:
VERIFY_NOT_REACHED();
}
return true;
}
LibJS: Implement Object.isFrozen() and Object.isSealed()
2021-04-06 22:45:12 +02:00
// 7.3.16 TestIntegrityLevel, https://tc39.es/ecma262/#sec-testintegritylevel
bool Object::test_integrity_level(IntegrityLevel level)
{
auto& vm = this->vm();
auto extensible = is_extensible();
if (vm.exception())
return false;
if (extensible)
return false;
auto keys = get_own_properties(PropertyKind::Key);
if (vm.exception())
return false;
for (auto& key : keys) {
auto property_name = PropertyName::from_value(global_object(), key);
auto property_descriptor = get_own_property_descriptor(property_name);
VERIFY(property_descriptor.has_value());
if (property_descriptor->attributes.is_configurable())
return false;
if (level == IntegrityLevel::Frozen && property_descriptor->is_data_descriptor()) {
if (property_descriptor->attributes.is_writable())
return false;
}
}
return true;
}
LibJS: Add Object::get_without_side_effects() Similar to Value::to_string_without_side_effects() this is mostly a regular object property lookup, but with the guarantee that it will be side-effect free, i.e. no accessors or native property functions will be called. This is needed when we want to access user-controlled object properties for debug logging, for example. The specific use case will be error objects which will soon no longer have internal name/message properties, so we need to guarantee that printing an error, which may already be the result of an exception, won't blow up in our face :^)
2021-04-11 22:52:25 +02:00
Value Object::get_own_property(const PropertyName& property_name, Value receiver, bool without_side_effects) const
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
VERIFY(!receiver.is_empty());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
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
Value value_here;
if (property_name.is_number()) {
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto existing_property = m_indexed_properties.get(nullptr, property_name.as_number(), false);
if (!existing_property.has_value())
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
return {};
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
value_here = existing_property.value().value.value_or(js_undefined());
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
} else {
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
auto metadata = shape().lookup(property_name.to_string_or_symbol());
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
if (!metadata.has_value())
return {};
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
value_here = m_storage[metadata.value().offset].value_or(js_undefined());
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
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!value_here.is_empty());
LibJS: Add Object::get_without_side_effects() Similar to Value::to_string_without_side_effects() this is mostly a regular object property lookup, but with the guarantee that it will be side-effect free, i.e. no accessors or native property functions will be called. This is needed when we want to access user-controlled object properties for debug logging, for example. The specific use case will be error objects which will soon no longer have internal name/message properties, so we need to guarantee that printing an error, which may already be the result of an exception, won't blow up in our face :^)
2021-04-11 22:52:25 +02:00
if (!without_side_effects) {
if (value_here.is_accessor())
return value_here.as_accessor().call_getter(receiver);
if (value_here.is_native_property())
return call_native_property_getter(value_here.as_native_property(), receiver);
}
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
return value_here;
}
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
MarkedValueList Object::get_own_properties(PropertyKind kind, bool only_enumerable_properties, GetOwnPropertyReturnType return_type) const
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
{
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
MarkedValueList properties(heap());
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
// FIXME: Support generic iterables
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
if (is<StringObject>(*this)) {
auto str = static_cast<const StringObject&>(*this).primitive_string().string();
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
for (size_t i = 0; i < str.length(); ++i) {
LibJS: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
if (kind == PropertyKind::Key) {
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(js_string(vm(), String::number(i)));
LibJS: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
} else if (kind == PropertyKind::Value) {
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(js_string(vm(), String::formatted("{:c}", str[i])));
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
} else {
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* entry_array = Array::create(global_object());
LibJS: Reduce Interpreter& usage in the Object class
2020-09-27 19:57:16 +02:00
entry_array->define_property(0, js_string(vm(), String::number(i)));
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
entry_array->define_property(1, js_string(vm(), String::formatted("{:c}", str[i])));
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(entry_array);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
return MarkedValueList { heap() };
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
return properties;
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
for (auto& entry : m_indexed_properties) {
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
auto value_and_attributes = entry.value_and_attributes(const_cast<Object*>(this));
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
if (only_enumerable_properties && !value_and_attributes.attributes.is_enumerable())
continue;
LibJS: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
if (kind == PropertyKind::Key) {
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(js_string(vm(), String::number(entry.index())));
LibJS: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
} else if (kind == PropertyKind::Value) {
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(value_and_attributes.value);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
} else {
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* entry_array = Array::create(global_object());
LibJS: Reduce Interpreter& usage in the Object class
2020-09-27 19:57:16 +02:00
entry_array->define_property(0, js_string(vm(), String::number(entry.index())));
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
entry_array->define_property(1, value_and_attributes.value);
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(entry_array);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
return MarkedValueList { heap() };
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Let Object::get_own_properties() return both strings and symbols The new default return_type argument is GetOwnPropertyReturnType::All, which returns properties with both string and symbol keys (which is also the default for [[OwnPropertyKeys]]). This means that in some cases we need to iterate the ordered property table twice, as we don't store string and symbol properties separately but symbols must - there's certainly room for (performance) improvements here. On the other hand this makes Reflect.ownKeys() return symbol properties now :^)
2021-04-05 19:17:40 +02:00
auto add_property_to_results = [&](auto& property) {
LibJS: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
if (kind == PropertyKind::Key) {
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(property.key.to_value(vm()));
LibJS: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
} else if (kind == PropertyKind::Value) {
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(get(property.key));
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
} else {
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* entry_array = Array::create(global_object());
LibJS: Let Object::get_own_properties() return both strings and symbols The new default return_type argument is GetOwnPropertyReturnType::All, which returns properties with both string and symbol keys (which is also the default for [[OwnPropertyKeys]]). This means that in some cases we need to iterate the ordered property table twice, as we don't store string and symbol properties separately but symbols must - there's certainly room for (performance) improvements here. On the other hand this makes Reflect.ownKeys() return symbol properties now :^)
2021-04-05 19:17:40 +02:00
entry_array->define_property(0, property.key.to_value(vm()));
entry_array->define_property(1, get(property.key));
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
properties.append(entry_array);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Let Object::get_own_properties() return both strings and symbols The new default return_type argument is GetOwnPropertyReturnType::All, which returns properties with both string and symbol keys (which is also the default for [[OwnPropertyKeys]]). This means that in some cases we need to iterate the ordered property table twice, as we don't store string and symbol properties separately but symbols must - there's certainly room for (performance) improvements here. On the other hand this makes Reflect.ownKeys() return symbol properties now :^)
2021-04-05 19:17:40 +02:00
};
// NOTE: Most things including for..in/of and Object.{keys,values,entries}() use StringOnly, and in those
// cases we won't be iterating the ordered property table twice. We can certainly improve this though.
if (return_type == GetOwnPropertyReturnType::All || return_type == GetOwnPropertyReturnType::StringOnly) {
for (auto& it : shape().property_table_ordered()) {
if (only_enumerable_properties && !it.value.attributes.is_enumerable())
continue;
if (it.key.is_symbol())
continue;
add_property_to_results(it);
if (vm().exception())
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
return MarkedValueList { heap() };
LibJS: Let Object::get_own_properties() return both strings and symbols The new default return_type argument is GetOwnPropertyReturnType::All, which returns properties with both string and symbol keys (which is also the default for [[OwnPropertyKeys]]). This means that in some cases we need to iterate the ordered property table twice, as we don't store string and symbol properties separately but symbols must - there's certainly room for (performance) improvements here. On the other hand this makes Reflect.ownKeys() return symbol properties now :^)
2021-04-05 19:17:40 +02:00
}
}
if (return_type == GetOwnPropertyReturnType::All || return_type == GetOwnPropertyReturnType::SymbolOnly) {
for (auto& it : shape().property_table_ordered()) {
if (only_enumerable_properties && !it.value.attributes.is_enumerable())
continue;
if (it.key.is_string())
continue;
add_property_to_results(it);
if (vm().exception())
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
return MarkedValueList { heap() };
LibJS: Let Object::get_own_properties() return both strings and symbols The new default return_type argument is GetOwnPropertyReturnType::All, which returns properties with both string and symbol keys (which is also the default for [[OwnPropertyKeys]]). This means that in some cases we need to iterate the ordered property table twice, as we don't store string and symbol properties separately but symbols must - there's certainly room for (performance) improvements here. On the other hand this makes Reflect.ownKeys() return symbol properties now :^)
2021-04-05 19:17:40 +02:00
}
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
return properties;
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Add Object::get_enumerable_own_property_names() and use it Object::get_own_properties() is a bit unwieldy to use - especially as StringOnly is about to no longer be the default value. The spec has an abstract operation specifically for this (EnumerateObjectProperties), so let's use that. No functionality change.
2021-04-05 19:05:15 +02:00
// 7.3.23 EnumerableOwnPropertyNames, https://tc39.es/ecma262/#sec-enumerableownpropertynames
LibJS: Use MarkedValueList for internal own properties getter functions Letting these create and return a JS::Array directly is pretty awkward since we then need to go through the indexed properties for iteration. Just use a MarkedValueList (i.e. Vector<Value>) for this and add a new Array::create_from() function to turn the Vector into a returnable Array as we did before. This brings it a lot closer to the spec as well, which uses the CreateArrayFromList abstract operation to do exactly this. There's an optimization opportunity for the future here, since we know the Vector's size we could prepare the newly created Array accordingly, e.g. by switching to generic storage upfront if needed.
2021-04-06 21:39:17 +02:00
MarkedValueList Object::get_enumerable_own_property_names(PropertyKind kind) const
LibJS: Add Object::get_enumerable_own_property_names() and use it Object::get_own_properties() is a bit unwieldy to use - especially as StringOnly is about to no longer be the default value. The spec has an abstract operation specifically for this (EnumerateObjectProperties), so let's use that. No functionality change.
2021-04-05 19:05:15 +02:00
{
return get_own_properties(kind, true, Object::GetOwnPropertyReturnType::StringOnly);
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
Optional<PropertyDescriptor> Object::get_own_property_descriptor(const PropertyName& property_name) const
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
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
Value value;
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
PropertyAttributes attributes;
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
if (property_name.is_number()) {
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto existing_value = m_indexed_properties.get(nullptr, property_name.as_number(), false);
if (!existing_value.has_value())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return {};
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
value = existing_value.value().value;
attributes = existing_value.value().attributes;
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
} else {
LibJS: Make Object.getOwnPropertyDescriptor() work with string indexed property E.g. for "0" we have to contruct a PropertyName with Type::Number so it looks in the indexed properties as expected.
2021-04-20 18:53:07 +02:00
if (property_name.is_string()) {
i32 property_index = property_name.as_string().to_int().value_or(-1);
if (property_index >= 0)
return get_own_property_descriptor(property_index);
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
auto metadata = shape().lookup(property_name.to_string_or_symbol());
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
if (!metadata.has_value())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return {};
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
value = m_storage[metadata.value().offset];
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
attributes = metadata.value().attributes;
}
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
PropertyDescriptor descriptor { attributes, {}, nullptr, nullptr };
LibJS: Make NativeProperty a plain Cell instead of an Object This removes the need for NativeProperty objects to have a prototype, which just made things confusing.
2020-06-23 17:56:57 +02:00
if (value.is_native_property()) {
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
auto result = call_native_property_getter(value.as_native_property(), const_cast<Object*>(this));
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.value = result.value_or(js_undefined());
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
} else if (value.is_accessor()) {
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
auto& pair = value.as_accessor();
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
if (pair.getter())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.getter = pair.getter();
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
if (pair.setter())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.setter = pair.setter();
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
} else {
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.value = value.value_or(js_undefined());
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
}
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
return descriptor;
}
LibJS: Fix get_own_property_descriptor_object() field name order This is defined by the spec: enumerable and configurable come last.
2021-06-07 23:02:52 +01:00
// Equivalent to:
// 6.2.5.4 FromPropertyDescriptor, https://tc39.es/ecma262/#sec-frompropertydescriptor
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
Value Object::get_own_property_descriptor_object(const PropertyName& property_name) const
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00: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: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
auto descriptor_opt = get_own_property_descriptor(property_name);
if (!descriptor_opt.has_value())
return js_undefined();
auto descriptor = descriptor_opt.value();
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
auto* descriptor_object = Object::create_empty(global_object());
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
if (descriptor.is_data_descriptor()) {
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
descriptor_object->define_property(vm.names.value, descriptor.value.value_or(js_undefined()));
descriptor_object->define_property(vm.names.writable, Value(descriptor.attributes.is_writable()));
LibJS: Never omit setter/getter attributes in accessor descriptor object These should not be omitted, an accessor with out getter or setter still yields an undefined for the attribute in its descriptor object.
2021-06-07 23:07:13 +01:00
} else {
VERIFY(descriptor.is_accessor_descriptor());
descriptor_object->define_property(vm.names.get, descriptor.getter ? Value(descriptor.getter) : js_undefined());
descriptor_object->define_property(vm.names.set, descriptor.setter ? Value(descriptor.setter) : js_undefined());
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
}
LibJS: Fix get_own_property_descriptor_object() field name order This is defined by the spec: enumerable and configurable come last.
2021-06-07 23:02:52 +01:00
descriptor_object->define_property(vm.names.enumerable, Value(descriptor.attributes.is_enumerable()));
descriptor_object->define_property(vm.names.configurable, Value(descriptor.attributes.is_configurable()));
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return descriptor_object;
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
void Object::set_shape(Shape& new_shape)
{
m_storage.resize(new_shape.property_count());
m_shape = &new_shape;
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
bool Object::define_property(const StringOrSymbol& property_name, const Object& descriptor, bool throw_exceptions)
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01: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();
bool is_accessor_property = descriptor.has_property(vm.names.get) || descriptor.has_property(vm.names.set);
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
PropertyAttributes attributes;
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 (descriptor.has_property(vm.names.configurable)) {
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_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 (descriptor.get(vm.names.configurable).value_or(Value(false)).to_boolean())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_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: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
return false;
}
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 (descriptor.has_property(vm.names.enumerable)) {
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_enumerable();
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 (descriptor.get(vm.names.enumerable).value_or(Value(false)).to_boolean())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_enumerable();
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: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
return false;
}
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (is_accessor_property) {
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 (descriptor.has_property(vm.names.value) || descriptor.has_property(vm.names.writable)) {
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (throw_exceptions)
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
vm.throw_exception<TypeError>(global_object(), ErrorType::AccessorValueOrWritable);
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return false;
}
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 getter = descriptor.get(vm.names.get).value_or(js_undefined());
if (vm.exception())
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return {};
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 setter = descriptor.get(vm.names.set).value_or(js_undefined());
if (vm.exception())
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return {};
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
Function* getter_function { nullptr };
Function* setter_function { nullptr };
if (getter.is_function()) {
getter_function = &getter.as_function();
} else if (!getter.is_undefined()) {
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
vm.throw_exception<TypeError>(global_object(), ErrorType::AccessorBadField, "get");
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return false;
}
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
if (setter.is_function()) {
setter_function = &setter.as_function();
} else if (!setter.is_undefined()) {
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
vm.throw_exception<TypeError>(global_object(), ErrorType::AccessorBadField, "set");
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return false;
}
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Defining new property {} with accessor descriptor {{ attributes={}, getter={}, setter={} }}", property_name.to_display_string(), attributes, getter, setter);
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07: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
return define_property(property_name, Accessor::create(vm, getter_function, setter_function), attributes, throw_exceptions);
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07: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 value = descriptor.get(vm.names.value);
if (vm.exception())
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return {};
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 (descriptor.has_property(vm.names.writable)) {
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_writable();
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 (descriptor.get(vm.names.writable).value_or(Value(false)).to_boolean())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_writable();
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: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
return false;
}
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 getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return {};
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Defining new property {} with data descriptor {{ attributes={}, value={} }}", property_name.to_display_string(), attributes, value);
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
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
return define_property(property_name, value, attributes, throw_exceptions);
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
}
LibJS: Add Object::define_property_without_transition() helper This allows us to avoid transitioning in two common cases, saving some time during object construction.
2020-10-06 16:57:02 +02:00
bool Object::define_property_without_transition(const PropertyName& property_name, Value value, PropertyAttributes attributes, bool throw_exceptions)
{
TemporaryChange change(m_transitions_enabled, false);
return define_property(property_name, value, attributes, throw_exceptions);
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
bool Object::define_property(const PropertyName& property_name, Value value, PropertyAttributes attributes, bool throw_exceptions)
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
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
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
if (property_name.is_number())
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
return put_own_property_by_index(property_name.as_number(), value, attributes, PutOwnPropertyMode::DefineProperty, throw_exceptions);
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
if (property_name.is_string()) {
i32 property_index = property_name.as_string().to_int().value_or(-1);
if (property_index >= 0)
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
return put_own_property_by_index(property_index, value, attributes, PutOwnPropertyMode::DefineProperty, throw_exceptions);
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
}
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
return put_own_property(property_name.to_string_or_symbol(), value, attributes, PutOwnPropertyMode::DefineProperty, throw_exceptions);
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
}
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
bool Object::define_accessor(const PropertyName& property_name, Function* getter, Function* setter, PropertyAttributes attributes, bool throw_exceptions)
LibJS: Add Object::define_accessor() This is a helper function based on the getter/setter definition logic from ObjectExpression::execute() to look up an Accessor property if it already exists, define a new Accessor property if it doesn't exist, and set the getter or setter function on the Accessor.
2020-06-13 21:23:33 -05:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
LibJS: Add Object::define_accessor() This is a helper function based on the getter/setter definition logic from ObjectExpression::execute() to look up an Accessor property if it already exists, define a new Accessor property if it doesn't exist, and set the getter or setter function on the Accessor.
2020-06-13 21:23:33 -05:00
Accessor* accessor { nullptr };
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
auto property_metadata = shape().lookup(property_name.to_string_or_symbol());
LibJS: Add Object::define_accessor() This is a helper function based on the getter/setter definition logic from ObjectExpression::execute() to look up an Accessor property if it already exists, define a new Accessor property if it doesn't exist, and set the getter or setter function on the Accessor.
2020-06-13 21:23:33 -05:00
if (property_metadata.has_value()) {
auto existing_property = get_direct(property_metadata.value().offset);
if (existing_property.is_accessor())
accessor = &existing_property.as_accessor();
}
if (!accessor) {
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
accessor = Accessor::create(vm(), getter, setter);
LibJS: Add Object::define_accessor() This is a helper function based on the getter/setter definition logic from ObjectExpression::execute() to look up an Accessor property if it already exists, define a new Accessor property if it doesn't exist, and set the getter or setter function on the Accessor.
2020-06-13 21:23:33 -05:00
bool definition_success = define_property(property_name, accessor, attributes, throw_exceptions);
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Add Object::define_accessor() This is a helper function based on the getter/setter definition logic from ObjectExpression::execute() to look up an Accessor property if it already exists, define a new Accessor property if it doesn't exist, and set the getter or setter function on the Accessor.
2020-06-13 21:23:33 -05:00
return {};
if (!definition_success)
return false;
LibJS: Update Object::define_accessor() to take both getter and setter This replaces the current 'function plus boolean indicating the type' API, which makes it easier to set both getter and setter at once. This was already possible before but required two calls of this function, which wasn't intuitive: define_accessor(name, getter, true, ...); define_accessor(name, setter, false, ...); Which now becomes: define_accessor(name, getter, setter, ...);
2021-04-10 18:35:29 +02:00
} else {
if (getter)
accessor->set_getter(getter);
if (setter)
accessor->set_setter(setter);
LibJS: Add Object::define_accessor() This is a helper function based on the getter/setter definition logic from ObjectExpression::execute() to look up an Accessor property if it already exists, define a new Accessor property if it doesn't exist, and set the getter or setter function on the Accessor.
2020-06-13 21:23:33 -05:00
}
return true;
}
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
bool Object::put_own_property(const StringOrSymbol& property_name, Value value, PropertyAttributes attributes, PutOwnPropertyMode mode, bool throw_exceptions)
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!(mode == PutOwnPropertyMode::Put && value.is_accessor()));
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07: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
if (value.is_accessor()) {
auto& accessor = value.as_accessor();
if (accessor.getter())
attributes.set_has_getter();
if (accessor.setter())
attributes.set_has_setter();
}
LibJS: Avoid property lookups during object initialization When we're initializing objects, we're just adding a bunch of new properties, without transition, and without overlap (we never add the same property twice.) Take advantage of this by skipping lookups entirely (no need to see if we're overwriting an existing property) during initialization. Another nice test-js speedup :^)
2020-10-13 23:53:02 +02:00
// NOTE: We disable transitions during initialize(), this makes building common runtime objects significantly faster.
// Transitions are primarily interesting when scripts add properties to objects.
if (!m_transitions_enabled && !m_shape->is_unique()) {
m_shape->add_property_without_transition(property_name, attributes);
m_storage.resize(m_shape->property_count());
m_storage[m_shape->property_count() - 1] = value;
return true;
}
LibJS: Object.preventExtensions should allow property modfication Existing properties on a non-extensible object should be changable and deletable.
2020-07-06 17:17:47 -07:00
auto metadata = shape().lookup(property_name);
bool new_property = !metadata.has_value();
if (!is_extensible() && new_property) {
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Disallow define_property of non-extensible object");
LibJS: Move "strict mode" state to the call stack Each call frame now knows whether it's executing in strict mode. It's no longer necessary to access the scope stack to find this mode.
2020-10-04 13:54:44 +02:00
if (throw_exceptions && vm().in_strict_mode())
LibJS: Use String::formatted() for throw_exception() message
2020-10-04 13:55:20 +01:00
vm().throw_exception<TypeError>(global_object(), ErrorType::NonExtensibleDefine, property_name.to_display_string());
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
return false;
}
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
if (new_property) {
LibJS: Switch objects to unique shape after 100 property additions At that point, it seems unlikely that the shape is gonna be shared with other objects, and we avoid getting stuck holding a big bag of shapes.
2020-05-05 18:48:30 +02:00
if (!m_shape->is_unique() && shape().property_count() > 100) {
// If you add more than 100 properties to an object, let's stop doing
// transitions to avoid filling up the heap with shapes.
ensure_shape_is_unique();
}
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (m_shape->is_unique()) {
m_shape->add_property_to_unique_shape(property_name, attributes);
LibJS: Grow storage when adding a property to uniquely-shaped Object Normally the storage would be expanded by set_shape() upon transition to a new shape, but if the shape is already unique, there is no new transition so we have to expand the storage manually.
2020-04-26 19:03:23 +02:00
m_storage.resize(m_shape->property_count());
LibJS: Prevent object shape transitions during runtime object buildup While initialization common runtime objects like functions, prototypes, etc, we don't really care about tracking transitions for each and every property added to them. This patch puts objects into a "disable transitions" mode while we call initialize() on them. After that, adding more properties will cause new transitions to be generated and added to the chain. This gives a ~10% speed-up on test-js. :^)
2020-10-05 20:08:14 +02:00
} else if (m_transitions_enabled) {
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
set_shape(*m_shape->create_put_transition(property_name, attributes));
LibJS: Prevent object shape transitions during runtime object buildup While initialization common runtime objects like functions, prototypes, etc, we don't really care about tracking transitions for each and every property added to them. This patch puts objects into a "disable transitions" mode while we call initialize() on them. After that, adding more properties will cause new transitions to be generated and added to the chain. This gives a ~10% speed-up on test-js. :^)
2020-10-05 20:08:14 +02:00
} else {
m_shape->add_property_without_transition(property_name, attributes);
m_storage.resize(m_shape->property_count());
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
metadata = shape().lookup(property_name);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(metadata.has_value());
LibJS: Add Object.defineProperty() and start caring about attributes We now care (a little bit) about the "configurable" and "writable" property attributes. Property attributes are stored together with the property name in the Shape object. Forward transitions are not attribute-savvy and will cause poor Shape reuse in the case of multiple same-name properties with different attributes. Oh, and this patch also adds Object.getOwnPropertyDescriptor() :^)
2020-04-09 22:15:26 +02:00
}
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::DefineProperty && !metadata.value().attributes.is_configurable() && attributes != metadata.value().attributes) {
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Disallow reconfig of non-configurable property");
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
if (throw_exceptions)
LibJS: Use String::formatted() for throw_exception() message
2020-10-04 13:55:20 +01:00
vm().throw_exception<TypeError>(global_object(), ErrorType::DescChangeNonConfigurable, property_name.to_display_string());
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return false;
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
}
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
if (mode == PutOwnPropertyMode::DefineProperty && attributes != metadata.value().attributes) {
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (m_shape->is_unique()) {
m_shape->reconfigure_property_in_unique_shape(property_name, attributes);
} else {
set_shape(*m_shape->create_configure_transition(property_name, attributes));
}
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
metadata = shape().lookup(property_name);
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Reconfigured property {}, new shape says offset is {} and my storage capacity is {}", property_name.to_display_string(), metadata.value().offset, m_storage.size());
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
}
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
auto value_here = m_storage[metadata.value().offset];
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::Put && !value_here.is_accessor() && !metadata.value().attributes.is_writable()) {
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Disallow write to non-writable property");
LibJS: Throw TypeError on write to non-writable property in strict mode
2021-06-06 00:43:03 +03:00
if (throw_exceptions && vm().in_strict_mode())
vm().throw_exception<TypeError>(global_object(), ErrorType::DescWriteNonWritable, property_name.to_display_string());
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return false;
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
}
if (value.is_empty())
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return true;
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
LibJS: Make NativeProperty a plain Cell instead of an Object This removes the need for NativeProperty objects to have a prototype, which just made things confusing.
2020-06-23 17:56:57 +02:00
if (value_here.is_native_property()) {
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
call_native_property_setter(value_here.as_native_property(), this, value);
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
} else {
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
m_storage[metadata.value().offset] = value;
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
}
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return true;
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
}
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
bool Object::put_own_property_by_index(u32 property_index, Value value, PropertyAttributes attributes, PutOwnPropertyMode mode, bool throw_exceptions)
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
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!(mode == PutOwnPropertyMode::Put && value.is_accessor()));
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
LibJS: Object.preventExtensions should allow property modfication Existing properties on a non-extensible object should be changable and deletable.
2020-07-06 17:17:47 -07:00
auto existing_property = m_indexed_properties.get(nullptr, property_index, false);
auto new_property = !existing_property.has_value();
if (!is_extensible() && new_property) {
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Disallow define_property of non-extensible object");
LibJS: Move "strict mode" state to the call stack Each call frame now knows whether it's executing in strict mode. It's no longer necessary to access the scope stack to find this mode.
2020-10-04 13:54:44 +02:00
if (throw_exceptions && vm().in_strict_mode())
LibJS: Remove a bunch of unnecessary uses of Cell::interpreter() We'll want to get rid of all uses of this, to free up the engine from the old assumption that there's always an Interpreter available.
2020-09-27 20:07:25 +02:00
vm().throw_exception<TypeError>(global_object(), ErrorType::NonExtensibleDefine, property_index);
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
return false;
}
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
if (value.is_accessor()) {
auto& accessor = value.as_accessor();
if (accessor.getter())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_getter();
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
if (accessor.setter())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_setter();
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
}
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
PropertyAttributes existing_attributes = new_property ? 0 : existing_property.value().attributes;
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
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::DefineProperty && !existing_attributes.is_configurable() && attributes != existing_attributes) {
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Disallow reconfig of non-configurable property");
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
if (throw_exceptions)
LibJS: Remove a bunch of unnecessary uses of Cell::interpreter() We'll want to get rid of all uses of this, to free up the engine from the old assumption that there's always an Interpreter available.
2020-09-27 20:07:25 +02:00
vm().throw_exception<TypeError>(global_object(), ErrorType::DescChangeNonConfigurable, property_index);
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
return false;
}
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto value_here = new_property ? Value() : existing_property.value().value;
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::Put && !value_here.is_accessor() && !existing_attributes.is_writable()) {
LibJS: Use dbgln_if() instead of '#if OBJECT_DEBUG'
2021-04-18 18:10:42 +02:00
dbgln_if(OBJECT_DEBUG, "Disallow write to non-writable property");
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
return false;
}
if (value.is_empty())
return true;
LibJS: Make NativeProperty a plain Cell instead of an Object This removes the need for NativeProperty objects to have a prototype, which just made things confusing.
2020-06-23 17:56:57 +02:00
if (value_here.is_native_property()) {
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
call_native_property_setter(value_here.as_native_property(), this, value);
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
} else {
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
m_indexed_properties.put(this, property_index, value, attributes, mode == PutOwnPropertyMode::Put);
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
}
return true;
}
LibJS: Let Object::delete_property() return a bool, not Value Just like the various define_property functions, this should return a bool directly and let the caller deal with wrapping it in a Value, if necessary.
2021-04-10 17:44:12 +02:00
bool Object::delete_property(const PropertyName& property_name)
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (property_name.is_number())
LibJS: Let Object::delete_property() return a bool, not Value Just like the various define_property functions, this should return a bool directly and let the caller deal with wrapping it in a Value, if necessary.
2021-04-10 17:44:12 +02:00
return m_indexed_properties.remove(property_name.as_number());
LibJS: Fix Object::delete_property() with numeric string property - We have to check if the property name is a string before calling as_string() on it - We can't as_number() the same property name but have to use the parsed index number Fixes #3950.
2020-11-04 23:31:47 +00:00
if (property_name.is_string()) {
i32 property_index = property_name.as_string().to_int().value_or(-1);
if (property_index >= 0)
LibJS: Let Object::delete_property() return a bool, not Value Just like the various define_property functions, this should return a bool directly and let the caller deal with wrapping it in a Value, if necessary.
2021-04-10 17:44:12 +02:00
return m_indexed_properties.remove(property_index);
LibJS: Fix Object::delete_property() with numeric string property - We have to check if the property name is a string before calling as_string() on it - We can't as_number() the same property name but have to use the parsed index number Fixes #3950.
2020-11-04 23:31:47 +00:00
}
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
auto metadata = shape().lookup(property_name.to_string_or_symbol());
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (!metadata.has_value())
LibJS: Let Object::delete_property() return a bool, not Value Just like the various define_property functions, this should return a bool directly and let the caller deal with wrapping it in a Value, if necessary.
2021-04-10 17:44:12 +02:00
return true;
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!metadata.value().attributes.is_configurable())
LibJS: Let Object::delete_property() return a bool, not Value Just like the various define_property functions, this should return a bool directly and let the caller deal with wrapping it in a Value, if necessary.
2021-04-10 17:44:12 +02:00
return false;
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
size_t deleted_offset = metadata.value().offset;
ensure_shape_is_unique();
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
shape().remove_property_from_unique_shape(property_name.to_string_or_symbol(), deleted_offset);
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
m_storage.remove(deleted_offset);
LibJS: Let Object::delete_property() return a bool, not Value Just like the various define_property functions, this should return a bool directly and let the caller deal with wrapping it in a Value, if necessary.
2021-04-10 17:44:12 +02:00
return true;
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
}
void Object::ensure_shape_is_unique()
{
if (shape().is_unique())
return;
m_shape = m_shape->create_unique_clone();
}
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
Value Object::get_by_index(u32 property_index) const
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
{
const Object* object = this;
while (object) {
LibJS: Fix array hole and string object indexing prototype indirection This fixes two cases of indexed access (array holes, out-of-bounds string object access) where we would not follow the prototype chain and incorrectly return undefined: // Should be "a", returned undefined Object.setPrototypeOf([,], ["a"])[0] // Should be "a", returned undefined Object.setPrototypeOf(new String(""), new String("a"))[0] The actual fix is simple, instead of returning early if the requested index is past the string's length or within the indexed properties size but has no value, we just continue the prototype chain traversal and get correct behaviour from that.
2021-04-11 17:16:00 +02:00
if (is<StringObject>(*object)) {
auto& string = static_cast<const StringObject&>(*object).primitive_string().string();
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
if (property_index < string.length())
LibJS: Implement indexed access for StringObject
2020-05-01 13:20:47 +01:00
return js_string(heap(), string.substring(property_index, 1));
LibJS: Fix array hole and string object indexing prototype indirection This fixes two cases of indexed access (array holes, out-of-bounds string object access) where we would not follow the prototype chain and incorrectly return undefined: // Should be "a", returned undefined Object.setPrototypeOf([,], ["a"])[0] // Should be "a", returned undefined Object.setPrototypeOf(new String(""), new String("a"))[0] The actual fix is simple, instead of returning early if the requested index is past the string's length or within the indexed properties size but has no value, we just continue the prototype chain traversal and get correct behaviour from that.
2021-04-11 17:16:00 +02:00
} else if (static_cast<size_t>(property_index) < object->m_indexed_properties.array_like_size()) {
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto result = object->m_indexed_properties.get(const_cast<Object*>(this), property_index);
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
return {};
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (result.has_value() && !result.value().value.is_empty())
return result.value().value;
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
}
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
object = object->prototype();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
}
return {};
}
LibJS: Add Object::get_without_side_effects() Similar to Value::to_string_without_side_effects() this is mostly a regular object property lookup, but with the guarantee that it will be side-effect free, i.e. no accessors or native property functions will be called. This is needed when we want to access user-controlled object properties for debug logging, for example. The specific use case will be error objects which will soon no longer have internal name/message properties, so we need to guarantee that printing an error, which may already be the result of an exception, won't blow up in our face :^)
2021-04-11 22:52:25 +02:00
Value Object::get(const PropertyName& property_name, Value receiver, bool without_side_effects) const
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
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
if (property_name.is_number())
return get_by_index(property_name.as_number());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
if (property_name.is_string()) {
LibJS: Use PropertyName::as_string() in Object::get() After we've already checked is_string(), we can use as_string() to avoid a temporary String.
2021-06-05 12:57:29 +02:00
auto& property_string = property_name.as_string();
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
i32 property_index = property_string.to_int().value_or(-1);
if (property_index >= 0)
return get_by_index(property_index);
}
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
LibJS: Only set receiver value fallback once in Object::get()
2021-03-16 21:59:49 +01:00
if (receiver.is_empty())
receiver = Value(this);
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
const Object* object = this;
while (object) {
LibJS: Add Object::get_without_side_effects() Similar to Value::to_string_without_side_effects() this is mostly a regular object property lookup, but with the guarantee that it will be side-effect free, i.e. no accessors or native property functions will be called. This is needed when we want to access user-controlled object properties for debug logging, for example. The specific use case will be error objects which will soon no longer have internal name/message properties, so we need to guarantee that printing an error, which may already be the result of an exception, won't blow up in our face :^)
2021-04-11 22:52:25 +02:00
auto value = object->get_own_property(property_name, receiver, without_side_effects);
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
LibJS: Stop using Optional<Value> in favor of Value's empty state JS::Value already has the empty state ({} or Value() gives you one.) Use this instead of wrapping Value in Optional in some places. I've also added Value::value_or(Value) so you can easily provide a fallback value when one is not present.
2020-04-25 18:43:34 +02:00
if (!value.is_empty())
return value;
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
object = object->prototype();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
}
LibJS: Allow function calls with missing arguments We were interpreting "undefined" as a variable lookup failure in some cases and throwing a ReferenceError exception instead of treating it as the valid value "undefined". This patch wraps the result of variable lookup in Optional<>, which allows us to only throw ReferenceError when lookup actually fails.
2020-03-27 12:54:18 +01:00
return {};
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Add Object::get_without_side_effects() Similar to Value::to_string_without_side_effects() this is mostly a regular object property lookup, but with the guarantee that it will be side-effect free, i.e. no accessors or native property functions will be called. This is needed when we want to access user-controlled object properties for debug logging, for example. The specific use case will be error objects which will soon no longer have internal name/message properties, so we need to guarantee that printing an error, which may already be the result of an exception, won't blow up in our face :^)
2021-04-11 22:52:25 +02:00
Value Object::get_without_side_effects(const PropertyName& property_name) const
{
LibJS: Temporarily clear exception in Object::get_without_side_effects() This would return an empty value once it hits an exception check otherwise. Considering that this mostly is used in situations where we already *do* have an exception (traceback printing, for example), let's make this easier for ourselves to use.
2021-04-24 17:59:28 +02:00
TemporaryClearException clear_exception(vm());
LibJS: Add Object::get_without_side_effects() Similar to Value::to_string_without_side_effects() this is mostly a regular object property lookup, but with the guarantee that it will be side-effect free, i.e. no accessors or native property functions will be called. This is needed when we want to access user-controlled object properties for debug logging, for example. The specific use case will be error objects which will soon no longer have internal name/message properties, so we need to guarantee that printing an error, which may already be the result of an exception, won't blow up in our face :^)
2021-04-11 22:52:25 +02:00
return get(property_name, {}, true);
}
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
bool Object::put_by_index(u32 property_index, Value value)
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!value.is_empty());
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
// If there's a setter in the prototype chain, we go to the setter.
// Otherwise, it goes in the own property storage.
Object* object = this;
while (object) {
auto existing_value = object->m_indexed_properties.get(nullptr, property_index, false);
if (existing_value.has_value()) {
auto value_here = existing_value.value();
if (value_here.value.is_accessor()) {
value_here.value.as_accessor().call_setter(object, value);
return true;
}
LibJS: Make NativeProperty a plain Cell instead of an Object This removes the need for NativeProperty objects to have a prototype, which just made things confusing.
2020-06-23 17:56:57 +02:00
if (value_here.value.is_native_property()) {
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
// FIXME: Why doesn't put_by_index() receive the receiver value from put()?!
auto receiver = this;
call_native_property_setter(value_here.value.as_native_property(), receiver, value);
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
return true;
}
}
object = object->prototype();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
}
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
return put_own_property_by_index(property_index, value, default_attributes, PutOwnPropertyMode::Put);
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
bool Object::put(const PropertyName& property_name, Value value, Value receiver)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
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
if (property_name.is_number())
return put_by_index(property_name.as_number(), value);
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!value.is_empty());
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
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
if (property_name.is_string()) {
auto& property_string = property_name.as_string();
i32 property_index = property_string.to_int().value_or(-1);
if (property_index >= 0)
return put_by_index(property_index, value);
}
auto string_or_symbol = property_name.to_string_or_symbol();
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
if (receiver.is_empty())
receiver = Value(this);
LibJS: Object::put() shouldn't create own properties on prototype chain Unless there is a setter present on the prototype chain, put() should only set own properties on the object itself. Fixes #1588.
2020-04-02 21:34:31 +02:00
// If there's a setter in the prototype chain, we go to the setter.
// Otherwise, it goes in the own property storage.
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 17:39:13 +01:00
Object* object = this;
while (object) {
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
auto metadata = object->shape().lookup(string_or_symbol);
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
if (metadata.has_value()) {
auto value_here = object->m_storage[metadata.value().offset];
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (value_here.is_accessor()) {
LibJS: Handle "receiver" argument in Reflect.{get,set}()
2020-06-25 14:00:13 +01:00
value_here.as_accessor().call_setter(receiver, value);
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
return true;
}
LibJS: Make NativeProperty a plain Cell instead of an Object This removes the need for NativeProperty objects to have a prototype, which just made things confusing.
2020-06-23 17:56:57 +02:00
if (value_here.is_native_property()) {
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
call_native_property_setter(value_here.as_native_property(), receiver, value);
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return true;
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 17:39:13 +01:00
}
}
object = object->prototype();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS+LibWeb: Clear exceptions after call'ing JavaScript functions Decorated Interpreter::call() with [[nodiscard]] to provoke thinking about the returned value at each call site. This is definitely not perfect and we should really start thinking about slimming down the public-facing LibJS interpreter API. Fixes #3136.
2020-08-14 17:31:07 +02:00
return false;
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 17:39:13 +01:00
}
LibJS: Remove this_object parameter from get/put own property functions Specifically: - Object::get_own_properties() - Object::put_own_property() - Object::put_own_property_by_index() These APIs make no sense (and are inconsistent, get_own_property() didn't have this parameter, for example) - and as expected we were always passing in the same object we were calling the method on anyway.
2021-04-05 18:04:55 +02:00
return put_own_property(string_or_symbol, value, default_attributes, PutOwnPropertyMode::Put);
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02: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
bool Object::define_native_function(const StringOrSymbol& property_name, AK::Function<Value(VM&, GlobalObject&)> native_function, i32 length, PropertyAttributes attribute)
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
{
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: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
String function_name;
if (property_name.is_string()) {
function_name = property_name.as_string();
} else {
LibJS: Use String::formatted() in various other places
2020-10-04 15:18:52 +01:00
function_name = String::formatted("[{}]", property_name.as_symbol()->description());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
}
LibJS: Remove unused argument in NativeFunction constructor
2020-09-20 19:11:11 +02:00
auto* function = NativeFunction::create(global_object(), function_name, move(native_function));
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
function->define_property_without_transition(vm.names.length, Value(length), Attribute::Configurable);
if (vm.exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
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
function->define_property_without_transition(vm.names.name, js_string(vm.heap(), function_name), Attribute::Configurable);
if (vm.exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return {};
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
return define_property(property_name, function, attribute);
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
}
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
bool Object::define_native_property(const StringOrSymbol& property_name, AK::Function<Value(VM&, GlobalObject&)> getter, AK::Function<void(VM&, GlobalObject&, Value)> setter, PropertyAttributes attribute)
LibJS: Add a mechanism for callback-based object properties This patch adds NativeProperty, which can be used to implement object properties that have C++ getters and/or setters. Use this to move String.prototype.length to its correct place. :^)
2020-03-15 18:15:44 +01:00
{
LibJS: Use allocate_without_global_object for primitive cell types More steps towards multiple global object support. Primitive cells like strings, bigints, etc, don't actually have any connection to the global object. Use the explicit API to clarify this.
2020-07-24 20:46:55 +02:00
return define_property(property_name, heap().allocate_without_global_object<NativeProperty>(move(getter), move(setter)), attribute);
LibJS: Add a mechanism for callback-based object properties This patch adds NativeProperty, which can be used to implement object properties that have C++ getters and/or setters. Use this to move String.prototype.length to its correct place. :^)
2020-03-15 18:15:44 +01:00
}
LibJS: Implement Object.defineProperties()
2021-04-10 18:39:11 +02:00
// 20.1.2.3.1 ObjectDefineProperties, https://tc39.es/ecma262/#sec-objectdefineproperties
void Object::define_properties(Value properties)
{
auto& vm = this->vm();
auto* props = properties.to_object(global_object());
if (!props)
return;
auto keys = props->get_own_properties(PropertyKind::Key);
if (vm.exception())
return;
struct NameAndDescriptor {
PropertyName name;
PropertyDescriptor descriptor;
};
Vector<NameAndDescriptor> descriptors;
for (auto& key : keys) {
auto property_name = PropertyName::from_value(global_object(), key);
auto property_descriptor = props->get_own_property_descriptor(property_name);
if (property_descriptor.has_value() && property_descriptor->attributes.is_enumerable()) {
auto descriptor_object = props->get(property_name);
if (vm.exception())
return;
if (!descriptor_object.is_object()) {
vm.throw_exception<TypeError>(global_object(), ErrorType::NotAnObject, descriptor_object.to_string_without_side_effects());
return;
}
auto descriptor = PropertyDescriptor::from_dictionary(vm, descriptor_object.as_object());
if (vm.exception())
return;
descriptors.append({ property_name, descriptor });
}
}
for (auto& [name, descriptor] : descriptors) {
// FIXME: The spec has both of this handled by DefinePropertyOrThrow(O, P, desc).
// We should invest some time in improving object property handling, it not being
// super close to the spec makes this and other things unnecessarily complicated.
if (descriptor.is_accessor_descriptor())
define_accessor(name, descriptor.getter, descriptor.setter, descriptor.attributes);
else
define_property(name, descriptor.value, descriptor.attributes);
}
}
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 Object::visit_edges(Cell::Visitor& visitor)
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
{
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
Cell::visit_edges(visitor);
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
visitor.visit(m_shape);
LibJS: Object needs to protect values in its storage Otherwise the garbage collector will eat them way too soon! This made it impossible to use "js -g" without crashing.
2020-04-06 12:33:27 +02:00
for (auto& value : m_storage)
visitor.visit(value);
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
LibJS: Make marking object indexed properties less allocation-heavy We were building up a vector with all the values in an object's indexed property storage, and then iterating over the vector to mark values. Instead of this, simply iterate over the property storage directly. :^)
2020-12-08 13:33:01 +01:00
m_indexed_properties.for_each_value([&visitor](auto& value) {
visitor.visit(value);
});
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
bool Object::has_property(const PropertyName& property_name) const
LibJS: Add Object::has_property() Like Object::has_own_property() but going down the prototype chain.
2020-04-30 20:03:40 +01:00
{
const Object* object = this;
while (object) {
if (object->has_own_property(property_name))
return true;
object = object->prototype();
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 16:46:45 +02:00
if (vm().exception())
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
return false;
LibJS: Add Object::has_property() Like Object::has_own_property() but going down the prototype chain.
2020-04-30 20:03:40 +01:00
}
return false;
}
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
bool Object::has_own_property(const PropertyName& property_name) const
LibJS: Add ObjectPrototype and implement hasOwnProperty() All Objects will now have ObjectPrototype as their prototype, unless overridden.
2020-03-15 15:25:43 +01:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(property_name.is_valid());
LibJS: ASSERT(property_name.is_valid()) in more Object methods
2020-11-04 23:29:45 +00:00
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
auto has_indexed_property = [&](u32 index) -> bool {
LibJS: Remove hand-rolled Object is_foo() helpers in favor of RTTI
2021-01-01 17:46:39 +01:00
if (is<StringObject>(*this))
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
return index < static_cast<const StringObject*>(this)->primitive_string().string().length();
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
return m_indexed_properties.has_index(index);
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
};
if (property_name.is_number())
return has_indexed_property(property_name.as_number());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
if (property_name.is_string()) {
i32 property_index = property_name.as_string().to_int().value_or(-1);
if (property_index >= 0)
return has_indexed_property(property_index);
}
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
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
return shape().lookup(property_name.to_string_or_symbol()).has_value();
LibJS: Add ObjectPrototype and implement hasOwnProperty() All Objects will now have ObjectPrototype as their prototype, unless overridden.
2020-03-15 15:25:43 +01:00
}
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
Value Object::ordinary_to_primitive(Value::PreferredType preferred_type) const
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(preferred_type == Value::PreferredType::String || preferred_type == Value::PreferredType::Number);
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
auto& vm = this->vm();
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
Vector<FlyString, 2> method_names;
if (preferred_type == Value::PreferredType::String)
method_names = { vm.names.toString, vm.names.valueOf };
else
method_names = { vm.names.valueOf, vm.names.toString };
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
for (auto& method_name : method_names) {
auto method = get(method_name);
LibJS: Reduce Interpreter& usage in the Object class
2020-09-27 19:57:16 +02:00
if (vm.exception())
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
return {};
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
if (method.is_function()) {
auto result = vm.call(method.as_function(), const_cast<Object*>(this));
if (!result.is_object())
return result;
}
LibJS: Make Object::to_string() call the "toString" property if present
2020-04-05 18:18:24 +02:00
}
LibJS: Implement spec-compliant OrdinaryToPrimitive This renames Object::to_primitive() to Object::ordinary_to_primitive() for two reasons: - No confusion with Value::to_primitive() - To match the spec's name Also change existing uses of Object::to_primitive() to Value::to_primitive() when the spec uses the latter (which will still call Object::ordinary_to_primitive()). Object::to_string() has been removed as it's not needed anymore (and nothing the spec uses). This makes it possible to overwrite an object's toString and valueOf and have them provide results for anything that uses to_primitive() - e.g.: const o = { toString: undefined, valueOf: () => 42 }; Number(o) // 42, previously NaN ["foo", o].toString(); // "foo,42", previously "foo,[object Object]" ++o // 43, previously NaN etc.
2020-11-03 19:52:21 +00:00
vm.throw_exception<TypeError>(global_object(), ErrorType::Convert, "object", preferred_type == Value::PreferredType::String ? "string" : "number");
return {};
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
}
LibJS: Make Object::to_string() call the "toString" property if present
2020-04-05 18:18:24 +02:00
LibJS: Add the same Object::invoke() overloads as VM::call()
2021-03-14 12:01:18 +01:00
Value Object::invoke_internal(const StringOrSymbol& property_name, Optional<MarkedValueList> arguments)
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
{
LibJS: Reduce Interpreter& usage in the Object class
2020-09-27 19:57:16 +02:00
auto& vm = this->vm();
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
auto property = get(property_name).value_or(js_undefined());
LibJS: Reduce Interpreter& usage in the Object class
2020-09-27 19:57:16 +02:00
if (vm.exception())
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
return {};
if (!property.is_function()) {
LibJS: Use String::formatted() for throw_exception() message
2020-10-04 13:55:20 +01:00
vm.throw_exception<TypeError>(global_object(), ErrorType::NotAFunction, property.to_string_without_side_effects());
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
return {};
}
LibJS: Reduce Interpreter& usage in the Object class
2020-09-27 19:57:16 +02:00
return vm.call(property.as_function(), this, move(arguments));
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
}
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
Value Object::call_native_property_getter(NativeProperty& property, Value this_value) const
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
{
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
auto& vm = this->vm();
LibJS: Use regular stack for VM call frames instead of Vector storage Keeping the VM call frames in a Vector could cause them to move around underneath us due to Vector resizing. Avoid this issue by allocating CallFrame objects on the stack and having the VM simply keep a list of pointers to each CallFrame, instead of the CallFrames themselves. Fixes #3830. Fixes #3951.
2020-11-07 11:07:17 +01:00
CallFrame call_frame;
LibJS: Move AST node stack from VM to Interpreter
2021-03-21 12:18:56 +01:00
if (auto* interpreter = vm.interpreter_if_exists())
call_frame.current_node = interpreter->current_node();
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
call_frame.is_strict_mode = vm.in_strict_mode();
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
call_frame.this_value = this_value;
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
vm.push_call_frame(call_frame, global_object());
if (vm.exception())
return {};
LibJS: Make call_native_property_{g,s}etter() take a NativeProperty& Passing in a plain Value and expecting it to be a native property is error prone, let's use a more narrow type and pass a NativeProperty reference directly.
2020-11-22 17:04:40 +00:00
auto result = property.get(vm, global_object());
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
vm.pop_call_frame();
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
return result;
}
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
void Object::call_native_property_setter(NativeProperty& property, Value this_value, Value setter_value) const
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
{
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
auto& vm = this->vm();
LibJS: Use regular stack for VM call frames instead of Vector storage Keeping the VM call frames in a Vector could cause them to move around underneath us due to Vector resizing. Avoid this issue by allocating CallFrame objects on the stack and having the VM simply keep a list of pointers to each CallFrame, instead of the CallFrames themselves. Fixes #3830. Fixes #3951.
2020-11-07 11:07:17 +01:00
CallFrame call_frame;
LibJS: Move AST node stack from VM to Interpreter
2021-03-21 12:18:56 +01:00
if (auto* interpreter = vm.interpreter_if_exists())
call_frame.current_node = interpreter->current_node();
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
call_frame.is_strict_mode = vm.in_strict_mode();
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
call_frame.this_value = this_value;
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
vm.push_call_frame(call_frame, global_object());
if (vm.exception())
return;
LibJS: Forward receiver value to native property getters/setters There's no reason why only (user-defined) accessors would have set the receiver as this value for their getters/setters, this is an oversight.
2020-11-22 17:29:25 +00:00
property.set(vm, global_object(), setter_value);
LibJS: Throw RuntimeError when reaching the end of the stack This prevents stack overflows when calling infinite/deep recursive functions, e.g.: const f = () => f(); f(); JSON.stringify({}, () => ({ foo: "bar" })); new Proxy({}, { get: (_, __, p) => p.foo }).foo; The VM caches a StackInfo object to not slow down function calls considerably. VM::push_call_frame() will throw an exception if necessary (plain Error with "RuntimeError" as its .name).
2020-11-08 12:54:52 +00:00
vm.pop_call_frame();
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Reference in a new issue Copy permalink