Swift 6.0 Blockers

[ADKaster]

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

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:

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

• 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

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?

[compnerd]

I believe that the currently marked Swift issues are dealt with except for the bridging header disagreement. That might be something that can get addressed in the next cycle depending on if anyone is willing to pick up the necessary investigation.

[ADKaster]

@compnerd I could use some help minimizing #1101 and #1102 into minimized swift-specific issues. At the moment they require using the real AK library.

[compnerd]

Do they reproduce on Windows or require a macOS host?

[ADKaster]

I have reproduced both issues on Linux and macOS.

[compnerd]

Unfortunately, the only host that I currently have with a development toolchain setup is Windows.

[circl-lastname]

Unfortunately, the only host that I currently have with a development toolchain setup is Windows.

You can use WSL2 to run Ladybird during this time

[ADKaster]

I believe that the currently marked Swift issues are dealt with except for the bridging header disagreement.

Actually, the 6.x backport for the libstdcxx issue is currently only approved by Egor, not by the proper release managers. So I can't quite recommend folks test on linux with swiftly install 6.0-snapshot yet. swiftlang/swift#75971