Das Wochenende, an dem Visual Studio 2026 unseren Code hasste

Plattformübergreifend ist ein Versprechen, das man erst geben darf, wenn der Build auf jeder Plattform grün ist. Das ist das Wochenende, an dem RakuAI es auf Windows wahr gemacht hat — und der Spielplan für die sechs Fehler, die auch Ihre C++-Codebasis treffen werden.

Es gibt einen alten Witz, dass der Unterschied zwischen einem Senior-Engineer und einem Junior-Engineer ist, dass der Senior-Engineer weiß, dass es ein Kampf mit dem Compiler werden wird, bevor er anfängt. Dieses Wochenende war ein Kampf mit dem Compiler. Der Compiler war Microsoft Visual C++, wie er in Visual Studio 2026 Insiders ausgeliefert wird. Die Codebasis war Raku. Der Kampf zog sich über beide Tage und ein paar späte Läufe aus der Arbeitswoche hin. Die Codebasis gewann, aber nur knapp.

Ich möchte das hier festhalten, weil das öffentliche Engineering-Log die Tage enthalten sollte, an denen Dinge nicht funktioniert haben, und weil die Art, wie die Agenten und ich uns hier durchgearbeitet haben, wirklich der Teil des Workflows ist, über den ich am neugierigsten auf die Meinungen anderer Leute bin.

Der Ausgangspunkt

Bis zu diesem Wochenende baute die Runtime sauber unter Linux mit GCC und unter macOS mit Clang. Beide waren meine hauptsächlichen Wochenend-Entwicklungsumgebungen. Ich hatte seit dem frühen Bring-up im Oktober keinen Windows-MSVC-Build tatsächlich versucht. Die Runtime soll plattformübergreifend sein. Plattformübergreifend bedeutet Windows. Also habe ich Samstagmorgen das Repo auf einer Windows-Maschine mit Visual Studio 2026 Insiders ausgecheckt und den Build gestartet.

Er baute nicht. Er baute nicht mal annähernd. Der erste Kompilierdurchgang produzierte mehr als zweihundert Fehler und eine vergleichbare Anzahl Warnungen. Die Fehler fielen in grob sechs Kategorien, von denen jede ihr eigener PR wurde.

Was die Kategorien waren

Jede ist es wert, beschrieben zu werden, weil jede die Art von Sache ist, die jede C++-Codebasis trifft, wenn sie zum ersten Mal auf eine neue MSVC-Version trifft. Andere Teams werden das treffen. Manche treffen es vielleicht schon.

Eins: Windows-Makros verunreinigen unsere Namensräume. Windows-Header #definen einen Haufen generischer Namen (min, max, DOMAIN, HULL, ERROR, OK, NEAR, FAR), die mit vernünftigen Enum-Namen, Funktionsnamen und Template-Spezialisierungen kollidieren. Unsere Logging-C-API hatte einen Enum-Wert namens ERROR. Windows hatte ebenfalls ERROR als Makro definiert. Der Compiler tat genau das, was die Spec sagt, dass er tut, nämlich das Makro zu expandieren und Kauderwelsch zu produzieren. Die Lösung ist #undef ERROR vor unserem Header, eng begrenzt. Dasselbe für die anderen.

Zwei: BOM-markierte Quelldateien, die MSVC nicht kompilieren wollte. Manche unserer Quelldateien hatten ein UTF-8-Byte-Order-Mark am Anfang, das die meisten Compiler tolerieren, MSVC 2026 aber nicht. Der Agent landete einen Sweep, der BOMs aus jeder C-/C++-Quelldatei im Repo entfernte.

Drei: Veraltete CRT-APIs. Ein Haufen Standard-C-Funktionen, die der C-Standard für in Ordnung hält, werden von MSVC als „veraltet, verwende die sichere Variante” markiert. sscanf wird zu sscanf_s. strncpy wird zu strncpy_s. Der Agent ging durch und ersetzte entweder die Aufrufe durch die sicheren Varianten oder umschloss sie mit dem passenden _CRT_SECURE_NO_WARNINGS-Pragma dort, wo die sichere Variante die Semantik auf eine Weise geändert hätte, die wir nicht wollten.

Vier: DLL-Export-Makros. Der größte. Jedes öffentliche Symbol in jeder DLL muss beim Bauen der DLL mit __declspec(dllexport) und beim Konsumieren aus einer anderen DLL mit __declspec(dllimport) markiert werden. Linux GCC und macOS Clang brauchen das nicht. MSVC schon, und unsere Codebasis hatte viele Stellen, an denen das Makro fehlte, inkonsistent angewendet wurde oder versehentlich auf Template-Spezialisierungen angewendet wurde, die der Compiler eigentlich gar nicht exportieren wollte. Die Lösung war ein Sweep, der das Export-Makro über jeden öffentlichen API-Header normalisierte und es dort hinzufügte, wo es fehlte.

Fünf: RAKU_API und die konsolidierten DLLs. Ein seltsamerer Fall. Ein Teil unseres internen CMake-Setups injizierte beim Kompilieren -DRAKU_API=__declspec(dllexport) selbst für statische Bibliotheken, die eigentlich nichts exportieren sollten. MSVC-C2491-Fehler überall. Die Lösung war ein CMake-Sanitizer, der RAKU_API für statische Targets explizit undefiniert und es nur für dynamische setzt.

Sechs: OpenXR-Header und <array>. Eine Handvoll MSVC-Kompilierungen scheiterten, weil <array> verwendet wurde, ohne explizit inkludiert zu sein. GCC und Clang tendieren dazu, es transitiv über andere STL-Header zu inkludieren. MSVC nicht, und „include what you use” ist ohnehin die richtige Antwort. Der Agent fügte die fehlenden Includes hinzu.

Wie das Wochenende ablief

Samstagmorgen bestand größtenteils darin, dass ich jede Fehlerklasse reproduzierte und die Diagnosenotizen schrieb. Die Agenten haben keine Windows-VM vor sich. Ich musste die Build-Ausgabe erfassen, bereinigen und dem Agenten mit einer klaren Bitte zurückspielen: „hier ist die Fehlerklasse, hier ist ein kanonisches Beispiel, hier ist die Datei, in der es liegt, schlage einen Sweep vor, der alle Instanzen dieser Klasse behebt.”

Die Agenten erledigten die Sweeps sauber. PR #408 behob Windows-Makro-Konflikte in logging.cpp. PR #406 behob die MSVC-Enum-Neudefinition. PR #404 fügte den CMake-Sanitizer für RAKU_API-Makros hinzu. PR #408 (ein anderer, in arvr_demo_telemetry) behob Windows-DLL-Export-Fehler. PR #411 behob MSVC-2026-DLL-Linkage-Fehler und Deprecation-Warnungen. PR #413 entfernte BOMs und ersetzte veraltete APIs. PR #415 behob C2491-Fehler, indem RAKU_RUNTIME_EXPORTS zu statischen Bibliotheken hinzugefügt wurde. PR #416 behob den CMake-Build mit einem Header-only-OpenXR-Fetch und fügte fehlende Runtime-Quellen hinzu. PR #401 behob Windows-DLL-Export-Makros und entfernte einen jetzt obsoleten MSVC-Workaround.

Zwölf PRs in zwei Tagen, grob gesagt. Jeder davon ist unter #404–#416 im Runtime-Repo dokumentiert.

Samstagnachmittag war der längste Abschnitt. Die DLL-Export-Normalisierung erforderte, jeden öffentlichen API-Header in der Engine zu lesen und zu entscheiden, welche Symbole tatsächlich Teil der öffentlichen Oberfläche waren. Manche davon stellten sich als nicht dazugehörig heraus. Ein paar wurden im Zuge dieser Arbeit zu intern degradiert, was ein Nettogewinn war, auch wenn es den Umfang vergrößerte.

Der Sonntag ging in einen Windows-MSVC-CI-Workflow mit vcpkg- und OpenXR-SDK-Integration, damit das nie wieder still passiert. Jetzt löst jeder Push einen MSVC-Build aus. Der Build kann nicht regressieren, ohne dass es jemand in der CI sieht.

Das Ende des Sonntags war die Feier. Als der Laptop für die Nacht zuklappte, war der Build auf Windows grün. Erster erfolgreicher x64-Build in der Geschichte der Runtime. Die Commit-Nachricht sagt genau das: build: first successful x64 build with OpenXR handle fixes. Der Commit-Hash ist f35f78bd, und es ist einer meiner Lieblings-Commits im Projekt bis heute.

Was funktioniert hat, was ich anders machen würde

Ein paar ehrliche Anmerkungen.

Eine neue Plattform spät ans Laufen zu bringen ist teuer. Ich hätte vor ein paar Wochenenden einen MSVC-Build fahren sollen, als die Codebasis kleiner war. Die Fehler wären auf dieser Größenordnung zwanzig gewesen, nicht zweihundert. Die Kosten, zwanzig Fehler zu beheben, sind spürbar kleiner als die Kosten, zweihundert zu beheben. Die Lehre ist, eine Zielplattform nie länger als ein paar Wochenenden ungebaut zu lassen.

Agentengetriebene Sweeps sind die richtige Antwort, wenn die Lösung mechanisch ist. Der DLL-Export-Sweep, das BOM-Entfernen, der veraltete-CRT-Ersatz: All das war genau die Art von Arbeit, die der Agent schneller und konsistenter macht als ein Mensch. Ich habe jeden davon als „finde alle Instanzen von Muster X, wende Transformation Y an, lass alles andere in Ruhe” formuliert, und der Agent hat genau das getan.

Agentengetriebene Sweeps sind die falsche Antwort, wenn die Lösung Urteilsvermögen erfordert. Das RAKU_API-Makro-Problem erforderte zu entscheiden, welche CMake-Targets tatsächlich den Export wollten und welche nicht. Das war kein Sweep. Das war ein sorgfältiges, target-für-target-Review. Das habe ich von Hand gemacht, mit dem Agenten als zweitem Augenpaar auf jede Entscheidung, nicht als Ausführendem.

Ein anderes Modell fing einen Fehler ab, den ein anderes Modell geschrieben hatte. Während des veraltete-CRT-Ersatz-Sweeps ersetzte einer der Agenten sprintf durch sprintf_s an einer Stelle, an der die Puffergrößen-Semantik subtil anders war, als es die Aufrufstelle erwartete. Der PR landete. Ein Review-Durchgang durch ein anderes Modell fing die Diskrepanz ab, bevor sie auslieferte. Der Multi-Vendor-Review-Workflow hat sich dieses Wochenende genau dafür bezahlt gemacht.

Was Partner und Builder daraus mitnehmen

Wenn Sie ein Partner sind, der überlegt, ob diese Engine auf Windows ausliefert: Die Antwort, Stand Sonntagabend, ist ja. Der MSVC-Build ist grün. Die CI hält ihn fortan grün.

Wenn Sie Entwickler sind, die an Ihrer eigenen plattformübergreifenden C++-Codebasis arbeiten, und Sie kurz davor stehen, zum ersten Mal Visual Studio 2026 Insiders auszuprobieren, sind die sechs Kategorien oben das, was Sie treffen wird. Sie können die meisten davon vorwegnehmen. Jetzt wissen Sie es.

Wenn Sie eine Person aus dem MSVC-Team sind und das hier lesen: Das Team hat gute Arbeit an 2026 Insiders geleistet. Die Warnungen sind tatsächlich nützlich, und die neue Tooling ist besser als 2022. Die Kompatibilitätsbrüche sind meist aus guten Gründen da. Ich würde ein paar Bug-Reports einreichen, wenn ich mehr Zeit hätte. Sie kommen.

Sonntagnacht baut die Engine sauber auf drei Plattformen. Das ist das Richtige, um damit in den Montag zu starten.