List of issues preventing moving forward on moving Swift 6.0 support out of an experimental state:

Swift issues:

• swiftlang/llvm-project#8998

  Details: Swift's version of LLVM is missing the fix for 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: swiftlang/llvm-project#9038

  Fixed in Swift 6.0.0 release

• 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.

• 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: swiftlang/swift#75662 (Just a workaround, not a fix)
  6.0 Backport: swiftlang/swift#75971
  Fixed in swiftlang/swift:main and release/6.0, but not in 6.0.0 or 6.0.1

• swiftlang/swift#76024

  Details: Returning binding types swift::Optional<T> or swift::String from a C++ function is not supported

  Workaround: Return std:: types?

• 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

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

  	# 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:

  ladybird/Userland/Libraries/LibGfx/CMakeLists.txt

  Lines 123 to 128 in 113b4da

  	# 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:

• #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

• #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

• #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: Not yet reduced

• #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

• #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

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?