Abandon de l’adoption de Swift – fin de l’issue sur le support de Swift 6.0 dans le navigateur Ladybird

• Le projet de navigateur Ladybird a dressé la liste des problèmes rencontrés lors du passage du support de Swift 6.0 du stade expérimental à un statut officiel, mais a ensuite décidé de ne plus poursuivre l’adoption de Swift
• Les principaux obstacles concernaient l’interopérabilité (Interop) entre Swift et C++ : incompatibilités d’ABI, dépendances circulaires entre en-têtes, impossibilité de renvoyer certains types, etc. Plusieurs points ont été corrigés après Swift 6.0.0
• Dans le système de build CMake, des problèmes ont également été signalés dans l’environnement Swift + Ninja, notamment des incohérences de cible de déploiement, des erreurs de traitement de install_name et des options de compilation incompatibles
• Dans le code de Ladybird lui-même, de nombreuses instabilités de build ont été constatées, notamment autour de la configuration des modulemap des modules AK et LibGfx, des plantages du frontend Swift et des conflits d’espace de noms sur les types
• En raison de l’accumulation de ces contraintes techniques, l’intégration de Swift a été abandonnée, ce qui a conduit à la décision de conserver un développement centré sur C++

---

Problèmes liés à Swift

• De nombreux bugs au niveau du langage et de l’ABI devaient être résolus pour faire sortir le support de Swift 6.0 de la phase expérimentale
  • Échec d’assertion lors d’un build open source de Swift en raison d’un décalage de version LLVM
  • Problème d’incompatibilité d’ABI entre le compilateur et le bridging header lors du retour de Optional<CxxValueType>
  • Sur Ubuntu 22.04, inclusion de l’en-tête <execution> provoquant une dépendance circulaire de module dans libstdc++
  • Problèmes de compatibilité C++23, notamment impossibilité de renvoyer swift::Optional<swift::String> et échec du chargement de l’en-tête <chrono>
• Certains problèmes ont été corrigés dans des versions publiées après Swift 6.0.0, mais d’autres ne l’ont été que sur la branche main, sans être intégrés à une version stable
• Plusieurs points proposaient des « workarounds (méthodes de contournement pour le build) », sans que cela constitue une solution complète

Problèmes liés à CMake

• Avec la combinaison Swift et Ninja build, CMAKE_OSX_DEPLOYMENT_TARGET n’était pas appliqué, ce qui générait de nombreux avertissements
  • Il fallait définir manuellement CMAKE_Swift_COMPILER_TARGET
• Quand la politique CMP0157 est activée, la configuration du répertoire install_name est ignorée, ce qui impose une correction manuelle
  • Le correctif correspondant doit être backporté dans CMake 3.29 et 3.30
• Des options de lien que le compilateur Swift ne comprend pas peuvent être transmises par des dépendances externes

Problèmes internes au projet Ladybird

• Lors de la configuration des clang module map des modules AK et LibGfx, des conflits avec les en-têtes système se produisent
  • L’inclusion de <math.h> entraîne un échec du build à cause d’une erreur de reconnaissance de module
• Le frontend Swift plante sur des builds debug pendant les tests des conteneurs AK
  • Le problème ne peut être contourné qu’en buildant en mode release
• Un conflit d’espace de noms autour du type String provoque un arrêt anormal du frontend Swift
  • Il faut l’indiquer explicitement comme AK.String ou Swift.String
• Lors de l’utilisation du module Swift Testing, on observe des plantages du frontend du compilateur, ainsi qu’un problème de non-reconnaissance de CxxSequenceType pour AK::StringView

Éléments d’amélioration supplémentaires

• Quand une fonction C++ renvoie Optional<CxxType> vers Swift, l’application plante
  • Une solution temporaire consiste à renvoyer un tableau de taille 0 ou 1
• SourceKit-LSP et vscode-swift exigent un compile_commands.json à la racine
  • Le problème peut être résolu par la création d’un lien symbolique
• Sous Linux, il est contraignant de devoir ajouter manuellement le chemin <swift/bridging>

Questions non résolues

• On ne sait pas clairement comment, en Swift, transmettre sans copie un type view C++ ou un byte slice
• Swift ne reconnaît pas les types maison comme AK::Optional ou AK::HashMap comme équivalents aux types std::
• La manière d’intégrer le garbage collector de Swift avec la gestion mémoire de Ladybird reste également indéterminée

---

Cette issue était un document consignant de manière structurée les obstacles techniques à l’intégration de Swift 6.0, mais après l’abandon de l’adoption de Swift par l’équipe Ladybird, l’issue « Swift 6.0 Blockers » a été clôturée.