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.h

196 lines
8.1 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
*/
#pragma once
#include <AK/HashMap.h>
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
#include <AK/String.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 <LibJS/Forward.h>
LibJS: Move Cell.{cpp,h} from Runtime/ to Heap/
2021-05-17 19:50:20 +02:00
#include <LibJS/Heap/Cell.h>
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
#include <LibJS/Runtime/IndexedProperties.h>
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
#include <LibJS/Runtime/MarkedValueList.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/PrimitiveString.h>
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
#include <LibJS/Runtime/PropertyName.h>
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
#include <LibJS/Runtime/Shape.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 RTTI for inheritance checks This replaces the hand-rolled string-based inheritance check tech.
2021-01-01 17:00:20 +01:00
#define JS_OBJECT(class_, base_class) \
public: \
using Base = base_class; \
virtual const char* class_name() const override { return #class_; }
LibJS+LibWeb: Add JS::Object::inherits(class_name) To allow implementing the DOM class hierarchy in JS bindings, this patch adds an inherits() function that can be used to ask an Object if it inherits from a specific C++ class (by name). The necessary overrides are baked into each Object subclass by the new JS_OBJECT macro, which works similarly to C_OBJECT in LibCore. Thanks to @Dexesttp for suggesting this approach. :^)
2020-06-21 15:14:02 +02:00
LibJS: 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
struct PropertyDescriptor {
PropertyAttributes attributes;
Value value;
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
FunctionObject* getter { nullptr };
FunctionObject* setter { nullptr };
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: 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
static PropertyDescriptor from_dictionary(VM&, const 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
bool is_accessor_descriptor() const { return getter || setter; }
bool is_data_descriptor() const { return !(value.is_empty() && !attributes.has_writable()); }
bool is_generic_descriptor() const { return !is_accessor_descriptor() && !is_data_descriptor(); }
};
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
class Object : public Cell {
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
public:
LibJS: Replace Object's create_empty() with create() taking a prototype This now matches the spec's OrdinaryObjectCreate() across the board: instead of implicitly setting the created object's prototype to %Object.prototype% and then in many cases setting it to a nullptr right away, it now has an 'Object* prototype' parameter with _no default value_. This makes the code easier to compare with the spec, very clear in terms of what prototype is being used as well as avoiding unnecessary shape transitions. Also fixes a couple of cases were we weren't setting the correct prototype. There's no reason to assume that the object would not be empty (as in having own properties), so let's follow our existing pattern of Type::create(...) and simply call it 'create'.
2021-06-16 20:52:30 +01:00
static Object* create(GlobalObject&, Object* prototype);
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
explicit Object(Object& prototype);
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
explicit Object(Shape&);
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
virtual void initialize(GlobalObject&) override;
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
virtual ~Object();
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: 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
enum class PropertyKind {
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
Key,
Value,
KeyAndValue,
};
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
enum class GetOwnPropertyReturnType {
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
All,
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
StringOnly,
SymbolOnly,
};
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
enum class PutOwnPropertyMode {
Put,
DefineProperty,
};
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
enum class IntegrityLevel {
Sealed,
Frozen,
};
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
Shape& shape() { return *m_shape; }
const Shape& shape() const { return *m_shape; }
LibJS: Allow Shape without a global object It would be nice to be able to cache some shapes globally in the VM, but then they can't be tied to a specific global object. So let's just get rid of the requirement that shapes are tied to a global object.
2020-11-28 13:58:20 +01:00
GlobalObject& global_object() const { return *shape().global_object(); }
LibJS: Always keep a reference to the global object in Shape We need to move towards supporting multiple global objects, which will be a large refactoring. To keep it manageable, let's do it in steps, starting with giving Object a way to find the GlobalObject it lives inside by asking its Shape for it.
2020-06-08 12:15:58 +02:00
LibJS: Replace boolean without_side_effects parameters with an enum
2021-06-17 03:12:41 +03:00
virtual Value get(const PropertyName&, Value receiver = {}, AllowSideEffects = AllowSideEffects::Yes) const;
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 get_without_side_effects(const PropertyName&) 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
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
virtual bool has_property(const PropertyName&) const;
bool has_own_property(const PropertyName&) 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
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
virtual bool put(const PropertyName&, Value, Value receiver = {});
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: Replace boolean without_side_effects parameters with an enum
2021-06-17 03:12:41 +03:00
Value get_own_property(const PropertyName&, Value receiver, AllowSideEffects = AllowSideEffects::Yes) const;
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 get_own_properties(PropertyKind, bool only_enumerable_properties = false, GetOwnPropertyReturnType = GetOwnPropertyReturnType::All) const;
MarkedValueList get_enumerable_own_property_names(PropertyKind) const;
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
virtual Optional<PropertyDescriptor> get_own_property_descriptor(const PropertyName&) const;
Value get_own_property_descriptor_object(const PropertyName&) const;
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: 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
virtual bool define_property(const StringOrSymbol& property_name, const Object& descriptor, bool throw_exceptions = true);
bool define_property(const PropertyName&, Value value, PropertyAttributes attributes = default_attributes, bool throw_exceptions = true);
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 define_property_without_transition(const PropertyName&, Value value, PropertyAttributes attributes = default_attributes, bool throw_exceptions = true);
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
bool define_accessor(const PropertyName&, FunctionObject* getter, FunctionObject* setter, PropertyAttributes attributes = default_attributes, bool throw_exceptions = true);
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: Stop qualifying AK::Function Now that JS function objects are JS::FunctionObject, we can stop qualifying AK::Function and just say "Function" everywhere. Nice. :^)
2021-06-27 22:38:42 +02:00
bool define_native_function(PropertyName const&, Function<Value(VM&, GlobalObject&)>, i32 length = 0, PropertyAttributes attributes = default_attributes);
bool define_native_property(PropertyName const&, Function<Value(VM&, GlobalObject&)> getter, Function<void(VM&, GlobalObject&, Value)> setter, PropertyAttributes attributes = default_attributes);
bool define_native_accessor(PropertyName const&, Function<Value(VM&, GlobalObject&)> getter, Function<Value(VM&, GlobalObject&)> setter, PropertyAttributes attributes = default_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: Implement Object.defineProperties()
2021-04-10 18:39:11 +02:00
void define_properties(Value properties);
LibJS: Add parameter to delete_property since we need DeleteOrThrow
2021-06-21 16:06:32 +02:00
virtual bool delete_property(PropertyName const&, bool force_throw_exception = false);
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: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 20:29:57 +01:00
virtual bool is_array() const { return false; }
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
virtual bool is_function() const { return false; }
LibJS: Add six typed arrays (signed and unsigned 8/16/32-bit) This patch adds six of the standard type arrays and tries to share as much code as possible: - Uint8Array - Uint16Array - Uint32Array - Int8Array - Int16Array - Int32Array
2020-12-01 21:05:25 +01:00
virtual bool is_typed_array() const { return false; }
LibJS: Add fast_is<T> for StringObject and GlobalObject Both of these are quite hot in profiles.
2021-03-19 11:28:44 +01:00
virtual bool is_string_object() const { return false; }
virtual bool is_global_object() const { return false; }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_proxy_object() const { return false; }
virtual bool is_native_function() const { return false; }
LibJS: Add the CreateMappedArgumentsObject abstract operation This patch adds a new ArgumentsObject class to represent what the spec calls "Arguments Exotic Objects" These are constructed by the new CreateMappedArgumentsObject when the `arguments` identifier is resolved in a callee context. The implementation is incomplete and doesn't yet support mapping of the parameter variables to the indexed properties of `arguments`.
2021-06-28 13:26:01 +02:00
virtual bool is_ordinary_function_object() const { return false; }
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: Implement support for the [[IsHTMLDDA]] internal slot Best regards from Annex B and document.all :^)
2021-06-20 17:08:29 +01:00
// B.3.7 The [[IsHTMLDDA]] Internal Slot, https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
virtual bool is_htmldda() const { return false; }
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
virtual const char* class_name() const override { return "Object"; }
LibJS: Rename Cell::visit_children() => Cell::visit_edges() The GC heap is really a graph of cells, so "children" didn't quite feel appropriate here.
2020-11-28 14:33:36 +01:00
virtual void visit_edges(Cell::Visitor&) override;
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 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
virtual Object* prototype();
virtual const Object* prototype() const;
virtual bool set_prototype(Object* prototype);
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 has_prototype(const Object* prototype) const;
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: 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
virtual bool is_extensible() const { return m_is_extensible; }
virtual bool prevent_extensions();
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
bool set_integrity_level(IntegrityLevel);
LibJS: Implement Object.isFrozen() and Object.isSealed()
2021-04-06 22:45:12 +02:00
bool test_integrity_level(IntegrityLevel);
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
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
virtual Value value_of() const { return Value(const_cast<Object*>(this)); }
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
virtual Value ordinary_to_primitive(Value::PreferredType preferred_type) 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
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
Value get_direct(size_t index) const { return m_storage[index]; }
LibJS: Add Object::own_properties() convenience accessor
2020-03-26 12:19:01 +01: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
const IndexedProperties& indexed_properties() const { return m_indexed_properties; }
IndexedProperties& indexed_properties() { return m_indexed_properties; }
void set_indexed_property_elements(Vector<Value>&& values) { m_indexed_properties = IndexedProperties(move(values)); }
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: Add the same Object::invoke() overloads as VM::call()
2021-03-14 12:01:18 +01:00
[[nodiscard]] Value invoke_internal(const StringOrSymbol& property_name, Optional<MarkedValueList> arguments);
template<typename... Args>
[[nodiscard]] ALWAYS_INLINE Value invoke(const StringOrSymbol& property_name, Args... args)
{
if constexpr (sizeof...(Args) > 0) {
MarkedValueList arglist { heap() };
(..., arglist.append(move(args)));
return invoke(property_name, move(arglist));
}
return invoke(property_name);
}
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
LibJS: Make global objects have unique shape from the start There's no point in trying to achieve shape sharing for global objects, so we can simply make the shape unique from the start and avoid making a transition chain.
2020-10-04 22:56:45 +02:00
void ensure_shape_is_unique();
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
void enable_transitions() { m_transitions_enabled = true; }
void disable_transitions() { m_transitions_enabled = false; }
LibJS: Add fast_is<T> for StringObject and GlobalObject Both of these are quite hot in profiles.
2021-03-19 11:28:44 +01:00
template<typename T>
bool fast_is() const = delete;
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
protected:
enum class GlobalObjectTag { Tag };
enum class ConstructWithoutPrototypeTag { Tag };
explicit Object(GlobalObjectTag);
Object(ConstructWithoutPrototypeTag, GlobalObject&);
LibJS: Replace boolean without_side_effects parameters with an enum
2021-06-17 03:12:41 +03:00
virtual Value get_by_index(u32 property_index, AllowSideEffects = AllowSideEffects::Yes) const;
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
virtual bool put_by_index(u32 property_index, Value);
LibJS: Have Uint8ClampedArray delegate OOB accesses to JS::Object Uint8ClampedArray itself only cares about legitimate in-bounds accesses since that's what where the specialization happens.
2020-12-01 17:10:57 +01:00
private:
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 put_own_property(const StringOrSymbol& property_name, Value, PropertyAttributes attributes, PutOwnPropertyMode = PutOwnPropertyMode::Put, bool throw_exceptions = true);
bool put_own_property_by_index(u32 property_index, Value, PropertyAttributes attributes, PutOwnPropertyMode = PutOwnPropertyMode::Put, bool throw_exceptions = 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
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 call_native_property_getter(NativeProperty& property, Value this_value) const;
void call_native_property_setter(NativeProperty& property, Value this_value, Value) const;
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -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
void set_shape(Shape&);
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
bool m_is_extensible { true };
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
bool m_transitions_enabled { 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
Shape* m_shape { nullptr };
Vector<Value> m_storage;
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
IndexedProperties m_indexed_properties;
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 the same Object::invoke() overloads as VM::call()
2021-03-14 12:01:18 +01:00
template<>
[[nodiscard]] ALWAYS_INLINE Value Object::invoke(const StringOrSymbol& property_name, MarkedValueList arguments) { return invoke_internal(property_name, move(arguments)); }
template<>
[[nodiscard]] ALWAYS_INLINE Value Object::invoke(const StringOrSymbol& property_name, Optional<MarkedValueList> arguments) { return invoke_internal(property_name, move(arguments)); }
template<>
[[nodiscard]] ALWAYS_INLINE Value Object::invoke(const StringOrSymbol& property_name) { return invoke(property_name, Optional<MarkedValueList> {}); }
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