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

34 lines
844 B
C++
Raw Permalink 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 {
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(MapIterator);
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
GC::Ref<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+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<MapIterator>(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