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

There was an error while loading. Please reload this page.

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:

ladybird/Meta/CMake/Swift/swift-settings.cmake

Lines 21 to 24

in

113b4da

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:

ladybird/Userland/Libraries/LibGfx/CMakeLists.txt

Lines 123 to 128

in

113b4da

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.

Unclear how to convince Swift that our types are just as good as std:: ones.

How to integrate with our garbage collector? https://forums.swift.org/t/ladybird-browser-and-swift-garbage-collection/76084