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/Userland/Libraries/LibJS/Runtime/Array.h

60 lines
2 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
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.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>
#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>
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: 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+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
static ThrowCompletionOr<Array*> create(Realm&, u64 length, Object* prototype = nullptr);
static Array* create_from(Realm&, Vector<Value> const&);
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>
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
static Array* create_from(Realm& realm, Span<T const> 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 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: Make Array constructor take its prototype Let's start moving towards native JS objects taking their prototype as a constructor argument. This will eventually allow us to move prototypes off of Interpreter and into GlobalObject.
2020-04-17 16:24:01 +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: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 14:01:24 +00:00
virtual ThrowCompletionOr<Optional<PropertyDescriptor>> internal_get_own_property(PropertyKey const&) const override;
virtual ThrowCompletionOr<bool> internal_define_own_property(PropertyKey const&, PropertyDescriptor const&) override;
virtual ThrowCompletionOr<bool> internal_delete(PropertyKey const&) override;
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 override;
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
[[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: 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);
ThrowCompletionOr<MarkedVector<Value>> sort_indexed_properties(VM&, Object const&, size_t length, Function<ThrowCompletionOr<double>(Value, Value)> const& sort_compare, bool skip_holes);
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