RobobunがBunのモジュールローダーのUTF-8エンコーディングバグを修正

BunプロジェクトのPR #33864は、モジュールローダーにおけるエンコーディング問題を修正しました。開発者がbun build --target=bunを使用し、カスタムバナーやフッターに非ASCII文字（日本語や絵文字など）を含めた場合、BunはUTF-8でエンコードされたバイトを誤ってLatin-1（ISO 8859-1）として処理していました。この誤認識により、文字列リテラルは文字化け（mojibake）し、非ASCII識別子はSyntaxErrorを引き起こしました。

問題の根本は、Bunの組み込みモジュールローダーが// @Bunプラグマを検出すると、ファイルをそのままJavaScriptCore（JSC）に渡すことにあります。しかし、ローダーは内部文字列を構築する際にString::clone_latin1メソッドを使用しており、各バイトを1つのLatin-1コード単位として扱っていました。ASCII文字のみのコードでは問題ありませんが、バナー/フッターにUTF-8の非ASCII文字が含まれると、マルチバイトシーケンスが複数のLatin-1文字に分解され、データが破損しました。

Robobunによる修正では、2箇所のローダーロジックをString::clone_utf8を使用するように変更しました。新しいメソッドはsimdutfライブラリを活用し、入力が純粋なASCIIの場合は高速なLatin-1コピーパスを利用（パフォーマンスを維持）、非ASCIIの場合は正しくUTF-8デコードを実行します。これにより、ソースコードと追加されたバナー/フッターの両方が正しいエンコーディングでJSCに渡されるようになりました。

修正はこれだけにとどまりません。続くコミット（68c1594）では、--bytecodeフラグを同時に使用した場合にバイトコードキャッシュにも影響が及ぶことが判明しました。ローダーがUTF-8デコードされたキーを生成する一方、キャッシュ生成器は依然としてLatin-1キーを使用していたため、decodeCodeBlockが不一致を検出し、JSCがコードを再パースする原因となっていました。これにより、プリコンパイルされた.jscファイルは無効な負荷として残されていました。このコミットでは、両方のシナリオで文字列構築を統一するヘルパー関数を導入し、simdutfを使用してASCII高速パスまたはUTF-8デコードを適用しています。

PR #33864はRobobunによって作成され、Claudeボットによってコードレビューが行われ、「claude」および「slop」ラベルが付けられました。CIでは複数のプラットフォームで5件のテスト失敗（WebSocket、WebView、プロキシストレステストなど）が発生しましたが、一部は本修正とは無関係です。最終的にPRは2026年7月9日にクローズされ、マージされました。この修正は、国際化対応やカスタムバナーを利用するBunユーザーにとって重要であり、本番環境で潜在的なバグを引き起こす原因を取り除くものです。