Le week-end où Visual Studio 2026 a détesté notre code

Le multiplateforme est une promesse qu'on ne peut faire qu'une fois le build vert sur chaque plateforme. Voici le week-end où RakuAI l'a rendue vraie sur Windows - et le guide des six erreurs qui frapperont aussi votre base de code C++.

Il y a une vieille blague selon laquelle la différence entre un ingénieur senior et un ingénieur junior est que l’ingénieur senior sait que ça va être un combat avec le compilateur avant même de commencer. Ce week-end a été un combat avec le compilateur. Le compilateur était Microsoft Visual C++ tel qu’il est livré dans Visual Studio 2026 Insiders. La base de code était Raku. Le combat s’est étalé sur les deux jours et quelques passages tardifs de la semaine de travail. La base de code a gagné, mais de justesse.

Je veux consigner celui-ci parce que le journal public d’ingénierie devrait inclure les jours où les choses n’ont pas fonctionné, et parce que la façon dont les agents et moi avons traversé cela est authentiquement la partie du flux de travail sur laquelle je suis le plus curieux d’avoir l’opinion d’autres personnes.

Le contexte

Jusqu’à ce week-end, le runtime se construisait proprement sur Linux avec GCC et sur macOS avec Clang. Les deux ont été mes principaux environnements de développement de week-end. Je n’avais pas réellement essayé un build Windows MSVC depuis la première mise en route en octobre. Le runtime est censé être multiplateforme. Multiplateforme signifie Windows. Donc samedi matin, j’ai récupéré le dépôt sur une machine Windows avec Visual Studio 2026 Insiders et lancé le build.

Ça n’a pas construit. Ça n’a même pas presque construit. Le premier passage de compilation a produit plus de deux cents erreurs et un nombre comparable d’avertissements. Les erreurs se répartissaient en approximativement six catégories, chacune devenant sa propre PR.

Quelles étaient les catégories

Chacune vaut la peine d’être décrite parce que chacune est le genre de chose qui frappe n’importe quelle base de code C++ la première fois qu’elle rencontre une nouvelle version de MSVC. D’autres équipes rencontreront cela. Certaines le rencontrent peut-être déjà.

Un : des macros Windows polluant nos espaces de noms. Les en-têtes Windows font des #define sur un tas de noms génériques (min, max, DOMAIN, HULL, ERROR, OK, NEAR, FAR) qui entrent en collision avec des noms d’énumération, des noms de fonction et des spécialisations de template raisonnables. Notre API C de logging avait une valeur d’énumération appelée ERROR. Windows avait aussi défini ERROR comme une macro. Le compilateur a fait exactement ce que la spec dit qu’il fait, c’est-à-dire étendre la macro et produire du charabia. La solution est #undef ERROR avant notre en-tête, étroitement circonscrit. Pareil pour les autres.

Deux : des fichiers source marqués BOM que MSVC a refusé de compiler. Certains de nos fichiers source avaient une marque d’ordre d’octets UTF-8 en tête, que la plupart des compilateurs tolèrent, et que MSVC 2026 ne tolère pas. L’agent a fait atterrir un balayage qui a retiré les BOM de chaque fichier source C/C++ du dépôt.

Trois : des API CRT dépréciées. Un tas de fonctions C standard que la norme C considère correctes sont signalées par MSVC comme « dépréciées, utilisez la variante sécurisée ». sscanf devient sscanf_s. strncpy devient strncpy_s. L’agent a parcouru et soit remplacé les appels par les variantes sécurisées, soit les a enveloppés avec le pragma _CRT_SECURE_NO_WARNINGS approprié là où la variante sécurisée aurait changé la sémantique de façons que nous ne voulions pas.

Quatre : les macros d’export DLL. La plus grosse. Chaque symbole public dans chaque DLL doit être marqué avec __declspec(dllexport) en construisant la DLL et __declspec(dllimport) en la consommant depuis une autre DLL. Linux GCC et macOS Clang n’ont pas besoin de cela. MSVC en a besoin, et notre base de code avait beaucoup de cas où la macro manquait, était appliquée de façon incohérente, ou appliquée accidentellement à des spécialisations de template que le compilateur ne voulait pas réellement exporter. La solution était un balayage qui a normalisé la macro d’export à travers chaque en-tête d’API publique et l’a ajoutée là où elle manquait.

Cinq : RAKU_API et les DLL consolidées. Une plus bizarre. Une partie de notre configuration CMake interne injectait -DRAKU_API=__declspec(dllexport) à la compilation même pour des bibliothèques statiques qui n’auraient pas dû exporter. Des erreurs MSVC C2491 partout. La solution était un désinfecteur CMake qui annule explicitement RAKU_API pour les cibles statiques et ne le définit que pour les dynamiques.

Six : les en-têtes OpenXR et <array>. Une poignée de compilations MSVC ont échoué parce que <array> était utilisé sans être explicitement inclus. GCC et Clang tendent à l’inclure transitivement à travers d’autres en-têtes STL. MSVC ne le fait pas, et « inclure ce qu’on utilise » est la bonne réponse de toute façon. L’agent a ajouté les includes manquants.

Comment s’est déroulé le week-end

Samedi matin, c’était surtout moi reproduisant chaque classe d’erreur et écrivant les notes de diagnostic. Les agents n’ont pas de VM Windows devant eux. J’ai dû capturer la sortie du build, la nettoyer, et la renvoyer à l’agent avec une demande claire : « voici la classe d’erreur, voici un exemple canonique, voici le fichier dans lequel il vit, propose un balayage qui corrige toutes les instances de cette classe ».

Les agents ont géré les balayages proprement. La PR #408 a corrigé les conflits de macros Windows dans logging.cpp. La PR #406 a corrigé la redéfinition d’énumération MSVC. La PR #404 a ajouté le désinfecteur CMake pour les macros RAKU_API. La PR #408 (une différente dans arvr_demo_telemetry) a corrigé les erreurs d’export DLL Windows. La PR #411 a corrigé les erreurs de liaison DLL MSVC 2026 et les avertissements de dépréciation. La PR #413 a retiré les BOM et remplacé les API dépréciées. La PR #415 a corrigé les erreurs C2491 en ajoutant RAKU_RUNTIME_EXPORTS aux bibliothèques statiques. La PR #416 a corrigé le build CMake avec une récupération OpenXR uniquement en en-têtes et ajouté des sources runtime manquantes. La PR #401 a corrigé les macros d’export DLL Windows et retiré un contournement MSVC devenu obsolète.

Douze PR en deux jours, à peu près. Chacune d’elles est documentée sous #404–#416 dans le dépôt runtime.

Samedi après-midi a été la période la plus longue. La normalisation d’export DLL nécessitait de lire chaque en-tête d’API publique du moteur et de décider quels symboles faisaient authentiquement partie de la surface publique. Certains se sont avérés ne pas en faire partie. Quelques-uns ont été rétrogradés en interne dans le cadre de ce travail, ce qui était un net positif même si cela a élargi la portée.

Dimanche a été consacré à un flux de travail CI Windows MSVC avec intégration vcpkg et OpenXR SDK pour que cela ne se reproduise plus jamais silencieusement. Maintenant chaque push déclenche un build MSVC. Le build ne peut pas régresser sans que quelqu’un ne le voie en CI.

La fin du dimanche a été la célébration. Au moment où l’ordinateur portable s’est fermé pour la nuit, le build est passé au vert sur Windows. Premier build x64 réussi de l’histoire du runtime. Le message de commit dit exactement cela : build: first successful x64 build with OpenXR handle fixes. Le hash du commit est f35f78bd et c’est l’un de mes commits préférés du projet à ce jour.

Ce qui a fonctionné, ce que je ferais différemment

Quelques notes honnêtes.

Mettre en route une nouvelle plateforme tard coûte cher. J’aurais dû lancer un build MSVC il y a quelques week-ends quand la base de code était plus petite. Les erreurs à cette échelle auraient été vingt, pas deux cents. Le coût de corriger vingt erreurs est significativement plus petit que le coût de corriger deux cents. La leçon est de ne jamais laisser une plateforme cible sans build pendant plus de quelques week-ends.

Les balayages pilotés par agents sont la bonne réponse quand la correction est mécanique. Le balayage d’export DLL, le retrait des BOM, le remplacement des CRT dépréciées : tout cela était exactement le genre de travail que l’agent fait plus vite et plus systématiquement qu’un humain. J’ai cadré chacun comme « trouve toutes les instances du schéma X, applique la transformation Y, laisse tout le reste tranquille », et l’agent a fait exactement cela.

Les balayages pilotés par agents sont la mauvaise réponse quand la correction nécessite du jugement. Le problème de la macro RAKU_API nécessitait de décider quelles cibles CMake voulaient réellement l’export et lesquelles non. Ce n’était pas un balayage. C’était une revue attentive, cible par cible. J’ai fait celle-là à la main avec l’agent agissant comme une seconde paire d’yeux sur chaque décision, pas comme l’exécutant.

Un modèle différent a attrapé un bug qu’un autre modèle avait écrit. Pendant le balayage de remplacement des CRT dépréciées, un des agents a remplacé sprintf par sprintf_s à un endroit où la sémantique de taille de tampon était subtilement différente de ce qu’attendait le site d’appel. La PR a atterri. Un passage de revue par un modèle différent a attrapé l’incohérence avant qu’elle ne soit livrée. Le flux de travail de revue multi-fournisseurs a gagné sa place ce week-end, spécifiquement.

Ce que les partenaires et bâtisseurs retiennent de ceci

Si vous êtes un partenaire qui réfléchit à savoir si ce moteur se déploie sur Windows, la réponse au dimanche soir est oui. Le build MSVC est vert. La CI le garde vert à l’avenir.

Si vous êtes un développeur qui travaille sur votre propre base de code C++ multiplateforme et que vous êtes sur le point d’essayer Visual Studio 2026 Insiders pour la première fois, les six catégories ci-dessus sont ce qui va vous frapper. Vous pouvez prévenir la plupart d’entre elles. Maintenant vous savez.

Si vous êtes une personne de l’équipe MSVC qui lit ceci, l’équipe a fait du bon travail sur 2026 Insiders. Les avertissements sont authentiquement utiles et le nouvel outillage est meilleur que 2022. Les casses de compatibilité sont là pour de bonnes raisons dans l’ensemble. Je déposerais bien quelques rapports de bugs si j’avais plus de temps. Ils arrivent.

Dimanche soir, le moteur se construit proprement sur trois plateformes. C’est la bonne chose avec laquelle entamer le lundi.