O Fim de Semana em Que o Visual Studio 2026 Odiou Nosso Código

Multiplataforma é uma promessa que você só consegue fazer depois de o build estar verde em toda plataforma. Este é o fim de semana em que a RakuAI a tornou verdadeira no Windows - e o manual para os seis erros que vão atingir a sua base de código C++ também.

Existe uma piada antiga de que a diferença entre um engenheiro sênior e um engenheiro júnior é que o sênior já sabe que vai ser uma briga com o compilador antes de começar. Este fim de semana foi uma briga com o compilador. O compilador era o Microsoft Visual C++ como vem no Visual Studio 2026 Insiders. A base de código era a Raku. A briga se estendeu pelos dois dias e algumas execuções tarde da noite vindas da semana de trabalho. A base de código venceu, mas por pouco.

Quero registrar este porque o diário público de engenharia deveria incluir os dias em que as coisas não funcionaram, e porque o jeito como eu e os agentes trabalhamos nisso é genuinamente a parte do fluxo de trabalho sobre a qual estou mais curioso pela opinião de outras pessoas.

O cenário

Até este fim de semana o runtime compilava limpo no Linux com GCC e no macOS com Clang. Ambos têm sido meus ambientes principais de desenvolvimento de fim de semana. Eu não tinha de fato tentado um build MSVC no Windows desde o bring-up inicial em outubro. O runtime deveria ser multiplataforma. Multiplataforma significa Windows. Então no sábado de manhã eu peguei o repositório em uma máquina Windows com Visual Studio 2026 Insiders e rodei o build.

Não compilou. Nem chegou perto de compilar. A primeira passada de compilação produziu mais de duzentos erros e um número comparável de avisos. Os erros caíram em aproximadamente seis categorias, cada uma das quais virou seu próprio PR.

Quais foram as categorias

Cada uma vale a pena descrever porque cada uma é o tipo de coisa que atinge qualquer base de código C++ na primeira vez que encontra uma nova versão do MSVC. Outros times vão encontrar isso. Alguns talvez já estejam encontrando.

Um: macros do Windows poluindo nossos namespaces. Cabeçalhos do Windows fazem #define de um monte de nomes genéricos (min, max, DOMAIN, HULL, ERROR, OK, NEAR, FAR) que colidem com nomes razoáveis de enum, nomes de função, e especializações de template. Nossa API C de logging tinha um valor de enum chamado ERROR. O Windows também tinha definido ERROR como uma macro. O compilador fez exatamente o que a especificação diz que ele faz, que é expandir a macro e produzir algaravia. A correção é #undef ERROR antes do nosso cabeçalho, com escopo restrito. O mesmo para os outros.

Dois: arquivos-fonte marcados com BOM que o MSVC se recusou a compilar. Alguns dos nossos arquivos-fonte tinham uma marca de ordem de byte UTF-8 no topo, que a maioria dos compiladores tolera, e o MSVC 2026 não tolera. O agente entregou uma varredura que removeu BOMs de todo arquivo-fonte C/C++ no repositório.

Três: APIs de CRT depreciadas. Um monte de funções C padrão que o padrão C considera adequadas são sinalizadas pelo MSVC como “depreciadas, use a variante segura.” sscanf vira sscanf_s. strncpy vira strncpy_s. O agente passou por elas e ou substituiu as chamadas pelas variantes seguras ou as envolveu com o pragma _CRT_SECURE_NO_WARNINGS apropriado onde a variante segura teria mudado a semântica de jeitos que não queríamos.

Quatro: macros de exportação de DLL. A maior. Todo símbolo público em toda DLL tem que ser marcado com __declspec(dllexport) ao construir a DLL e __declspec(dllimport) ao consumi-la de outra DLL. GCC no Linux e Clang no macOS não precisam disso. O MSVC precisa, e a nossa base de código tinha muitos casos onde a macro estava faltando, aplicada de forma inconsistente, ou aplicada acidentalmente a especializações de template que o compilador na verdade não queria exportar. A correção foi uma varredura que normalizou a macro de exportação em todo cabeçalho de API pública e a adicionou onde faltava.

Cinco: RAKU_API e as DLLs consolidadas. Uma mais estranha. Parte da nossa configuração interna de CMake estava injetando -DRAKU_API=__declspec(dllexport) em tempo de compilação até mesmo para bibliotecas estáticas que não deveriam estar exportando nada. Erros C2491 do MSVC por toda parte. A correção foi um sanitizador de CMake que explicitamente indefine RAKU_API para alvos estáticos e só o define para os dinâmicos.

Seis: cabeçalhos OpenXR e <array>. Um punhado de compilações MSVC falhou porque <array> estava sendo usado sem ser explicitamente incluído. GCC e Clang tendem a incluí-lo transitivamente através de outros cabeçalhos da STL. O MSVC não faz isso, e “inclua o que você usa” é a resposta certa independentemente. O agente adicionou os includes faltando.

Como foi o fim de semana

Sábado de manhã foi principalmente eu reproduzindo cada classe de erro e escrevendo as notas de diagnóstico. Os agentes não têm uma VM Windows na frente deles. Eu tive que capturar a saída do build, higienizá-la, e entregá-la de volta ao agente com um pedido claro: “aqui está a classe de erro, aqui está um exemplo canônico, aqui está o arquivo onde ela vive, proponha uma varredura que corrija todas as instâncias dessa classe.”

Os agentes lidaram com as varreduras de forma limpa. O PR #408 corrigiu conflitos de macro do Windows em logging.cpp. O PR #406 corrigiu a redefinição de enum do MSVC. O PR #404 adicionou o sanitizador de CMake para macros RAKU_API. O PR #408 (um diferente em arvr_demo_telemetry) corrigiu erros de exportação de DLL do Windows. O PR #411 corrigiu erros de linkagem de DLL do MSVC 2026 e avisos de depreciação. O PR #413 removeu BOMs e substituiu APIs depreciadas. O PR #415 corrigiu erros C2491 adicionando RAKU_RUNTIME_EXPORTS a bibliotecas estáticas. O PR #416 corrigiu o build do CMake com uma busca de OpenXR somente-cabeçalho e adicionou fontes de runtime faltando. O PR #401 corrigiu macros de exportação de DLL do Windows e removeu um workaround do MSVC que já estava obsoleto.

Doze PRs em dois dias, mais ou menos. Cada um deles está documentado sob #404–#416 no repositório do runtime.

Sábado à tarde foi o trecho mais longo. A normalização de exportação de DLL exigiu ler todo cabeçalho de API pública no motor e decidir quais símbolos genuinamente faziam parte da superfície pública. Alguns acabaram não fazendo. Alguns foram rebaixados para internos como parte desse trabalho, o que foi um ganho líquido mesmo que tenha aumentado o escopo.

Domingo foi dedicado a um workflow de CI do MSVC no Windows com integração de vcpkg e OpenXR SDK para que isso nunca aconteça de novo silenciosamente. Agora todo push dispara um build do MSVC. O build não pode regredir sem alguém ver na CI.

O fim do domingo foi a comemoração. Quando o laptop fechou pela noite, o build ficou verde no Windows. Primeiro build x64 bem-sucedido na história do runtime. A mensagem de commit diz exatamente isso: build: first successful x64 build with OpenXR handle fixes. O hash do commit é f35f78bd e é um dos meus commits favoritos no projeto até hoje.

O que funcionou, o que eu faria diferente

Algumas notas honestas.

Trazer uma nova plataforma para operação tarde é caro. Eu deveria ter rodado um build do MSVC alguns fins de semana atrás quando a base de código era menor. Os erros nessa escala teriam sido vinte, não duzentos. O custo de corrigir vinte erros é significativamente menor que o custo de corrigir duzentos. A lição é nunca deixar uma plataforma-alvo ficar sem compilar por mais de alguns fins de semana.

Varreduras conduzidas por agentes são a resposta certa quando a correção é mecânica. A varredura de exportação de DLL, a remoção de BOM, a substituição de CRT depreciada: todas essas eram exatamente o tipo de trabalho que o agente faz mais rápido e mais consistentemente que um humano. Enquadrei cada uma como “encontre todas as instâncias do padrão X, aplique a transformação Y, deixe tudo o mais intocado,” e o agente fez exatamente isso.

Varreduras conduzidas por agentes são a resposta errada quando a correção exige julgamento. O problema da macro RAKU_API exigiu decidir quais alvos de CMake de fato queriam a exportação e quais não. Aquilo não era uma varredura. Era uma revisão cuidadosa, alvo por alvo. Fiz aquela à mão com o agente atuando como um segundo par de olhos em cada decisão, não como o executor.

Um modelo diferente pegou um bug que outro modelo escreveu. Durante a varredura de substituição de CRT depreciada, um dos agentes substituiu sprintf por sprintf_s em um lugar onde a semântica de tamanho de buffer era sutilmente diferente do que o ponto de chamada esperava. O PR entrou. Uma passada de revisão por um modelo diferente pegou a incompatibilidade antes de ser lançada. O fluxo de trabalho de revisão multi-fornecedor se pagou neste fim de semana, especificamente.

O que parceiros e construtores tiram disso

Se você é um parceiro pensando se este motor é lançado no Windows, a resposta a partir do domingo à noite é sim. O build do MSVC está verde. A CI o mantém verde daqui em diante.

Se você é um desenvolvedor trabalhando na sua própria base de código C++ multiplataforma e está prestes a tentar o Visual Studio 2026 Insiders pela primeira vez, as seis categorias acima são o que vai te atingir. Você pode antecipar a maioria delas. Agora você sabe.

Se você é uma pessoa do time do MSVC lendo isso, o time fez um bom trabalho no 2026 Insiders. Os avisos são genuinamente úteis e as novas ferramentas são melhores que as de 2022. As quebras de compatibilidade em sua maioria existem por boas razões. Eu registraria alguns relatos de bug se tivesse mais tempo. Estão a caminho.

Domingo à noite, o motor compila limpo em três plataformas. Essa é a coisa certa para levar para a segunda-feira.