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

223 lines
9.2 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>
LibJS: Add Object constructor allowing null prototype
2022-02-09 19:34:33 +00:00
* Copyright (c) 2020-2022, 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
LibJS: Avoid pointless transitions and metadata lookups in storage_set() - Replace the misleading abuse of the m_transitions_enabled flag for the fast path without lookup with a new m_initialized boolean that's set either by Heap::allocate() after calling the Object's initialize(), or by the GlobalObject in its special initialize_global_object(). This makes it work regardless of the shape's uniqueness. - When we're adding a new property past the initialization phase, there's no need to do a second metadata lookup to retrieve the storage value offset - it's known to always be the shape's property count minus one. Also, instead of doing manual storage resizing and assignment via indexing, just use Vector::append(). - When we didn't add a new property but are overwriting an existing one, the property count and therefore storage value offset doesn't change, so we don't have to retrieve it either. As a result, Object::set_shape() is now solely responsible for updating the m_shape pointer and is not resizing storage anymore, so I moved it into the header.
2021-08-28 17:12:14 +01:00
#include <AK/Badge.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/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>
DevTools+LibJS+LibWeb: Change class_name to use StringView This helps make the overall codebase consistent. `class_name()` in `Kernel` is always `StringView`, but not elsewhere. Additionally, this results in the `strlen` (which needs to be done when printing or other operations) always being computed at compile-time.
2022-03-16 18:26:49 -06:00
#include <AK/StringView.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: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
#include <LibJS/Heap/MarkedVector.h>
LibJS: Convert internal_get_prototype_of() to ThrowCompletionOr
2021-09-28 23:30:17 +01:00
#include <LibJS/Runtime/Completion.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 "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 slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
#include <LibJS/Runtime/PrivateEnvironment.h>
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
#include <LibJS/Runtime/PropertyDescriptor.h>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
#include <LibJS/Runtime/PropertyKey.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: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
#define JS_OBJECT(class_, base_class) \
public: \
using Base = base_class; \
virtual StringView class_name() const override \
{ \
Everywhere: Add sv suffix to strings relying on StringView(char const*) Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-07-11 17:32:29 +00:00
return #class_##sv; \
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
}
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 slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
struct PrivateElement {
enum class Kind {
Field,
Method,
Accessor
};
PrivateName key;
Kind kind { Kind::Field };
Value 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
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: Add Object constructor allowing null prototype
2022-02-09 19:34:33 +00:00
Object(GlobalObject&, Object* prototype);
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;
Libraries: Use default constructors/destructors in LibJS https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 10:25:06 -06:00
virtual ~Object() = default;
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: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
enum class IntegrityLevel {
Sealed,
Frozen,
};
LibJS: Replace the boolean argument of Object::set with an enum class This is more serenity-esque and also makes pointing out missing exception checks during reviews much easier.
2021-07-16 15:16:27 +03:00
enum class ShouldThrowExceptions {
No,
Yes,
};
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// Please DO NOT make up your own non-standard methods unless you
// have a very good reason to do so. If any object abstract
// operation from the spec is missing, add it instead.
// Functionality for implementation details like shapes and
// property storage are obviously exempt from this rule :^)
//
// Methods named [[Foo]]() in the spec are named internal_foo()
// here, as they are "The [[Foo]] internal method of a ... object".
// They must be virtual and may be overridden. All other methods
LibJS: Fix a typo in a comment in Object.h
2021-09-29 19:20:28 +01:00
// follow the regular PascalCase name converted to camel_case
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// naming convention and must not be virtual.
// 7.1 Type Conversion, https://tc39.es/ecma262/#sec-type-conversion
LibJS: Convert ordinary_to_primitive() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-02 15:13:09 +01:00
ThrowCompletionOr<Value> ordinary_to_primitive(Value::PreferredType preferred_type) const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 7.2 Testing and Comparison Operations, https://tc39.es/ecma262/#sec-testing-and-comparison-operations
LibJS: Convert is_extensible() to ThrowCompletionOr
2021-10-02 15:27:37 +01:00
ThrowCompletionOr<bool> is_extensible() const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 7.3 Operations on Objects, https://tc39.es/ecma262/#sec-operations-on-objects
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<Value> get(PropertyKey const&) const;
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
ThrowCompletionOr<void> set(PropertyKey const&, Value, ShouldThrowExceptions);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<bool> create_data_property(PropertyKey const&, Value);
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
ThrowCompletionOr<void> create_method_property(PropertyKey const&, Value);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<bool> create_data_property_or_throw(PropertyKey const&, Value);
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
void create_non_enumerable_data_property_or_throw(PropertyKey const&, Value);
ThrowCompletionOr<void> define_property_or_throw(PropertyKey const&, PropertyDescriptor const&);
ThrowCompletionOr<void> delete_property_or_throw(PropertyKey const&);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<bool> has_property(PropertyKey const&) const;
ThrowCompletionOr<bool> has_own_property(PropertyKey const&) const;
LibJS: Convert set_integrity_level() to ThrowCompletionOr
2021-10-03 02:20:19 +01:00
ThrowCompletionOr<bool> set_integrity_level(IntegrityLevel);
LibJS: Convert test_integrity_level() to ThrowCompletionOr
2021-10-03 02:21:44 +01:00
ThrowCompletionOr<bool> test_integrity_level(IntegrityLevel) const;
LibJS: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
ThrowCompletionOr<MarkedVector<Value>> enumerable_own_property_names(PropertyKind kind) const;
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
ThrowCompletionOr<void> copy_data_properties(Value source, HashTable<PropertyKey> const& seen_names, GlobalObject& global_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
LibJS: Add slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
PrivateElement* private_element_find(PrivateName const& name);
ThrowCompletionOr<void> private_field_add(PrivateName const& name, Value value);
ThrowCompletionOr<void> private_method_or_accessor_add(PrivateElement element);
ThrowCompletionOr<Value> private_get(PrivateName const& name);
ThrowCompletionOr<void> private_set(PrivateName const& name, Value value);
LibJS: De-duplicate ClassFieldDefinition Records This was defined twice, despite being the very same thing: - ClassElement::ClassFieldDefinition - ECMAScriptFunctionObject::InstanceField Move the former to a new header and use it everywhere. Also update the define_field() AO to take a single field instead of separate name and initializer arguments.
2022-04-20 00:06:45 +02:00
ThrowCompletionOr<void> define_field(ClassFieldDefinition const&);
LibJS: Add slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 10.1 Ordinary Object Internal Methods and Internal Slots, https://tc39.es/ecma262/#sec-ordinary-object-internal-methods-and-internal-slots
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: Convert internal_get_prototype_of() to ThrowCompletionOr
2021-09-28 23:30:17 +01:00
virtual ThrowCompletionOr<Object*> internal_get_prototype_of() const;
LibJS: Convert internal_set_prototype_of() to ThrowCompletionOr
2021-09-28 23:54:42 +01:00
virtual ThrowCompletionOr<bool> internal_set_prototype_of(Object* prototype);
LibJS: Convert internal_is_extensible() to ThrowCompletionOr
2021-09-29 00:02:05 +01:00
virtual ThrowCompletionOr<bool> internal_is_extensible() const;
LibJS: Convert internal_prevent_extensions() to ThrowCompletionOr
2021-09-29 00:13:41 +01:00
virtual ThrowCompletionOr<bool> internal_prevent_extensions();
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
virtual ThrowCompletionOr<Optional<PropertyDescriptor>> internal_get_own_property(PropertyKey const&) const;
virtual ThrowCompletionOr<bool> internal_define_own_property(PropertyKey const&, PropertyDescriptor const&);
virtual ThrowCompletionOr<bool> internal_has_property(PropertyKey const&) const;
virtual ThrowCompletionOr<Value> internal_get(PropertyKey const&, Value receiver) const;
virtual ThrowCompletionOr<bool> internal_set(PropertyKey const&, Value value, Value receiver);
virtual ThrowCompletionOr<bool> internal_delete(PropertyKey const&);
LibJS: Replace uses of MarkedValueList with MarkedVector<Value> This is effectively a drop-in replacement.
2022-02-09 10:06:40 +00:00
virtual ThrowCompletionOr<MarkedVector<Value>> internal_own_property_keys() const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<bool> ordinary_set_with_own_descriptor(PropertyKey const&, Value, Value, Optional<PropertyDescriptor>);
LibJS: Make Object::ordinary_set_with_own_descriptor non-static This needs to be accessible for implementing IDL legacy platform objects.
2021-09-24 19:39:01 +01:00
LibJS: Make ObjectPrototype an immutable prototype exotic object To make this happen, this patch implements the SetImmutablePrototype abstract operation (as a method on Object) and then overrides [[SetPrototypeOf]] on ObjectPrototype.
2021-07-04 23:48:47 +01:00
// 10.4.7 Immutable Prototype Exotic Objects, https://tc39.es/ecma262/#sec-immutable-prototype-exotic-objects
LibJS: Convert set_immutable_prototype() to ThrowCompletionOr
2021-10-03 19:52:13 +01:00
ThrowCompletionOr<bool> set_immutable_prototype(Object* prototype);
LibJS: Make ObjectPrototype an immutable prototype exotic object To make this happen, this patch implements the SetImmutablePrototype abstract operation (as a method on Object) and then overrides [[SetPrototypeOf]] on ObjectPrototype.
2021-07-04 23:48:47 +01:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 20.1 Object Objects, https://tc39.es/ecma262/#sec-object-objects
LibJS: Convert define_properties() to ThrowCompletionOr
2021-10-03 19:54:37 +01:00
ThrowCompletionOr<Object*> define_properties(Value properties);
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
LibJS: Implement the EnumerateObjectProperties AO
2022-03-29 00:18:15 +03:00
// 14.7.5 The for-in, for-of, and for-await-of Statements
Optional<Completion> enumerate_object_properties(Function<Optional<Completion>(Value)>) const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// Implementation-specific storage abstractions
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: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
Optional<ValueAndAttributes> storage_get(PropertyKey const&) const;
bool storage_has(PropertyKey const&) const;
void storage_set(PropertyKey const&, ValueAndAttributes const&);
void storage_delete(PropertyKey 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: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// Non-standard methods
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Value get_without_side_effects(PropertyKey const&) 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
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
void define_direct_property(PropertyKey const& property_key, Value value, PropertyAttributes attributes) { storage_set(property_key, { value, attributes }); };
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
void define_direct_accessor(PropertyKey const&, FunctionObject* getter, FunctionObject* setter, PropertyAttributes attributes);
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: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
void define_native_function(PropertyKey const&, Function<ThrowCompletionOr<Value>(VM&, GlobalObject&)>, i32 length, PropertyAttributes attributes);
void define_native_accessor(PropertyKey const&, Function<ThrowCompletionOr<Value>(VM&, GlobalObject&)> getter, Function<ThrowCompletionOr<Value>(VM&, GlobalObject&)> setter, PropertyAttributes attributes);
LibJS: Convert NativeFunction callback to ThrowCompletionOr
2021-10-19 22:53:27 +03: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
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: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
virtual bool is_ecmascript_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: Make Object.prototype.toString() fully spec compliant - Fix evaluation order: IsArray(O) should always be called and before Get(O, @@toStringTag), previously it was the other way around and IsArray would only be called if @@toStringTag is not a string - Add missing exception checks to both function calls - Add missing builtin tag for arguments object Also, while we're here: - Update variable names to match spec - Add spec step comments
2021-07-05 18:31:56 +01:00
bool has_parameter_map() const { return m_has_parameter_map; }
void set_has_parameter_map() { m_has_parameter_map = true; }
DevTools+LibJS+LibWeb: Change class_name to use StringView This helps make the overall codebase consistent. `class_name()` in `Kernel` is always `StringView`, but not elsewhere. Additionally, this results in the `strlen` (which needs to be done when printing or other operations) always being computed at compile-time.
2022-03-16 18:26:49 -06:00
virtual StringView class_name() const override { return "Object"sv; }
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: 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
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
IndexedProperties const& indexed_properties() const { return m_indexed_properties; }
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& 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: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
Shape& shape() { return *m_shape; }
Shape const& shape() const { return *m_shape; }
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 20:27:20 +02:00
GlobalObject& global_object() const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +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: 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 };
LibJS: Let Shape store a Realm instead of a GlobalObject This is a cautious first step towards being able to create JS objects before a global object has been instantiated.
2022-08-01 20:27:20 +02:00
explicit Object(GlobalObjectTag, Realm&);
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(ConstructWithoutPrototypeTag, GlobalObject&);
LibJS: Add Object::set_prototype() This is just factoring out step "9. Set O.[[Prototype]] to V." of 10.1.2 [[SetPrototypeOf]] into its own method so that we don't have to use internal_set_prototype_of() for setting an object prototype in all cases.
2021-10-02 14:20:39 +01:00
void set_prototype(Object*);
LibJS: Make Object.prototype.toString() fully spec compliant - Fix evaluation order: IsArray(O) should always be called and before Get(O, @@toStringTag), previously it was the other way around and IsArray would only be called if @@toStringTag is not a string - Add missing exception checks to both function calls - Add missing builtin tag for arguments object Also, while we're here: - Update variable names to match spec - Add spec step comments
2021-07-05 18:31:56 +01:00
// [[Extensible]]
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
bool m_is_extensible { true };
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
LibJS: Make Object.prototype.toString() fully spec compliant - Fix evaluation order: IsArray(O) should always be called and before Get(O, @@toStringTag), previously it was the other way around and IsArray would only be called if @@toStringTag is not a string - Add missing exception checks to both function calls - Add missing builtin tag for arguments object Also, while we're here: - Update variable names to match spec - Add spec step comments
2021-07-05 18:31:56 +01:00
// [[ParameterMap]]
bool m_has_parameter_map { false };
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: Avoid pointless transitions and metadata lookups in storage_set() - Replace the misleading abuse of the m_transitions_enabled flag for the fast path without lookup with a new m_initialized boolean that's set either by Heap::allocate() after calling the Object's initialize(), or by the GlobalObject in its special initialize_global_object(). This makes it work regardless of the shape's uniqueness. - When we're adding a new property past the initialization phase, there's no need to do a second metadata lookup to retrieve the storage value offset - it's known to always be the shape's property count minus one. Also, instead of doing manual storage resizing and assignment via indexing, just use Vector::append(). - When we didn't add a new property but are overwriting an existing one, the property count and therefore storage value offset doesn't change, so we don't have to retrieve it either. As a result, Object::set_shape() is now solely responsible for updating the m_shape pointer and is not resizing storage anymore, so I moved it into the header.
2021-08-28 17:12:14 +01:00
void set_shape(Shape& shape) { m_shape = &shape; }
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: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
Object* prototype() { return shape().prototype(); }
Object const* prototype() const { return shape().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
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: Only allocate space for Object private elements if needed Most JavaScript objects don't have private elements, so this reduces the size of typical JS::Object instances by two pointers.
2021-12-08 09:38:31 +01:00
OwnPtr<Vector<PrivateElement>> m_private_elements; // [[PrivateElements]]
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