svanimpe
September 16, 2024, 12:42pm
1
Here's an interesting clip of Andreas Kling discussing how/why the Ladybird browser project decided to adopt Swift as a C++ successor language:
22 Likes
nhatlee
September 17, 2024, 12:14am
2
Is this their repo LadybirdBrowser/ladybird ?I saw the repo written in C++
It is, but they've decided to shift to Swift for new code:
opened 02:49PM - 02 Aug 24 UTC
task list
swift
List of issues preventing moving forward on moving Swift 6.0 support out of an e… xperimental 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?
4 Likes
To be honest, except 12 files, I didn't see any code written in Swift. And these were updated 3 months ago. Seems like the adoption slowed down a bit...
svanimpe
April 24, 2025, 3:28pm
5
I just came across this on YouTube:
5 Likes
