Ladybird: Closing this as we are no longer pursuing Swift adoption

Hacker News · Feb 18, 2026 · Collected from RSS

Full Article

List of issues preventing moving forward on moving Swift 6.0 support out of an experimental state: Swift issues: Please backport d8352e93c1c8042d9166eab3d76d6c07ef585b6d swiftlang/llvm-project#8998 Details: Swift's version of LLVM is missing the fix for [Clang] ICE in CheckPointerToMemberOperands passing decltype of lambda llvm/llvm-project#53815. This means that any assertions build of llvm from the swift open source project cannot build our code. Snapshot builds are released with assertions on. Workaround: Build swift from source on Linux without llvm assertions, or use macOS. PR: 🍒 [Clang] [Sema] Handle placeholders in '.*' expressions (#83103) swiftlang/llvm-project#9038 Fixed in Swift 6.0.0 release Interop: Compiler and C++ Bridging header disagree on ABI of Optional<CxxValueType> swiftlang/swift#75593 Details: It is not currently possible to return a swift optional of a small C++ type back to C++. The compiler and the generated bridging header disagree on how that is supposed to be done. Workaround: Don't use Optional, use a return type that forces the C++ type to be heap allocated. Array is one alternative. Interop: Compiling with C++17 or higher on Ubuntu 22.04 fails with cyclic header dependencies in libstdc++ swiftlang/swift#75661 Details: Swift's clang module map for libstdc++ contains cycles when <execution> is included. See https://forums.swift.org/t/swift-5-9-release-on-ubuntu-22-04-fails-to-build-std-module/67659 Workaround: Edit <prefix>/lib/swift/linux/libstdcxx.h to comment out the #include <execution> line. PR: [cxx-interop] Disable c++ execution header with libstdcxx versions >= 11 swiftlang/swift#75662 (Just a workaround, not a fix) 6.0 Backport: 🍒 [cxx-interop] Disable c++ execution header with libstdcxx versions >= 11 swiftlang/swift#75971 Fixed in swiftlang/swift:main and release/6.0, but not in 6.0.0 or 6.0.1 Interop: Cannot return swift::Optional<swift::String> from C++ function swiftlang/swift#76024 Details: Returning binding types swift::Optional<T> or swift::String from a C++ function is not supported Workaround: Return std:: types? Swift cannot import libstdc++-13 chrono header in C++23 mode swiftlang/swift#76809 Details: Swift 6.0 cannot import libstdc++-13 or higher <chrono> header. Workaround: Use libc++ or a lower libstdc++ version. libstdc++-13 is default on Ubuntu 24.04 LTS. Fixed in swiftlang/swift:main as of Oct 18, 2024 [cxx-interop] SIL verifier crash in Unmanaged.passUnretained() on SWIFT_UNSAFE_REFERENCE type swiftlang/swift#80065 Details: SIL verifier crash when trying to compare unsafe reference types by pointer Workaround: Disable SIL verification (!! yikes) Fixed in [cxx-interop] Relax a SILVerifier assertion for immortal reference types swiftlang/swift#81614 [cxx-interop] Bitfield setter/getter for SWIFT_UNSAFE_REFERENCE crashes frontend swiftlang/swift#80182 Details: SWIFT_UNSAFE_REFERENCE types with getters/setters for bitfields crash the frontend Workaround: ... don't use SWIFT_UNSAFE_REFERENCE? unsure. Need guidance Fixed in [cxx-interop] Do not create mutating properties for classes swiftlang/swift#80197 CxxInterop: Swift does not synthesize CxxConvertibleToContainer iterator operator== in some cases swiftlang/swift#77607 Details: Vector<u32, 2> is not recognized as CxxConvertibleToContainer Workaround: Treat it as a sequence instead, and any transfer to a swift type requires manual copying of elements Enabling cxx interop on Arch with GCC 15 causes lots of errors swiftlang/swift#81774 Details: Swift fails to import clang modules with #include <math.h> with libstdc++-15 installed. Workaround: None (!!) CMake issues: https://gitlab.kitware.com/cmake/cmake/-/issues/26174 Details: Swift + Ninja doesn't respect CMAKE_OSX_DEPLOYMENT_TARGET. This results in a mismatched LC_BUILD_VERSION on swift and c++ object files, spamming the console with warnings. Workaround: # FIXME: https://gitlab.kitware.com/cmake/cmake/-/issues/26174 if (APPLE) set(CMAKE_Swift_COMPILER_TARGET "${CMAKE_SYSTEM_PROCESSOR}-apple-macosx${CMAKE_OSX_DEPLOYMENT_TARGET}") endif() https://gitlab.kitware.com/cmake/cmake/-/issues/26175 Details: With CMP0157 enabled, swiftc does not set install_name directory to "@rpath" per CMAKE_INSTALL_NAME_DIR Workaround: # FIXME: https://gitlab.kitware.com/cmake/cmake/-/issues/26175 if (APPLE) add_custom_command(TARGET LibGfx POST_BUILD COMMAND install_name_tool -id @rpath/liblagom-gfx.0.dylib "$<TARGET_FILE:LibGfx>" ) endif() PR: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9692. Merged Aug 2, 2024 to be backported to CMake 3.29, 3.30. https://gitlab.kitware.com/cmake/cmake/-/issues/26195 Details: Imported targets from dependencies can have INTERFACE_COMPILE_OPTIONS or INTERFACE_LINK_OPTIONS that swiftc doesn't understand. Workaround: Swizzle the flags just after import, for every single imported library. Ladybird issues: AK+LibGfx: Explicitly spell out headers in the clang module map #965 Details: Creating a modulemap for larger libraries can cause issues with libc headers. For example, creating an umbrella directory entry for LibGfx causes issues with <math.h>, which is clearly included in every file that is complaining about it. Needs more module.modulemap massaging to get the clang frontend/swiftc to properly associate system headers with system modules and not our own modules Workaround: ¯\_(ツ)_/¯ Resolution: Generate module maps for each library Swift: Importing AK and querying type properties crashes swift-frontend in Debug build #1101 Details: Building the CxxSequence protocol conformance test for AK containers crashes the swift frontend process in debug mode Workaround: Build in release mode lmao Upstream bug: Not yet reduced Swift: Using un-namespaced 'String' type after importing AK crashes swift frontend #1102 Details: A function that takes an unnamespaced String argument will crash the swift frontend if AK is imported Workaround: Qualify all references to String as AK.String or Swift.String Upstream bug: [cxxinterop] UNREACHABLE in AstMangler when mangling C++ type imported via global using declaration swiftlang/swift#82108 Swift: Building AK swift test with Testing module crashes compiler frontend #1201 Details: Using swift-testing to test AK container conformance to swift interop protocols crashes the frontend Workaround: Keep custom test runner code Upstream bug: Not yet reduced Swift: AK::StringView is no longer a CxxSequenceType on swift/main #2168 Details: AK::StringView fails to conform to CxxSequenceType on swift/main Workaround: Reach into the bytesUnsafe() in order to iterate over the bytes of the view as a sequence Upstream bug: Not yet reduced Nice-to-have: Interop: Application crash when returning Optional<CxxType> swiftlang/swift#79767 Details: Returning MyCxx.CxxType? from a swift function that is called from C++ crashes on call. Workaround: Return as [MyCxx.CxxType] instead, with a 0 or 1-sized array Root-level compile_commands.json required for simple CMake projects swiftlang/vscode-swift#1449 Details: Top-level compile_commands.json is required for SourceKit-LSP and vscode-swift to grok the project Workaround: Create a symlink ln -s Build/release/compile_commands.json compile_commands.json Automatically include path to <swift/bridging> in SDK installs swiftlang/swift#80142 Details: An extra include path is required to include <swift/bridging> on Linux Workaround: Grab the path from swiftc -print-target-info Open questions: Unclear how to pass view types or byte slices to swift without creating a copy. We will want to be passing untrusted Strings, or c++-owned Spans of bytes to swift for it to crunch on and return some structured data. It's not clear how to inform swift about this without copying the data (at least) once. I was not able to massage swift into interpreting our String and StringView types as 'CxxConvertibleToContainer' or 'CxxRandomAccessContainer' types. Likely because they are actually immutable? Unclear how to convince Swift that our types are just as good as std:: ones. AK::Optional AK::HashTable/HashMap AK::Time more? How to integrate with our garbage collector? https://forums.swift.org/t/ladybird-browser-and-swift-garbage-collection/76084