b84f8fb55b
Some of these are allocated upon initialization of the intrinsics, and some lazily, but in neither case the getters actually return a nullptr. This saves us a whole bunch of pointer dereferences (as NonnullGCPtr has an `operator T&()`), and also has the interesting side effect of forcing us to explicitly use the FunctionObject& overload of call(), as passing a NonnullGCPtr is ambigous - it could implicitly be turned into a Value _or_ a FunctionObject& (so we have to dereference manually).
38 lines
1.2 KiB
C++
38 lines
1.2 KiB
C++
/*
|
|
* Copyright (c) 2021, David Tuin <davidot@serenityos.org>
|
|
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
|
|
*
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
*/
|
|
|
|
#include <LibJS/Runtime/AsyncFromSyncIterator.h>
|
|
#include <LibJS/Runtime/AsyncFromSyncIteratorPrototype.h>
|
|
#include <LibJS/Runtime/GlobalObject.h>
|
|
|
|
namespace JS {
|
|
|
|
NonnullGCPtr<AsyncFromSyncIterator> AsyncFromSyncIterator::create(Realm& realm, Iterator sync_iterator_record)
|
|
{
|
|
return realm.heap().allocate<AsyncFromSyncIterator>(realm, realm, sync_iterator_record).release_allocated_value_but_fixme_should_propagate_errors();
|
|
}
|
|
|
|
AsyncFromSyncIterator::AsyncFromSyncIterator(Realm& realm, Iterator sync_iterator_record)
|
|
: Object(ConstructWithPrototypeTag::Tag, realm.intrinsics().async_from_sync_iterator_prototype())
|
|
, m_sync_iterator_record(sync_iterator_record)
|
|
{
|
|
}
|
|
|
|
ThrowCompletionOr<void> AsyncFromSyncIterator::initialize(Realm& realm)
|
|
{
|
|
MUST_OR_THROW_OOM(Base::initialize(realm));
|
|
return {};
|
|
}
|
|
|
|
void AsyncFromSyncIterator::visit_edges(Cell::Visitor& visitor)
|
|
{
|
|
Object::visit_edges(visitor);
|
|
visitor.visit(m_sync_iterator_record.iterator);
|
|
visitor.visit(m_sync_iterator_record.next_method);
|
|
}
|
|
|
|
}
|