ladybird/Userland/Libraries/LibJS/Runtime/Set.cpp

/*
 * Copyright (c) 2021, Idan Horowitz <idan.horowitz@serenityos.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#include <LibJS/Runtime/Set.h>

namespace JS {

Set* Set::create(Realm& realm)
{
    return realm.heap().allocate<Set>(realm, *realm.intrinsics().set_prototype());
}

Set::Set(Object& prototype)
    : Object(prototype)
{
}

void Set::initialize(Realm& realm)
{
    m_values = Map::create(realm);
}

void Set::visit_edges(Cell::Visitor& visitor)
{
    Base::visit_edges(visitor);
    visitor.visit(m_values);
}

}
LibJS: Add the Set built-in object 2021-06-09 00:08:47 +03:00			`/*`
			`* Copyright (c) 2021, Idan Horowitz <idan.horowitz@serenityos.org>`
			`*`
			`* SPDX-License-Identifier: BSD-2-Clause`
			`*/`

			`#include <LibJS/Runtime/Set.h>`

			`namespace JS {`

LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there. 2022-08-16 00:20:49 +01:00			`Set* Set::create(Realm& realm)`
LibJS: Add the Set built-in object 2021-06-09 00:08:47 +03:00			`{`
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^) 2022-08-27 00:54:55 +01:00			`return realm.heap().allocate<Set>(realm, *realm.intrinsics().set_prototype());`
LibJS: Add the Set built-in object 2021-06-09 00:08:47 +03:00			`}`

			`Set::Set(Object& prototype)`
			`: Object(prototype)`
			`{`
			`}`

LibJS: Do not allocate in Set's constructor We are currently allocating in Set's constructor to create the set's underlying Map. This can cause GC to occur before the member is actually initialized, thus we will crash in Set::visit_edges trying to visit a member that does not exist. Instead, create the Map in Set::initialize, where we can allocate. Also change Map to be stored as a normal JS heap-allocated object, rather than as a stack variable. 2022-11-30 09:18:27 -05:00			`void Set::initialize(Realm& realm)`
			`{`
			`m_values = Map::create(realm);`
			`}`

LibJS: Mark heap cell values stored in Set instances This makes sure they dont get garbage collected while stored in a Set. 2021-06-09 18:01:06 +03:00			`void Set::visit_edges(Cell::Visitor& visitor)`
			`{`
LibJS+LibWeb+Spreadsheet: Upcall visit_edges() via Base typedef Let's use Base::visit_edges() when calling the base class, to prevent accidentally skipping over anyone in the inheritance chain. 2021-09-11 14:05:12 +02:00			`Base::visit_edges(visitor);`
LibJS: Do not allocate in Set's constructor We are currently allocating in Set's constructor to create the set's underlying Map. This can cause GC to occur before the member is actually initialized, thus we will crash in Set::visit_edges trying to visit a member that does not exist. Instead, create the Map in Set::initialize, where we can allocate. Also change Map to be stored as a normal JS heap-allocated object, rather than as a stack variable. 2022-11-30 09:18:27 -05:00			`visitor.visit(m_values);`
LibJS: Mark heap cell values stored in Set instances This makes sure they dont get garbage collected while stored in a Set. 2021-06-09 18:01:06 +03:00			`}`

LibJS: Add the Set built-in object 2021-06-09 00:08:47 +03:00			`}`