Ladybird browser

svanimpe · September 16, 2024, 12:42pm

Here's an interesting clip of Andreas Kling discussing how/why the Ladybird browser project decided to adopt Swift as a C++ successor language:

nhatlee · September 17, 2024, 12:14am

Is this their repo LadybirdBrowser/ladybird?
I saw the repo written in C++

Finagolfin · September 17, 2024, 5:43am

It is, but they've decided to shift to Swift for new code:

github.com/LadybirdBrowser/ladybird

Swift 6.0 Blockers

opened 02:49PM - 02 Aug 24 UTC

ADKaster

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?