ladybird/Libraries/LibGC/CMakeLists.txt

set(SOURCES
    BlockAllocator.cpp
    Cell.cpp
    CellAllocator.cpp
    ConservativeVector.cpp
    ForeignCell.cpp
    Root.cpp
    RootHashMap.cpp
    RootVector.cpp
    Heap.cpp
    HeapBlock.cpp
    WeakBlock.cpp
    WeakContainer.cpp
)

ladybird_lib(LibGC gc EXPLICIT_SYMBOL_EXPORT)
target_link_libraries(LibGC PRIVATE LibCore)

if (ENABLE_SWIFT)
    generate_clang_module_map(LibGC)
    target_sources(LibGC PRIVATE
        Heap+Swift.swift
    )
    target_link_libraries(LibGC PRIVATE AK)
    add_swift_target_properties(LibGC LAGOM_LIBRARIES AK)
endif()

# TODO: Use lagom_generate_export_header and annotate entire LibGC with export macros
include(GenerateExportHeader)
generate_export_header(LibGC EXPORT_MACRO_NAME GC_API EXPORT_FILE_NAME "Export.h")
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-15 04:01:23 +13:00			`set(SOURCES`
			`BlockAllocator.cpp`
			`Cell.cpp`
			`CellAllocator.cpp`
			`ConservativeVector.cpp`
LibGC: Add a ForeignCell class for ownership of non-C++ objects This will allow us to use the GC to manage the lifetime of objects that are not C++ objects, such as Swift objects. In the future we could expand this cursed FFI to other languages as well. 2024-11-16 14:56:27 -07:00			`ForeignCell.cpp`
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-15 04:01:23 +13:00			`Root.cpp`
LibGC: Add GC::RootHashMap<...> template container This is a GC-aware wrapper around AK::HashMap. Entry values are treated as GC roots, much like the GC::RootVector we already had. We also provide GC::OrderedRootHashMap as a convenience. 2025-05-03 11:59:17 +02:00			`RootHashMap.cpp`
LibGC: Rename MarkedVector => RootVector Let's try to make it a bit more clear that this is a Vector of GC roots. 2024-12-26 14:32:52 +01:00			`RootVector.cpp`
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-15 04:01:23 +13:00			`Heap.cpp`
			`HeapBlock.cpp`
LibGC: Add GC::Weak<T> as an alternative to AK::WeakPtr<T> This is a weak pointer that integrates with the garbage collector. It has a number of differences compared to AK::WeakPtr, including: - The "control block" is allocated from a well-packed WeakBlock owned by the GC heap, not just a generic malloc allocation. - Pointers to dead cells are nulled out by the garbage collector immediately before running destructors. - It works on any GC::Cell derived type, meaning you don't have to inherit from AK::Weakable for the ability to be weakly referenced. - The Weak always points to a control block, even when "null" (it then points to a null WeakImpl), which means one less null check when chasing pointers. 2025-10-16 11:10:01 +02:00			`WeakBlock.cpp`
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-15 04:01:23 +13:00			`WeakContainer.cpp`
			`)`

CMake: Rename serenity_* helper functions/macros to ladybird_* 2025-06-30 08:11:44 -07:00			`ladybird_lib(LibGC gc EXPLICIT_SYMBOL_EXPORT)`
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-15 04:01:23 +13:00			`target_link_libraries(LibGC PRIVATE LibCore)`
LibGC: Add Swift bindings to the GC heap This includes a protocol for creating LibGC Heap allocated Swift objects. Pay no attention to the Unmanaged shenanigans, they are all behind the curtain. 2024-11-16 14:58:28 -07:00
			`if (ENABLE_SWIFT)`
			`generate_clang_module_map(LibGC)`
			`target_sources(LibGC PRIVATE`
LibGC+LibJS+LibWeb: Add workaround for Swift boolean bitfield issue This patch adds a workaround for a Swift issue where boolean bitfields with getters and setters in SWIFT_UNSAFE_REFERENCE types are improperly imported, causing an ICE. 2025-03-22 18:58:04 -06:00			`Heap+Swift.swift`
LibGC: Add Swift bindings to the GC heap This includes a protocol for creating LibGC Heap allocated Swift objects. Pay no attention to the Unmanaged shenanigans, they are all behind the curtain. 2024-11-16 14:58:28 -07:00			`)`
			`target_link_libraries(LibGC PRIVATE AK)`
LibGC+LibWeb+LibJS: Remove workaround for Swift boolean bitfield issue We're using a main snapshot everywhere, so we can yeet the workaround. 2025-04-04 07:04:10 -06:00			`add_swift_target_properties(LibGC LAGOM_LIBRARIES AK)`
LibGC: Add Swift bindings to the GC heap This includes a protocol for creating LibGC Heap allocated Swift objects. Pay no attention to the Unmanaged shenanigans, they are all behind the curtain. 2024-11-16 14:58:28 -07:00			`endif()`
LibGC: Add the minimum export macros required to link LibJS This approach still requires the WINDOWS_EXPORT_ALL_SYMBOLS target property, but it does let us run a lot more tests than before. 2025-05-29 00:04:33 -06:00
			`# TODO: Use lagom_generate_export_header and annotate entire LibGC with export macros`
			`include(GenerateExportHeader)`
			`generate_export_header(LibGC EXPORT_MACRO_NAME GC_API EXPORT_FILE_NAME "Export.h")`