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

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

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

[ngortheone]

Please reconsider the choice of the successor language. Swift is not really supported on Linux (and very little opensource software is written in Swift for Linux) and not even available on BSDs. This will make Ladybird browser a Windows/OSX only browser.

It will be very sad to loose new web browser to closed-source commercial OSes.

[ADKaster]

"Swift for Server" seems to work just fine locally on my Linux machine. We have every intention of working with upstreams to help it better handle the use cases we have for safety critical components for the platforms we've promised to support for the alpha release sometime in 2026.

As for downstreams like distros, we'll of course work with them as needed when we get closer to actually releasing the browser for end user testing. Again, the Alpha date is sometime in 2026, with a Beta a year after that.

Please keep this issue focused on technical challenges encountered with the integration of Swift 6.0 into our build.

[ngortheone]

Please keep this issue focused on technical challenges encountered with the integration of Swift 6.0 into our build.

@ADKaster BSDs are not "downstream distros". These are entirely separate and complete operating systems with their own kernels and userlands.

• https://www.freebsd.org/
• https://www.openbsd.org/
• https://www.netbsd.org/

Today no swift compiler exists for these 3 operating systems and I don't think there will ever be one.
I urge you to reconsider the choice of swift. Literally any other language will have better cross-platform and cross-OS support.

[AtkinsSJ]

BSDs are not "downstream distros".

You're misquoting/misunderstanding him. He said "downstreams like distros". Anywhere that packages Ladybird, whether it's a distro or a different OS like one of the BSDs or Haiku etc, is downstream of our repo.

Today no swift compiler exists for these 3 operating systems and I don't think there will ever be one.

Ladybird isn't going into early alpha until 2026, and then a proper release will be years after that. There's plenty of time for Swift support to develop on those other OSes. The Swift compiler is based on LLVM so the amount of porting required shouldn't be too huge. (Though I haven't looked into it.) Even on Linux the Swift situation is a little rough right now, but it'll improve with time.

[ADKaster]

As Sam said, I meant to refer to any package or port that distributes the application for their operating system, not to classify the BSDs as Linux Distros.

Today no swift compiler exists for these 3 operating systems and I don't think there will ever be one.

There is documentation from 2022 for building Swift on OpenBSD. https://github.com/swiftlang/swift/blob/main/docs/OpenBSD.md. The technical challenges with the latest efforts of porting Swift to FreeBSD seem llvm related. The issues with updating Swift to work on more BSD platforms are technical problems, not political ones. Unless there's BSD mailing list drama I'm not aware of. But that would still be out of scope for our project.

As you mentioned, there are no large and/or popular open source desktop applications using Swift (to my knowledge). I can't think of a better way to energize Swift porting efforts than to prove that such a thing is possible on non-macOS Unix systems.

[ngortheone]

You're misquoting/misunderstanding him. He said "downstreams like distros". Anywhere that packages Ladybird, whether it's a distro or a different OS like one of the BSDs or Haiku etc, is downstream of our repo.

Indeed I misunderstood the meaning of downstream in this context.

I do not want to discourage the optimism and I hope that Ladybird will succeed. The opensource ecosystem desperately needs "new blood" in the browser section. But lets look at the facts:

• Swift was first released in 2014 and Linux always was a second-class citizen (example - Swift's stable ABI for dynamically loaded libraries only works on OSX). 10 years is plenty of time to "grow" support for various platforms but somehow Swift didn't do it - comparing to literally any other LLVM based language. The hope that by 2026 the situation will somehow change is thin.

• Swift's C++ interop is still WIP. This means that you are inviting a whole new class of language interop bugs into the project that will be difficult to debug.

• Introduction of any second language into the project inevitably slows the progress down, creates unnecessary context switch for humans and diverges a lot of energy into rewriting existing functionality. Needless to say that most rewrites never finish.

I can't think of a better way to energize Swift porting efforts than to prove that such a thing is possible on non-macOS Unix systems.

It does seem like you are subscribing yourselves to more work than you expect:

• Improving Swift's opensource desktop ecosystem
• Improving Swift's cross-OS support
• Building a new browser

P.S. Have you looked at Herb Sutter's cppfront? (https://hsutter.github.io/cppfront/)
It is a lot less invasive way to get nice things in a C++ project

[ADKaster]

Thanks for your feedback, but like I said, this issue is for technical issues with our specific implementation. If you want to debate the merits of using Swift for an open source project, please do it in the appropriate forum.

We have done our technical diligence regarding this experiment, and suggestions otherwise are not helpful for meeting the goals of the project

[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