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/MapIterator.cpp

32 lines
830 B
C++
Raw Normal View History

LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 20:58:03 +00:00
/*
* Copyright (c) 2021, Idan Horowitz <idan.horowitz@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibJS/Runtime/GlobalObject.h>
#include <LibJS/Runtime/MapIterator.h>
namespace JS {
LibJS: Convert MapIterator::create() to NonnullGCPtr
2022-12-13 20:49:50 +00:00
NonnullGCPtr<MapIterator> MapIterator::create(Realm& realm, Map& map, Object::PropertyKind iteration_kind)
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 20:58:03 +00:00
{
LibJS: Make Heap::allocate<T>() infallible Stop worrying about tiny OOMs. Work towards #20449. While going through these, I also changed the function signature in many places where returning ThrowCompletionOr<T> is no longer necessary.
2023-08-13 11:05:26 +00:00
return realm.heap().allocate<MapIterator>(realm, map, iteration_kind, realm.intrinsics().map_iterator_prototype());
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 20:58:03 +00:00
}
LibJS: Consistently make prototype the last argument in Object ctors This is so that we can reliably allocate them in a template function, e.g. in ordinary_create_from_constructor(): global_object.heap().allocate<T>( global_object, forward<Args>(args)..., *prototype); The majority of objects already take the prototype as the last argument, so I updated the ones that didn't.
2021-06-19 22:21:08 +00:00
MapIterator::MapIterator(Map& map, Object::PropertyKind iteration_kind, Object& prototype)
LibJS: Remove Object(Object& prototype) footgun This constructor was easily confused with a copy constructor, and it was possible to accidentally copy-construct Objects in at least one way that we dicovered (via generic ThrowCompletionOr construction). This patch adds a mandatory ConstructWithPrototypeTag parameter to the constructor to disambiguate it.
2022-12-14 11:17:58 +00:00
: Object(ConstructWithPrototypeTag::Tag, prototype)
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 20:58:03 +00:00
, m_map(map)
, m_iteration_kind(iteration_kind)
LibJS: Make Map iterators independent of the underlying hashmap This implements ordered maps as a pair of an RBTree for key order, and an underlying unordered hash map for storage. Fixes (part of) #11004.
2022-02-09 13:04:52 +00:00
, m_iterator(static_cast<Map const&>(map).begin())
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 20:58:03 +00:00
{
}
void MapIterator::visit_edges(Cell::Visitor& visitor)
{
Base::visit_edges(visitor);
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 23:09:02 +00:00
visitor.visit(m_map);
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 20:58:03 +00:00
}
}
Reference in a new issue Copy permalink