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

51 lines
1.6 KiB
C
Raw Normal View History

LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
/*
* Copyright (c) 2023, Tim Flynn <trflynn89@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
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-15 04:01:23 +13:00
#include <LibGC/Function.h>
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
#include <LibJS/Runtime/Completion.h>
LibJS: Convert IteratorHelper to be a GeneratorObject This is required for %IteratorHelperPrototype%.return, which needs to operate on the internal slots of the base GeneratorObject. Doing so also provides us with the appropriate VM to be used in invocations to the overridden IteratorHelper::execute.
2023-07-16 15:04:59 -04:00
#include <LibJS/Runtime/GeneratorObject.h>
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
#include <LibJS/Runtime/Iterator.h>
#include <LibJS/Runtime/Object.h>
namespace JS {
LibJS: Revert Enable EXPLICIT_SYMBOL_EXPORT This reverts commit c14173f651f5a50fdb86beb4b79487454a00f3f6. We should only annotate the minimum number of symbols that external consumers actually use, so I am starting from scratch to do that
2025-07-19 10:41:08 -07:00
class IteratorHelper final : public GeneratorObject {
LibJS: Convert IteratorHelper to be a GeneratorObject This is required for %IteratorHelperPrototype%.return, which needs to operate on the internal slots of the base GeneratorObject. Doing so also provides us with the appropriate VM to be used in invocations to the overridden IteratorHelper::execute.
2023-07-16 15:04:59 -04:00
JS_OBJECT(IteratorHelper, GeneratorObject);
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-15 04:01:23 +13:00
GC_DECLARE_ALLOCATOR(IteratorHelper);
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04: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-15 04:01:23 +13:00
using Closure = GC::Function<ThrowCompletionOr<Value>(VM&, IteratorHelper&)>;
using AbruptClosure = GC::Function<ThrowCompletionOr<Value>(VM&, IteratorHelper&, Completion const&)>;
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04: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-15 04:01:23 +13:00
static ThrowCompletionOr<GC::Ref<IteratorHelper>> create(Realm&, GC::Ref<IteratorRecord>, GC::Ref<Closure>, GC::Ptr<AbruptClosure> = {});
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
LibJS: Use the IteratorStepValue AO in Iterator prototypes This is an editorial change in the Iterator Helpers proposal. See: https://github.com/tc39/proposal-iterator-helpers/commit/b4ccc31
2024-08-27 12:22:03 -04:00
IteratorRecord& underlying_iterator() { return m_underlying_iterator; }
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
IteratorRecord const& underlying_iterator() const { return m_underlying_iterator; }
size_t counter() const { return m_counter; }
void increment_counter() { ++m_counter; }
Value result(Value);
LibJS: Convert IteratorHelper to be a GeneratorObject This is required for %IteratorHelperPrototype%.return, which needs to operate on the internal slots of the base GeneratorObject. Doing so also provides us with the appropriate VM to be used in invocations to the overridden IteratorHelper::execute.
2023-07-16 15:04:59 -04:00
ThrowCompletionOr<Value> close_result(VM&, Completion);
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
private:
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-15 04:01:23 +13:00
IteratorHelper(Realm&, Object& prototype, GC::Ref<IteratorRecord>, GC::Ref<Closure>, GC::Ptr<AbruptClosure>);
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
virtual void visit_edges(Visitor&) override;
LibJS: Skip iteration result allocation in AsyncFunctionDriverWrapper - Create less GC pressure by making each `await` in async function skip iteration result object allocation. - Skip uncached `Object::get()` calls to extract `value` and `done` from the iteration result object. With this change, following function goes 30% faster on my computer: ```js (async () => { const resolved = Promise.resolve(); for (let i = 0; i < 5_000_000; i++) { await resolved; } })(); ```
2025-05-09 04:23:30 +03:00
virtual ThrowCompletionOr<IterationResult> execute(VM&, JS::Completion const& completion) override;
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04: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-15 04:01:23 +13:00
GC::Ref<IteratorRecord> m_underlying_iterator; // [[UnderlyingIterator]]
GC::Ref<Closure> m_closure;
GC::Ptr<AbruptClosure> m_abrupt_closure;
LibJS: Implement Iterator.prototype.map This uses a new Iterator type called IteratorHelper. This does not implement IteratorHelper.prototype.return as that relies on generator objects (i.e. the internal slots of JS::GeneratorObject), which are not hooked up here.
2023-06-25 09:39:33 -04:00
size_t m_counter { 0 };
bool m_done { false };
};
}
Reference in a new issue Copy permalink