ladybird/Libraries/LibJS/Runtime/BigIntObject.cpp

/*
 * Copyright (c) 2020-2023, Linus Groh <linusg@serenityos.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#include <LibJS/Runtime/BigIntObject.h>
#include <LibJS/Runtime/GlobalObject.h>

namespace JS {

GC_DEFINE_ALLOCATOR(BigIntObject);

GC::Ref<BigIntObject> BigIntObject::create(Realm& realm, BigInt& bigint)
{
    return realm.create<BigIntObject>(bigint, realm.intrinsics().bigint_prototype());
}

BigIntObject::BigIntObject(BigInt& bigint, Object& prototype)
    : Object(ConstructWithPrototypeTag::Tag, prototype)
    , m_bigint(bigint)
{
}

void BigIntObject::visit_edges(Cell::Visitor& visitor)
{
    Base::visit_edges(visitor);
    visitor.visit(m_bigint);
}

}
LibJS: Add BigInt 2020-06-05 21:14:10 -03:00			`/*`
LibJS: Make intrinsics getters return NonnullGCPtr 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). 2023-04-12 19:47:15 -03:00			`* Copyright (c) 2020-2023, Linus Groh <linusg@serenityos.org>`
LibJS: Add BigInt 2020-06-05 21:14:10 -03:00			`*`
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt * 2021-04-22 05:24:48 -03:00			`* SPDX-License-Identifier: BSD-2-Clause`
LibJS: Add BigInt 2020-06-05 21:14:10 -03:00			`*/`

			`#include <LibJS/Runtime/BigIntObject.h>`
			`#include <LibJS/Runtime/GlobalObject.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 12:01:23 -03:00			`GC_DEFINE_ALLOCATOR(BigIntObject);`
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 05:45:05 -03: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 12:01:23 -03:00			`GC::Ref<BigIntObject> BigIntObject::create(Realm& realm, BigInt& bigint)`
LibJS: Add BigInt 2020-06-05 21:14:10 -03: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 13:50:17 -03:00			`return realm.create<BigIntObject>(bigint, realm.intrinsics().bigint_prototype());`
LibJS: Add BigInt 2020-06-05 21:14:10 -03:00			`}`

			`BigIntObject::BigIntObject(BigInt& bigint, 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 08:17:58 -03:00			`: Object(ConstructWithPrototypeTag::Tag, prototype)`
LibJS: Add BigInt 2020-06-05 21:14:10 -03:00			`, m_bigint(bigint)`
			`{`
			`}`

LibJS: Rename Cell::visit_children() => Cell::visit_edges() The GC heap is really a graph of cells, so "children" didn't quite feel appropriate here. 2020-11-28 10:33:36 -03:00			`void BigIntObject::visit_edges(Cell::Visitor& visitor)`
LibJS: Add BigInt 2020-06-05 21:14:10 -03:00			`{`
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 09:05:12 -03:00			`Base::visit_edges(visitor);`
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr 2023-02-26 20:09:02 -03:00			`visitor.visit(m_bigint);`
LibJS: Add BigInt 2020-06-05 21:14:10 -03:00			`}`

			`}`