beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 15:40:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Libraries/LibJS/Runtime/Array.h

75 lines
2.5 KiB
C
Raw Normal View History

LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 11:19:50 +00:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
LibJS: Implement the CompareArrayElements AO
2022-06-13 06:53:58 +00:00
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00: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 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
*/
#pragma once
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
#include <AK/Assertions.h>
LibJS: Add a fallible variant of Array::create_from
2023-01-22 03:34:42 +00:00
#include <AK/Concepts.h>
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
#include <AK/Function.h>
LibJS: Allow calling Array::create_from without allocating a Vector This method works as-is with a Span instead of a Vector (with some minor const correctness adjustments).
2022-01-30 21:52:40 +00:00
#include <AK/Span.h>
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
#include <AK/Vector.h>
LibJS: Convert internal_get_own_property() to ThrowCompletionOr
2021-09-29 16:53:57 +00:00
#include <LibJS/Runtime/Completion.h>
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
#include <LibJS/Runtime/Object.h>
LibJS: Add a fallible variant of Array::create_from
2023-01-22 03:34:42 +00:00
#include <LibJS/Runtime/VM.h>
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
namespace JS {
LibJS: Make ArrayPrototype an Array object https://tc39.es/ecma262/#sec-properties-of-the-array-prototype-object The Array prototype object: [...] is an Array exotic object and has the internal methods specified for such objects. NOTE: The Array prototype object is specified to be an Array exotic object to ensure compatibility with ECMAScript code that was created prior to the ECMAScript 2015 specification.
2021-02-24 08:48:29 +00:00
class Array : public Object {
LibJS+LibWeb: Add JS::Object::inherits(class_name) To allow implementing the DOM class hierarchy in JS bindings, this patch adds an inherits() function that can be used to ask an Object if it inherits from a specific C++ class (by name). The necessary overrides are baked into each Object subclass by the new JS_OBJECT macro, which works similarly to C_OBJECT in LibCore. Thanks to @Dexesttp for suggesting this approach. :^)
2020-06-21 13:14:02 +00:00
JS_OBJECT(Array, Object);
LibJS: Segregate GC-allocated objects by type This patch adds two macros to declare per-type allocators: - JS_DECLARE_ALLOCATOR(TypeName) - JS_DEFINE_ALLOCATOR(TypeName) When used, they add a type-specific CellAllocator that the Heap will delegate allocation requests to. The result of this is that GC objects of the same type always end up within the same HeapBlock, drastically reducing the ability to perform type confusion attacks. It also improves HeapBlock utilization, since each block now has cells sized exactly to the type used within that block. (Previously we only had a handful of block sizes available, and most GC allocations ended up with a large amount of slack in their tails.) There is a small performance hit from this, but I'm sure we can make up for it elsewhere. Note that the old size-based allocators still exist, and we fall back to them for any type that doesn't have its own CellAllocator.
2023-11-19 08:45:05 +00:00
JS_DECLARE_ALLOCATOR(Array);
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 13:14:02 +00:00
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
public:
LibJS: Convert Array::create{,_from}() to NonnullGCPtr
2022-12-13 20:49:49 +00:00
static ThrowCompletionOr<NonnullGCPtr<Array>> create(Realm&, u64 length, Object* prototype = nullptr);
LibJS: Remove Array::create_from overload that accepts a plain vector There's no need to have overloads for both a span and a vector.
2024-10-31 16:37:36 +00:00
static NonnullGCPtr<Array> create_from(Realm&, ReadonlySpan<Value>);
LibJS: Add a fallible variant of Array::create_from
2023-01-22 03:34:42 +00:00
LibJS: Add an Array::create_from overload to accept a plain array This is just a wrapper to easily construct an Array from a span. This avoids creating a Vector of values that are possiby Objects. One such case is in ArrayIteratorPrototype::next.
2024-10-31 16:29:31 +00:00
template<size_t N>
static NonnullGCPtr<Array> create_from(Realm& realm, Value const (&values)[N])
{
return create_from(realm, ReadonlySpan<Value> { values, N });
}
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
// Non-standard but equivalent to CreateArrayFromList.
template<typename T>
Everywhere: Use ReadonlySpan<T> instead of Span<T const>
2023-02-05 19:02:54 +00:00
static NonnullGCPtr<Array> create_from(Realm& realm, ReadonlySpan<T> elements, Function<Value(T const&)> map_fn)
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
{
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-15 23:20:49 +00:00
auto values = MarkedVector<Value> { realm.heap() };
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
values.ensure_capacity(elements.size());
LibJS+Everywhere: Remove VM::exception() and most related functions This commit removes all exception related code: Remove VM::exception(), VM::throw_exception() etc. Any leftover throw_exception calls are moved to throw_completion. The one method left is clear_exception() which is now a no-op. Most of these calls are just to clear whatever exception might have been thrown when handling a Completion. So to have a cleaner commit this will be removed in a next commit. It also removes the actual Exception and TemporaryClearException classes since these are no longer used. In any spot where the exception was actually used an attempt was made to preserve that behavior. However since it is no longer tracked by the VM we cannot access exceptions which were thrown in previous calls. There are two such cases which might have different behavior: - In Web::DOM::Document::interpreter() the on_call_stack_emptied hook used to print any uncaught exception but this is now no longer possible as the VM does not store uncaught exceptions. - In js the code used to be interruptable by throwing an exception on the VM. This is no longer possible but was already somewhat fragile before as you could happen to throw an exception just before a VERIFY.
2022-02-07 14:12:41 +00:00
for (auto const& element : elements)
LibJS: Add Array::create_from() for generic Vector<T> It relies on a mapper function to convert each T& to a JS::Value. This allows us to avoid awkward Vector<T> to MarkedValueList conversion at the call site.
2021-09-04 16:07:46 +00:00
values.append(map_fn(element));
LibJS+Everywhere: Remove VM::exception() and most related functions This commit removes all exception related code: Remove VM::exception(), VM::throw_exception() etc. Any leftover throw_exception calls are moved to throw_completion. The one method left is clear_exception() which is now a no-op. Most of these calls are just to clear whatever exception might have been thrown when handling a Completion. So to have a cleaner commit this will be removed in a next commit. It also removes the actual Exception and TemporaryClearException classes since these are no longer used. In any spot where the exception was actually used an attempt was made to preserve that behavior. However since it is no longer tracked by the VM we cannot access exceptions which were thrown in previous calls. There are two such cases which might have different behavior: - In Web::DOM::Document::interpreter() the on_call_stack_emptied hook used to print any uncaught exception but this is now no longer possible as the VM does not store uncaught exceptions. - In js the code used to be interruptable by throwing an exception on the VM. This is no longer possible but was already somewhat fragile before as you could happen to throw an exception just before a VERIFY.
2022-02-07 14:12:41 +00:00
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-15 23:20:49 +00:00
return Array::create_from(realm, values);
LibJS: Add a fallible variant of Array::create_from
2023-01-22 03:34:42 +00:00
}
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 16:25:06 +00:00
virtual ~Array() override = default;
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
LibJS: Mark classes and virtual functions `final` where possible These cases were found with GCC's `-Wsuggest-final-{types,methods}` warnings, which catch calls that could have been devirtualized had we declared the functions `final` in the source. To reproduce, Link Time Optimization needs to be enabled. The easiest way to achieve this is to set the `CMAKE_INTERPROCEDURAL_OPTIMIZATION` cache variable to `ON`. The `.incbin` directive in LibCompress' Brotli decompressor might needs to be changed to an absolute path for this to work. This commit also removes a pair of unused virtual functions.
2023-08-13 10:53:46 +00:00
virtual ThrowCompletionOr<Optional<PropertyDescriptor>> internal_get_own_property(PropertyKey const&) const override final;
LibJS+LibWeb: Prevent double invocation of `[[GetOwnProperty]]` The `[[GetOwnProperty]]` internal method invocation in `OrdinarySetWithOwnDescriptor` was being invocated again with the same parameters in the `[[DefineOwnProperty]]` internal method that is also later called in `OrdinarySetWithOwnDescriptor`. The `PlatformObject.[[DefineOwnProperty]]` has similair logic. This change adds an optional parameter to the `[[DefineOwnProperty]]` internal method so the results of the previous `[[GetOwnProperty]]` internal method invocation can be re-used.
2024-11-01 20:03:18 +00:00
virtual ThrowCompletionOr<bool> internal_define_own_property(PropertyKey const&, PropertyDescriptor const&, Optional<PropertyDescriptor>* precomputed_get_own_property = nullptr) override final;
LibWeb/WebIDL: Introduce ObservableArray ObservableArray inherits from JS::Array and overrides `internal_set` and `internal_delete` to run an interceptor callback when an indexed item is added or deleted.
2024-03-07 22:29:25 +00:00
virtual ThrowCompletionOr<bool> internal_delete(PropertyKey const&) override;
LibJS: Mark classes and virtual functions `final` where possible These cases were found with GCC's `-Wsuggest-final-{types,methods}` warnings, which catch calls that could have been devirtualized had we declared the functions `final` in the source. To reproduce, Link Time Optimization needs to be enabled. The easiest way to achieve this is to set the `CMAKE_INTERPROCEDURAL_OPTIMIZATION` cache variable to `ON`. The `.incbin` directive in LibCompress' Brotli decompressor might needs to be changed to an absolute path for this to work. This commit also removes a pair of unused virtual functions.
2023-08-13 10:53:46 +00:00
virtual ThrowCompletionOr<MarkedVector<Value>> internal_own_property_keys() const override final;
LibJS: Stop using a native property for Array lengths Specifically, replace it with a specification-based implementation that overrides the internal methods that interact with the length property instead.
2021-07-07 00:50:19 +00:00
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-08 02:48:11 +00:00
[[nodiscard]] bool length_is_writable() const { return m_length_writable; }
LibJS: More Interpreter::global_object() removal Also let's settle on calling the operation of fetching the "this" value from the Interpreter and converting it to a specific Object pointer typed_this() since consistency is nice.
2020-06-20 14:25:12 +00:00
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 21:51:28 +00:00
protected:
explicit Array(Object& prototype);
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
private:
LibJS: Convert Array AOs to ThrowCompletionOr
2021-10-21 22:34:06 +00:00
ThrowCompletionOr<bool> set_length(PropertyDescriptor const&);
LibJS: Stop using a native property for Array lengths Specifically, replace it with a specification-based implementation that overrides the internal methods that interact with the length property instead.
2021-07-07 00:50:19 +00:00
bool m_length_writable { true };
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
};
LibJS: Update spec numbers / text for the Change Array by Copy proposal This proposal has been merged into the main ECMA-262 spec. See: https://github.com/tc39/ecma262/commit/4a32716 Note this includes some editorial changes made when the proposal was merged into the main spec, but are not in the proposal spec.
2023-03-20 16:24:48 +00:00
enum class Holes {
SkipHoles,
ReadThroughHoles,
};
ThrowCompletionOr<MarkedVector<Value>> sort_indexed_properties(VM&, Object const&, size_t length, Function<ThrowCompletionOr<double>(Value, Value)> const& sort_compare, Holes holes);
LibJS: Replace GlobalObject with VM in Array AOs [Part 15/19]
2022-08-21 16:54:08 +00:00
ThrowCompletionOr<double> compare_array_elements(VM&, Value x, Value y, FunctionObject* comparefn);
LibJS: Implement the CompareArrayElements AO
2022-06-13 06:53:58 +00:00
LibJS: Parse ArrayExpression and start implementing Array objects Note that property lookup is not functional yet.
2020-03-20 19:29:57 +00:00
}
Reference in a new issue Copy permalink