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);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
GC_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:
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
static ThrowCompletionOr<GC::Ref<Array>> create(Realm&, u64 length, Object* prototype = nullptr);
static GC::Ref<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>
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
static GC::Ref<Array> create_from(Realm& realm, Value const (&values)[N])
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
{
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>
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
static GC::Ref<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
{
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
auto values = GC::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;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
virtual ThrowCompletionOr<GC::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,
};
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
ThrowCompletionOr<GC::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