Swift 6.0 Blockers

[ADKaster]

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

Swift issues:

• [ ] https://github.com/swiftlang/llvm-project/issues/8998

  Details: Swift's version of LLVM is missing the fix for https://github.com/llvm/llvm-project/issues/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: https://github.com/swiftlang/llvm-project/pull/9038

• [ ] https://github.com/swiftlang/swift/issues/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.

• [x] https://github.com/swiftlang/swift/issues/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: https://github.com/swiftlang/swift/pull/75662 (Just a workaround, not a fix) 6.0 Backport: https://github.com/swiftlang/swift/pull/75971

• [ ] https://github.com/swiftlang/swift/issues/76024

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

  Workaround: Return std:: types?

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: https://github.com/LadybirdBrowser/ladybird/blob/113b4da1df7ec65a8686af4e7b91e2f8d4114e2c/Meta/CMake/Swift/swift-settings.cmake#L21-L24

• [ ] 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: https://github.com/LadybirdBrowser/ladybird/blob/113b4da1df7ec65a8686af4e7b91e2f8d4114e2c/Userland/Libraries/LibGfx/CMakeLists.txt#L123-L128

  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:

• [x] https://github.com/LadybirdBrowser/ladybird/pull/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

• [ ] https://github.com/LadybirdBrowser/ladybird/issues/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

• [ ] https://github.com/LadybirdBrowser/ladybird/issues/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

• [ ] https://github.com/LadybirdBrowser/ladybird/issues/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

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?

[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

[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. https://github.com/swiftlang/swift/pull/75971