Visual Studio 2026が私たちのコードを嫌った週末

クロスプラットフォームとは、すべてのプラットフォームでビルドがグリーンになって初めて言える約束だ。これはRakuAIがそれをWindows上で現実にした週末の話であり - そしてあなたのC++コードベースにも降りかかるであろう6つのエラーへの攻略法でもある。

シニアエンジニアとジュニアエンジニアの違いは、シニアエンジニアは始める前からコンパイラとの戦いになると分かっていることだ、という古いジョークがある。この週末はコンパイラとの戦いだった。そのコンパイラは、Visual Studio 2026 Insidersに搭載されているMicrosoft Visual C++だった。コードベースはRakuだった。その戦いは両日にわたり、平日の夜遅くの実行も何回か伴った。コードベースは勝ったが、辛勝だった。

これを書き留めておきたい。公開のエンジニアリングログには、うまくいかなかった日々も含まれるべきだからだ。そして、エージェントと私がこれをどう乗り切ったかは、他の人々の意見を本当に聞いてみたいと思っているワークフローの部分だからだ。

前提

この週末までは、ランタイムはLinux上のGCCとmacOS上のClangできれいにビルドできていた。そのどちらも、私の週末の主要な開発環境だった。10月の初期立ち上げ以来、実際にはWindows MSVCビルドを試していなかった。このランタイムはクロスプラットフォームであるはずだ。クロスプラットフォームとはWindowsを意味する。そこで土曜の朝、Visual Studio 2026 InsidersがインストールされたWindowsマシンでリポジトリをチェックアウトし、ビルドを実行した。

ビルドできなかった。ほとんどビルドできなかった。最初のコンパイルパスは200件を超えるエラーと、それに匹敵する数の警告を生み出した。エラーはおおよそ6つのカテゴリに分かれ、それぞれが独自のPRになった。

そのカテゴリとは何だったか

それぞれ説明する価値がある。どれも、新しいMSVCバージョンに初めて出会ったときにどんなC++コードベースにも降りかかる種類のものだからだ。他のチームもこれらに遭遇するだろう。すでに遭遇しているチームもあるかもしれない。

1つ目：私たちの名前空間を汚染するWindowsマクロ。 Windowsのヘッダーは、妥当なenum名、関数名、テンプレート特殊化と衝突する汎用的な名前(min、max、DOMAIN、HULL、ERROR、OK、NEAR、FAR)を大量に #define している。私たちのロギングC APIには ERROR という名前のenum値があった。Windowsもまた ERROR をマクロとして定義していた。コンパイラは仕様が言う通りのことを正確に行った。つまりマクロを展開し、意味不明な結果を生み出した。修正は、私たちのヘッダーの前に、範囲を厳密に絞った #undef ERROR だ。他のものについても同様だ。

2つ目：MSVCがコンパイルを拒否したBOM付きソースファイル。 私たちのソースファイルのいくつかは、先頭にUTF-8のバイトオーダーマークが付いていた。ほとんどのコンパイラはこれを許容するが、MSVC 2026は許容しない。エージェントは、リポジトリ内のすべてのC/C++ソースファイルからBOMを取り除く一掃作業を着地させた。

3つ目：非推奨のCRT API。 C標準では問題ないとされている標準Cの関数の多くが、MSVCによって「非推奨、セキュアな亜種を使え」とフラグされる。sscanf は sscanf_s になる。strncpy は strncpy_s になる。エージェントは調べて回り、呼び出しをセキュアな亜種に置き換えるか、セキュアな亜種がセマンティクスを望まない形で変えてしまう箇所には適切な _CRT_SECURE_NO_WARNINGS プラグマでラップした。

4つ目：DLLエクスポートマクロ。 最大のものだ。すべてのDLL内のすべての公開シンボルは、そのDLLをビルドするときは __declspec(dllexport)、別のDLLからそれを消費するときは __declspec(dllimport) でマークされなければならない。Linux GCCとmacOS Clangはこれを必要としない。MSVCは必要とし、私たちのコードベースには、マクロが欠けていたり、一貫性なく適用されていたり、コンパイラが実際にはエクスポートしてほしくなかったテンプレート特殊化に誤って適用されていたりする箇所が多くあった。修正は、すべての公開API用ヘッダーにわたってエクスポートマクロを正規化し、欠けている箇所に追加する一掃作業だった。

5つ目：RAKU_API と統合されたDLL群。 より奇妙なものだ。私たちの内部CMake設定の一部が、エクスポートすべきではない静的ライブラリに対してさえ、コンパイル時に -DRAKU_API=__declspec(dllexport) を注入していた。あちこちでMSVCのC2491エラーが発生した。修正は、静的ターゲットに対してはRAKU_APIを明示的にundefし、動的ターゲットに対してのみそれを設定するCMakeのサニタイザーだった。

6つ目：OpenXRのヘッダーと <array>。 一握りのMSVCコンパイルが、<array> が明示的にインクルードされずに使われていたために失敗した。GCCとClangは、他のSTLヘッダーを通じて推移的にそれをインクルードする傾向がある。MSVCはそうしない。そして「使うものはインクルードせよ」は、いずれにせよ正しい答えだ。エージェントは欠けていたインクルードを追加した。

この週末はどう進んだか

土曜の朝は、ほとんどが私自身がそれぞれのエラーのクラスを再現し、診断メモを書くことに費やされた。エージェントは目の前にWindowsのVMを持っていない。私はビルドの出力をキャプチャし、整理し、明確な依頼とともにエージェントに渡さなければならなかった。「これがエラーのクラスであり、これが正規の一例であり、これがそれが住んでいるファイルであり、このクラスのすべてのインスタンスを修正する一掃を提案せよ」。

エージェントたちはこの一掃をきれいに処理した。PR #408は logging.cpp におけるWindowsマクロの衝突を修正した。PR #406はMSVCのenum再定義を修正した。PR #404はRAKU_APIマクロのためのCMakeサニタイザーを追加した。PR #408(arvr_demo_telemetryにある別のもの)はWindows DLLエクスポートエラーを修正した。PR #411はMSVC 2026のDLLリンケージエラーと非推奨警告を修正した。PR #413はBOMを取り除き、非推奨APIを置き換えた。PR #415は静的ライブラリにRAKU_RUNTIME_EXPORTSを追加してC2491エラーを修正した。PR #416は、ヘッダーオンリーのOpenXR取得でCMakeビルドを修正し、欠けていたランタイムのソースを追加した。PR #401はWindows DLLエクスポートマクロを修正し、今や不要になっていたMSVCの回避策を取り除いた。

2日間で12件のPR、おおよそだが。それぞれがランタイムリポジトリの#404から#416の下に文書化されている。

土曜の午後が最も長い区間だった。DLLエクスポートの正規化には、エンジン内のすべての公開API用ヘッダーを読み、どのシンボルが本当に公開表面の一部なのかを判断する必要があった。そのうちのいくつかは、そうではないことが判明した。この作業の一環として、いくつかは内部用に降格された。それはスコープが広がったとはいえ、正味では良いことだった。

日曜は、vcpkgとOpenXR SDKの統合を伴うWindows MSVC CIワークフローに費やされた。これが二度と静かに起きないようにするためだ。今やすべてのプッシュがMSVCビルドをトリガーする。誰かがCIでそれを見ることなくビルドが退行することはあり得ない。

日曜の終わりは祝賀だった。その夜ラップトップを閉じるまでに、ビルドはWindows上でグリーンになった。ランタイム史上初めて成功したx64ビルドだ。コミットメッセージはまさにそう書いている。build: first successful x64 build with OpenXR handle fixes。コミットハッシュは f35f78bd で、これまでこのプロジェクトで最もお気に入りのコミットの一つだ。

うまくいったこと、違うやり方をしたかったこと

いくつか正直なメモがある。

新しいプラットフォームを遅く立ち上げるのはコストが高い。 コードベースがまだ小さかった数週間前にMSVCビルドを実行しておくべきだった。その規模でのエラーは200件ではなく20件だっただろう。20件のエラーを修正するコストは、200件のエラーを修正するコストよりもはるかに小さい。教訓は、ターゲットプラットフォームを2週間以上ビルドしないまま放置しないということだ。

修正が機械的なとき、エージェント駆動の一掃は正しい答えだ。 DLLエクスポートの一掃、BOMの除去、非推奨CRTの置き換え、これらはすべて、エージェントが人間よりも速く、より一貫してこなす種類の作業だ。私はそれぞれを「パターンXのすべてのインスタンスを見つけ、変換Yを適用し、それ以外はそのままにせよ」と組み立て、エージェントはまさにその通りにした。

修正が判断を必要とするとき、エージェント駆動の一掃は間違った答えだ。 RAKU_APIマクロの問題は、どのCMakeターゲットが実際にエクスポートを望んでいて、どれが望んでいないかを判断する必要があった。それは一掃ではなかった。ターゲットごとの注意深いレビューだった。私はそれを手作業で行い、エージェントは実行者としてではなく、各判断に対する2番目の目として振る舞った。

別のモデルが、あるモデルが書いたバグを捕まえた。 非推奨CRTの置き換えの一掃の最中、あるエージェントが sprintf を sprintf_s に置き換えたが、その呼び出し箇所が期待していたものとバッファサイズのセマンティクスが微妙に異なる場所があった。そのPRは着地した。別のモデルによるレビューパスが、それが出荷される前にその不一致を捕まえた。複数ベンダーのレビューワークフローが、この週末、まさにその存在価値を発揮した。

パートナーとビルダーがこれから読み取ること

もしあなたが、このエンジンがWindows上で出荷されるかどうか考えているパートナーなら、日曜の夜の時点での答えはイエスだ。MSVCビルドはグリーンだ。CIはこの先それをグリーンに保ち続ける。

もしあなたが自分自身のクロスプラットフォームC++コードベースに取り組んでいて、初めてVisual Studio 2026 Insidersを試そうとしているなら、上記の6つのカテゴリがあなたに降りかかることになるものだ。そのほとんどは事前に対処できる。もう分かったはずだ。

もしあなたがMSVCチームの人でこれを読んでいるなら、チームは2026 Insidersで良い仕事をしている。警告は本当に役に立つし、新しいツールは2022より良い。互換性の断絶はほとんど正当な理由があってのことだ。もっと時間があればいくつかバグ報告をファイルするところだ。近いうちにやる。

日曜の夜、このエンジンは3つのプラットフォームでクリーンにビルドできる。それが月曜日を迎えるために持っておくべき正しいものだ。