El fin de semana en que Visual Studio 2026 odió nuestro código

Multiplataforma es una promesa que solo puedes hacer una vez que el build está en verde en cada plataforma. Este es el fin de semana en que RakuAI la hizo realidad en Windows, y el manual de jugadas para los seis errores que también golpearán tu código en C++.

Hay un viejo chiste sobre que la diferencia entre un ingeniero senior y uno junior es que el senior sabe que va a ser una pelea con el compilador antes de empezar. Este fin de semana fue una pelea con el compilador. El compilador fue Microsoft Visual C++ tal como se distribuye en Visual Studio 2026 Insiders. El código fue Raku. La pelea se extendió a lo largo de los dos días y unas cuantas sesiones de última hora entre semana. El código ganó, pero por poco.

Quiero dejar esto por escrito porque el registro público de ingeniería debería incluir los días en que las cosas no funcionaron, y porque la manera en que los agentes y yo trabajamos a través de esto es genuinamente la parte del flujo de trabajo sobre la que más curiosidad tengo por la opinión de otras personas.

El planteamiento

Hasta este fin de semana el runtime compilaba limpio en Linux con GCC y en macOS con Clang. Ambos han sido mis principales entornos de desarrollo de fin de semana. En realidad no había intentado un build de Windows MSVC desde la puesta en marcha inicial en octubre. Se supone que el runtime es multiplataforma. Multiplataforma significa Windows. Así que el sábado por la mañana descargué el repositorio en una máquina Windows con Visual Studio 2026 Insiders y ejecuté el build.

No compiló. Ni de cerca. El primer pase de compilación produjo más de doscientos errores y una cantidad comparable de advertencias. Los errores caían en aproximadamente seis categorías, cada una de las cuales se convirtió en su propio PR.

Cuáles fueron las categorías

Cada una merece describirse porque cada una es el tipo de cosa que golpea a cualquier código en C++ la primera vez que se encuentra con una versión nueva de MSVC. Otros equipos se toparán con esto. Algunos quizás ya se estén topando con ello.

Uno: macros de Windows contaminando nuestros espacios de nombres. Los headers de Windows hacen #define de un montón de nombres genéricos (min, max, DOMAIN, HULL, ERROR, OK, NEAR, FAR) que colisionan con nombres de enum razonables, nombres de funciones y especializaciones de plantillas. Nuestra API en C de registro tenía un valor de enum llamado ERROR. Windows también había definido ERROR como una macro. El compilador hizo exactamente lo que dice la especificación que hace, que es expandir la macro y producir galimatías. La solución es #undef ERROR antes de nuestro header, con un alcance estrecho. Lo mismo para los demás.

Dos: archivos fuente marcados con BOM que MSVC se negaba a compilar. Algunos de nuestros archivos fuente tenían una marca de orden de bytes UTF-8 al principio, que la mayoría de los compiladores toleran, y MSVC 2026 no. El agente completó un barrido que eliminó los BOM de cada archivo fuente C/C++ del repositorio.

Tres: APIs de CRT obsoletas. Un montón de funciones estándar de C que el estándar C considera correctas están marcadas por MSVC como “obsoletas, usa la variante segura.” sscanf se convierte en sscanf_s. strncpy se convierte en strncpy_s. El agente revisó todo y o bien reemplazó las llamadas con las variantes seguras o las envolvió con el pragma _CRT_SECURE_NO_WARNINGS apropiado donde la variante segura habría cambiado la semántica de maneras que no queríamos.

Cuatro: macros de exportación de DLL. La más grande. Cada símbolo público en cada DLL tiene que marcarse con __declspec(dllexport) al construir la DLL y con __declspec(dllimport) al consumirla desde otra DLL. Linux GCC y macOS Clang no necesitan esto. MSVC sí, y nuestro código tenía muchos casos donde la macro faltaba, se aplicaba de forma inconsistente, o se aplicaba accidentalmente a especializaciones de plantillas que el compilador en realidad no quería exportar. La solución fue un barrido que normalizó la macro de exportación en cada header de API pública y la añadió donde faltaba.

Cinco: RAKU_API y las DLLs consolidadas. Una más rara. Parte de nuestra configuración interna de CMake estaba inyectando -DRAKU_API=__declspec(dllexport) en tiempo de compilación incluso para bibliotecas estáticas que no deberían haber estado exportando. Errores C2491 de MSVC por todas partes. La solución fue un sanitizador de CMake que deshace explícitamente la definición de RAKU_API para objetivos estáticos y solo la establece para los dinámicos.

Seis: headers de OpenXR y <array>. Un puñado de compilaciones de MSVC fallaban porque se usaba <array> sin incluirlo explícitamente. GCC y Clang tienden a incluirlo transitivamente a través de otros headers de la STL. MSVC no, e “incluye lo que uses” es la respuesta correcta de todas formas. El agente añadió los includes faltantes.

Cómo transcurrió el fin de semana

El sábado por la mañana fue principalmente yo reproduciendo cada clase de error y escribiendo las notas de diagnóstico. Los agentes no tienen una VM de Windows delante. Tuve que capturar la salida del build, depurarla y devolvérsela al agente con una petición clara: “esta es la clase de error, este es un ejemplo canónico, este es el archivo donde vive, propón un barrido que arregle todas las instancias de esta clase.”

Los agentes manejaron los barridos con limpieza. El PR #408 arregló conflictos de macros de Windows en logging.cpp. El PR #406 arregló la redefinición de enum de MSVC. El PR #404 añadió el sanitizador de CMake para las macros de RAKU_API. El PR #408 (uno diferente en arvr_demo_telemetry) arregló errores de exportación de DLL de Windows. El PR #411 arregló errores de enlazado de DLL de MSVC 2026 y advertencias de obsolescencia. El PR #413 eliminó los BOM y reemplazó APIs obsoletas. El PR #415 arregló errores C2491 añadiendo RAKU_RUNTIME_EXPORTS a bibliotecas estáticas. El PR #416 arregló el build de CMake con una obtención de OpenXR solo de headers y añadió fuentes de runtime faltantes. El PR #401 arregló macros de exportación de DLL de Windows y eliminó una solución alternativa de MSVC que ya estaba obsoleta.

Doce PRs en dos días, más o menos. Cada uno de ellos está documentado bajo #404–#416 en el repositorio del runtime.

El sábado por la tarde fue el tramo más largo. La normalización de exportación de DLL requirió leer cada header de API pública del motor y decidir qué símbolos eran genuinamente parte de la superficie pública. Algunos resultaron no serlo. Unos cuantos se degradaron a internos como parte de este trabajo, lo cual fue un beneficio neto aunque añadió alcance.

El domingo se fue en un flujo de trabajo de CI de Windows MSVC con vcpkg e integración del SDK de OpenXR para que esto nunca vuelva a pasar en silencio. Ahora cada push dispara un build de MSVC. El build no puede regresar sin que alguien lo vea en el CI.

El final del domingo fue la celebración. Para cuando se cerró el portátil por la noche, el build se puso en verde en Windows. Primer build x64 exitoso en la historia del runtime. El mensaje de commit dice exactamente eso: build: first successful x64 build with OpenXR handle fixes. El hash del commit es f35f78bd y es uno de mis commits favoritos del proyecto hasta la fecha.

Lo que funcionó, lo que haría diferente

Unas cuantas notas honestas.

Poner en marcha una plataforma nueva tarde es costoso. Debería haber ejecutado un build de MSVC un par de fines de semana atrás, cuando el código era más pequeño. Los errores a esa escala habrían sido veinte, no doscientos. El costo de arreglar veinte errores es significativamente menor que el costo de arreglar doscientos. La lección es nunca dejar que una plataforma objetivo se quede sin compilarse durante más de un par de fines de semana.

Los barridos impulsados por agentes son la respuesta correcta cuando la solución es mecánica. El barrido de exportación de DLL, la eliminación de BOM, el reemplazo de CRT obsoleto: todos estos eran exactamente el tipo de trabajo que el agente hace más rápido y de forma más consistente que un humano. Encuadré cada uno como “encuentra todas las instancias del patrón X, aplica la transformación Y, deja todo lo demás en paz,” y el agente hizo exactamente eso.

Los barridos impulsados por agentes son la respuesta equivocada cuando la solución requiere juicio. El problema de la macro RAKU_API requería decidir qué objetivos de CMake realmente querían la exportación y cuáles no. Eso no fue un barrido. Fue una revisión cuidadosa, objetivo por objetivo. Hice ese a mano con el agente actuando como un segundo par de ojos en cada decisión, no como el ejecutor.

Un modelo diferente detectó un error que otro modelo escribió. Durante el barrido de reemplazo de CRT obsoleto, uno de los agentes reemplazó sprintf con sprintf_s en un lugar donde la semántica del tamaño del búfer era sutilmente diferente de lo que esperaba el sitio de la llamada. El PR se completó. Un pase de revisión de un modelo diferente detectó el desajuste antes de que se lanzara. El flujo de trabajo de revisión multi-proveedor se ganó su lugar este fin de semana, específicamente.

Lo que se llevan socios y constructores de esto

Si eres un socio pensando en si este motor se lanza en Windows, la respuesta a partir del domingo por la noche es sí. El build de MSVC está en verde. El CI lo mantiene en verde de ahora en adelante.

Si eres un desarrollador trabajando en tu propio código multiplataforma en C++ y estás a punto de probar Visual Studio 2026 Insiders por primera vez, las seis categorías de arriba son lo que te va a golpear. Puedes anticipar la mayoría de ellas. Ahora ya lo sabes.

Si eres alguien del equipo de MSVC leyendo esto, el equipo ha hecho buen trabajo en 2026 Insiders. Las advertencias son genuinamente útiles y las herramientas nuevas son mejores que las de 2022. Las rupturas de compatibilidad están ahí en su mayoría por buenas razones. Reportaría unos cuantos bugs si tuviera más tiempo. Van a llegar.

Domingo por la noche, el motor compila limpio en tres plataformas. Eso es lo correcto con lo que entrar al lunes.