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.global_object().set_prototype());
}

Set::Set(Object& prototype)
    : Object(prototype)
    , m_values(*prototype.global_object().map_prototype())
{
}

void Set::visit_edges(Cell::Visitor& visitor)
{
    Base::visit_edges(visitor);
    static_cast<Object&>(m_values).visit_edges(visitor);
}

}
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+LibWeb: Replace GlobalObject with Realm in Heap::allocate<T>() This is a continuation of the previous three commits. Now that create() receives the allocating realm, we can simply forward that to allocate(), which accounts for the majority of these changes. Additionally, we can get rid of the realm_from_global_object() in one place, with one more remaining in VM::throw_completion(). 2022-08-16 00:20:50 +01:00			`return realm.heap().allocate<Set>(realm, *realm.global_object().set_prototype());`
LibJS: Add the Set built-in object 2021-06-09 00:08:47 +03:00			`}`

			`Set::Set(Object& prototype)`
			`: Object(prototype)`
LibJS: Implement Sets using Maps This implements ordered sets using Maps with a sentinel value, and includes some extra set tests. Fixes #11004. Co-Authored-By: davidot <davidot@serenityos.org> 2022-02-09 18:34:16 +03:30			`, m_values(*prototype.global_object().map_prototype())`
LibJS: Add the Set built-in object 2021-06-09 00:08:47 +03:00			`{`
			`}`

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: Implement Sets using Maps This implements ordered sets using Maps with a sentinel value, and includes some extra set tests. Fixes #11004. Co-Authored-By: davidot <davidot@serenityos.org> 2022-02-09 18:34:16 +03:30			`static_cast<Object&>(m_values).visit_edges(visitor);`
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			`}`