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

70 lines
2.3 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 13:39:33 +00:00
/*
* Copyright (c) 2023, Tim Flynn <trflynn89@serenityos.org>
*
* 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 10:54:48 +00: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 13:39:33 +00: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-14 15:01:23 +00: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 08:45:05 +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
ThrowCompletionOr<GC::Ref<IteratorHelper>> IteratorHelper::create(Realm& realm, GC::Ref<IteratorRecord> underlying_iterator, 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 13:39:33 +00:00
{
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-13 16:50:17 +00:00
return realm.create<IteratorHelper>(realm, realm.intrinsics().iterator_helper_prototype(), move(underlying_iterator), 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 13:39:33 +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
IteratorHelper::IteratorHelper(Realm& realm, Object& prototype, GC::Ref<IteratorRecord> underlying_iterator, GC::Ref<Closure> closure, GC::Ptr<AbruptClosure> abrupt_closure)
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 19:04:59 +00:00
: GeneratorObject(realm, prototype, realm.vm().running_execution_context().copy(), "Iterator Helper"sv)
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 13:39:33 +00:00
, m_underlying_iterator(move(underlying_iterator))
LibJS: Use HeapFunction for IteratorHelper
2024-08-18 02:54:48 +00: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 13:39:33 +00:00
{
}
void IteratorHelper::visit_edges(Visitor& visitor)
{
Base::visit_edges(visitor);
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 09:44:41 +00:00
visitor.visit(m_underlying_iterator);
LibJS: Use HeapFunction for IteratorHelper
2024-08-18 02:54:48 +00: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 13:39:33 +00:00
}
Value IteratorHelper::result(Value 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 19:04:59 +00:00
set_generator_state(value.is_undefined() ? GeneratorState::Completed : GeneratorState::SuspendedYield);
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 13:39:33 +00:00
return 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 19:04:59 +00:00
ThrowCompletionOr<Value> IteratorHelper::close_result(VM& vm, Completion 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 13:39:33 +00:00
{
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 19:04:59 +00:00
set_generator_state(GeneratorState::Completed);
return *TRY(iterator_close(vm, underlying_iterator(), move(completion)));
}
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 19:50:56 +00:00
ThrowCompletionOr<Value> 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 19:04:59 +00: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 19:50:56 +00:00
if (completion.is_abrupt()) {
LibJS: Use HeapFunction for IteratorHelper
2024-08-18 02:54:48 +00:00
if (m_abrupt_closure)
return m_abrupt_closure->function()(vm, *this, completion);
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 19:50:56 +00:00
return close_result(vm, completion);
}
LibJS: Use HeapFunction for IteratorHelper
2024-08-18 02:54:48 +00: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 19:04:59 +00:00
if (result_value.is_throw_completion()) {
set_generator_state(GeneratorState::Completed);
return result_value;
}
return create_iterator_result_object(vm, result(result_value.release_value()), generator_state() == GeneratorState::Completed);
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 13:39:33 +00:00
}
}
Reference in a new issue Copy permalink