Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-18 18:00:31 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Runtime/IteratorHelper.cpp

64 lines
2.1 KiB
C++
Raw Permalink 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
/*
LibJS: Replace [[UnderlyingIterator]] with [[UnderlyingIterators]] This is an editorial change in the EMCA-262 spec. See: https://github.com/tc39/ecma262/commit/c541680
2025-12-02 12:21:13 -05:00
* Copyright (c) 2023-2025, Tim Flynn <trflynn89@ladybird.org>
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
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibJS/Runtime/GlobalObject.h>
LibJS+LibWeb: Move IteratorOperations.h AOs to Iterator.h Rather than splitting the Iterator type and its AOs into two files, let's combine them into one file to match every other JS runtime object that we have.
2023-07-19 06:54:48 -04:00
#include <LibJS/Runtime/Iterator.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/IteratorHelper.h>
#include <LibJS/Runtime/Realm.h>
namespace JS {
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_DEFINE_ALLOCATOR(IteratorHelper);
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 09:45:05 +01:00
LibJS: Mark IteratorHelper::create as infallible This is just allocating an IteratorHelper. There is no way for this to throw an exception.
2025-12-02 12:32:57 -05:00
GC::Ref<IteratorHelper> IteratorHelper::create(Realm& realm, ReadonlySpan<GC::Ref<IteratorRecord>> underlying_iterators, GC::Ref<Closure> closure, GC::Ptr<AbruptClosure> 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
{
LibJS: Replace [[UnderlyingIterator]] with [[UnderlyingIterators]] This is an editorial change in the EMCA-262 spec. See: https://github.com/tc39/ecma262/commit/c541680
2025-12-02 12:21:13 -05:00
return realm.create<IteratorHelper>(realm, realm.intrinsics().iterator_helper_prototype(), underlying_iterators, closure, 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
}
LibJS: Replace [[UnderlyingIterator]] with [[UnderlyingIterators]] This is an editorial change in the EMCA-262 spec. See: https://github.com/tc39/ecma262/commit/c541680
2025-12-02 12:21:13 -05:00
IteratorHelper::IteratorHelper(Realm& realm, Object& prototype, ReadonlySpan<GC::Ref<IteratorRecord>> underlying_iterators, GC::Ref<Closure> closure, GC::Ptr<AbruptClosure> abrupt_closure)
LibJS: Allow constructing generator from function with null "prototype" Fixes 4 test262 tests and simplifies some upcoming stuff.
2025-11-17 10:23:56 +01:00
: GeneratorObject(realm, &prototype, realm.vm().running_execution_context().copy(), "Iterator Helper"sv)
LibJS: Replace [[UnderlyingIterator]] with [[UnderlyingIterators]] This is an editorial change in the EMCA-262 spec. See: https://github.com/tc39/ecma262/commit/c541680
2025-12-02 12:21:13 -05:00
, m_underlying_iterators(underlying_iterators)
LibJS: Use HeapFunction for IteratorHelper
2024-08-18 14:54:48 +12:00
, m_closure(closure)
, m_abrupt_closure(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
{
}
void IteratorHelper::visit_edges(Visitor& visitor)
{
Base::visit_edges(visitor);
LibJS: Replace [[UnderlyingIterator]] with [[UnderlyingIterators]] This is an editorial change in the EMCA-262 spec. See: https://github.com/tc39/ecma262/commit/c541680
2025-12-02 12:21:13 -05:00
visitor.visit(m_underlying_iterators);
LibJS: Use HeapFunction for IteratorHelper
2024-08-18 14:54:48 +12:00
visitor.visit(m_closure);
visitor.visit(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
}
LibJS: Directly indicate when the IteratorHelper generator is complete Our existing implementation was checking if the generator step result was `undefined` to indicate that the generator is complete. This is not sufficient for an upcoming implementation of Iterator.concat, where `undefined` is used as an incomplete iteration result. Instead, let's have the Iterator prototype return an IterationResult to explicitly indicate its completeness. As a result, the prototype also looks more like the spec now.
2025-12-02 16:53:09 -05:00
ThrowCompletionOr<IteratorHelper::IterationResult> IteratorHelper::execute(VM& vm, JS::Completion const& completion)
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
{
ScopeGuard guard { [&] { vm.pop_execution_context(); } };
LibJS: Handle abrupt closures from Iterator.prototype.flatMap This is in preparation of implementing %IteratorHelperPrototype%.return. That will invoke GeneratorResumeAbrupt, which will execute the generator with an abrupt completion. At that time, we must take care to close the current inner iterator.
2023-07-16 15:50:56 -04:00
if (completion.is_abrupt()) {
LibJS: Directly indicate when the IteratorHelper generator is complete Our existing implementation was checking if the generator step result was `undefined` to indicate that the generator is complete. This is not sufficient for an upcoming implementation of Iterator.concat, where `undefined` is used as an incomplete iteration result. Instead, let's have the Iterator prototype return an IterationResult to explicitly indicate its completeness. As a result, the prototype also looks more like the spec now.
2025-12-02 16:53:09 -05:00
auto abrupt_result = m_abrupt_closure
? TRY(m_abrupt_closure->function()(vm, completion))
: TRY(iterator_close_all(vm, underlying_iterators(), completion));
set_generator_state(GeneratorState::Completed);
return IterationResult(abrupt_result, true);
LibJS: Handle abrupt closures from Iterator.prototype.flatMap This is in preparation of implementing %IteratorHelperPrototype%.return. That will invoke GeneratorResumeAbrupt, which will execute the generator with an abrupt completion. At that time, we must take care to close the current inner iterator.
2023-07-16 15:50:56 -04:00
}
LibJS: Use HeapFunction for IteratorHelper
2024-08-18 14:54:48 +12:00
auto result_value = m_closure->function()(vm, *this);
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
if (result_value.is_throw_completion()) {
set_generator_state(GeneratorState::Completed);
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
return result_value.throw_completion();
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
}
LibJS: Directly indicate when the IteratorHelper generator is complete Our existing implementation was checking if the generator step result was `undefined` to indicate that the generator is complete. This is not sufficient for an upcoming implementation of Iterator.concat, where `undefined` is used as an incomplete iteration result. Instead, let's have the Iterator prototype return an IterationResult to explicitly indicate its completeness. As a result, the prototype also looks more like the spec now.
2025-12-02 16:53:09 -05:00
auto result = result_value.release_value();
set_generator_state(result.done ? GeneratorState::Completed : GeneratorState::SuspendedYield);
return result;
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
}
}
Reference in a new issue Copy permalink