Pull Request on 2026年07月19日

dotnet/runtimeにマージされたPull RequestをAIで日本語要約

注意点

このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。

#131033 Keep runtimelab IntermediateArtifacts on classic build artifacts

概要

runtimelab の下流コンシューマーの互換性を保つため、中間成果物のアップロードステップを Pipeline Artifacts から従来の Azure DevOps Build Artifacts に戻します。複数のジョブが同一名の成果物に発行する必要があるため、この変更が必要です。今後すべての runtimelab ブランチが v3/v4 発行に移行すれば、この設定は削除可能です。

変更内容

  • eng/pipelines/common/upload-intermediate-artifacts-step.yml: Pipeline Artifact 発行テンプレートを 1ES.PublishBuildArtifacts@1 / PublishBuildArtifacts@1 タスクに置き換え
  • 公式/非公式タスクの分岐を追加
  • 従来の Build Artifacts が必要な理由についてのインラインコメントを追加

パフォーマンスへの影響

影響なし

関連Issue

#128498

その他

この変更は CI/CD パイプラインの設定に関するもので、ランタイムの機能や公開 API には影響しません。runtimelab の複数のジョブが同じ成果物に発行するワークフローに対応するための暫定的な対応です。

#131026 [perf][wasm] Stage CoreCLR wasm runtime pack for Mono workload install

  • 作成者: @lewing
  • 作成日時: 2026年07月19日 01:40:00(UTC)
  • マージ日時: 2026年07月19日 15:11:05(UTC)
  • ラベル: area-Build-mono

概要

WASM パフォーマンスパイプラインの修正。PR #130380 で wasm-tools ワークロードマニフェストに CoreCLR ランタイムパック Microsoft.NETCore.App.Runtime.browser-wasm が追加されたことで、Mono ビルドジョブが必要なパックを見つけられず、ワークロードインストール時に失敗していた問題を解決する。CoreCLR ビルドジョブが生成するランタイムパックを Mono ビルドジョブが再利用するよう、パイプラインテンプレートを修正。

変更内容

  • perf-wasm-prepare-artifacts-steps.yml

    • publishCoreClrRuntimePack パラメータ追加：CoreCLR ジョブが Microsoft.NETCore.App.Runtime.browser-wasm nupkg をアーティファクトとして発行
    • downloadCoreClrRuntimePack パラメータ追加：Mono ジョブがアーティファクトをダウンロードし、ワークロードインストール前に artifacts/packages/Release/Shipping/ にステージング

  • perf-wasm-build-jobs.yml

    • wasm_coreclr ジョブで publishCoreClrRuntimePack: true を設定
    • wasm (Mono) ジョブで downloadCoreClrRuntimePack: true を設定し、dependsOn: build_browser_wasm_linux_Release_wasm_coreclr で CoreCLR ビルドジョブに依存

パフォーマンスへの影響

Mono ビルドジョブが CoreCLR ビルドジョブに依存するようになったため、これまで並列実行できていたジョブが順序付き実行となり、PR トリガー時のサニティパイプラインの総実行時間が増加する。

関連Issue

#130380

その他

  • ステージングされた CoreCLR パックは Mono ジョブの既存の _GetRuntimePackNuGetsToBuild ロジック（Microsoft.NETCore.App.Runtime.Mono.* のみマッチ）と干渉しない
  • 本修正は #130380 で main/extra-platforms CI で採用されたパターンに従い、既存の CoreCLR ビルドを再利用することで、重複したビルドを回避
  • このPRはGitHub Copilotのアシスタンスを受けて生成

#131025 [wasm] Fix native build failing when temp path contains parentheses

概要

WebAssembly のネイティブビルド（Emcc）において、一時ディレクトリパスにかっこが含まれている場合に dotnet publish が失敗する Windows 固有の問題を修正します。例えば C:\Users\John(US)\AppData\Local\Temp\... のようなテンポラリパスで失敗していた問題が対象です。

根本原因は cmd.exe の /c オプションが引用符で囲まれたパス内の特殊文字（かっこ）を検出すると、引用符を削除してしまうため、パスが正しく解析されないことです。

変更内容

  • src/tasks/Common/Utils.cs: Utils.RunShellCommand の Windows パスで、テンポラリスクリプト呼び出しを cmd /S /c ""<script>"" に変更。/S フラグにより cmd.exe は最外層の引用符のみを削除し、内側の引用符は保持されるため、かっこを含むパスでも正確に処理されます。Unix（/bin/sh）パスは変更なし。
  • src/mono/wasm/Wasm.Build.Tests/NativeBuildTests.cs: Windows 限定の回帰テスト NativeBuildWithParenthesesInTempPath を追加。%TMP%/%TEMP% をかっこ付きディレクトリに指定した状態で、エンドツーエンドのネイティブパブリッシュ/ビルドを実行。

パフォーマンスへの影響

影響なし

関連Issue

#120327

その他

  • この修正は Windows 固有の問題であり、Unix（Linux/macOS）の /bin/sh コードパスは影響を受けません。
  • テストは Windows CI でのみ実行され、[SkipOnPlatform(TestPlatforms.AnyUnix, …)] で保護されています。
  • PR は GitHub Copilot により作成されました。

#131023 [wasm] Bump chrome for testing - linux: 150.0.7871.128, windows: 150.0.7871.129, mac: 150.0.7871.129

概要

WebAssembly（WASM）テスト環境で使用するChrome for Testingのバージョンを更新するプロパティファイルの更新です。Linux、Windows、macOSの各プラットフォームに対応したChrome for Testingバージョンを最新版に統一しました。

変更内容

  • eng/testing/BrowserVersions.props: Chrome for Testingのバージョン情報を更新
    • Linux: 150.0.7871.128に更新
    • Windows: 150.0.7871.129に更新
    • macOS: 150.0.7871.129に更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このプルリクエストはGitHub Actionsボットによる自動更新です。WASM関連テストの環境構成ファイルの定期メンテナンスの一部と考えられます。

#131022 [mono][wasm] Respect [Un]SupportedOSPlatform in the Mono pinvoke generator

概要

Mono wasm バックエンドで、[SupportedOSPlatform]/[UnsupportedOSPlatform]属性を尊重していなかったP/Invoke生成器を修正しました。ターゲットOS（browser）で非サポートのP/Invokeメソッドが解析対象となり、不必要な警告（WASM0001/WASM0060/WASM0062）が発生していた問題を解決します。

変更内容

  • PInvokeCollector.cs: TargetOSパラメータを追加し、[UnsupportedOSPlatform]または対象OSをサポートしていない[SupportedOSPlatform(...)]が指定されたメソッド、型、アセンブリをスキップするロジックを実装
  • ManagedToNativeGenerator.cs: TargetOSをPInvokeTableGenerator経由でPInvokeCollectorに渡すように修正
  • PInvokeTableGenerator.cs: TargetOSパラメータを受け取り、PInvokeCollectorに転送
  • WasmApp.Common.targets: Mono タスクにTargetOSプロパティ（デフォルト: browser）を追加
  • テスト資産: Windows専用の非blittable P/Invoke（HandleRef/objectパラメータ）を含むテストアセットとテストケースを追加

パフォーマンスへの影響

影響なし

関連Issue

#110870

その他

  • 本修正はMono wasm ビルドタスクのみに影響し、CoreCLRは変更なし
  • CoreCLR側は既にIsUnsupportedOnPlatform/EvaluatePlatformAttributesでプラットフォーム属性チェックを実装していたため、このロジックをMonoに移植した形
  • 新規テスト「PInvokeTableGeneratorTests.UnsupportedOSPlatformPInvokeIsSkipped」で、Windows専用P/Invokeが警告を発生させないことを検証済み（Debug/Release両方で合格）

#131021 [mono][wasm] Fix pinvoke with 64-bit enum argument

概要

WebAssembly上のMono interpreterにおいて、64ビット基礎型を持つenumをP/Invokeの引数として渡す際のクラッシュを修正。interp_type_as_ptr()がenumの基礎型を確認せずにすべてのenumをポインタサイズ互換として扱っていたため、call_indirectのシグネチャ不一致エラーが発生していました。

修正後、以下のようなコード例が正常に動作します：

[Flags] enum Flags : ulong { /* ... */ }
[DllImport("native")]
static extern void ProcessFlags(Flags flags);  // 64ビット値を正しく渡すことが可能に

変更内容

  • interp/transform.c: interp_type_as_ptr()関数の修正。64ビット基礎型（I8/U8）を持つenumに対して、基礎型の判定にフォールバックするロジックを追加。他のwidth（enum:int/enum:uintなど）のenumや64ビットホスト上のenumの動作は変更なし。
  • AbiRules.cs: enum:ulongおよびenum:longのP/Invoke呼び出しテストケースを追加。
  • wasm-abi.c: 64ビット整数の受け渡しに対応したネイティブ関数を追加。
  • PInvokeTableGeneratorTests.cs: 新しいenum型のABI出力に対する検証アサーションを追加。

パフォーマンスへの影響

影響なし。この修正は正確なシグネチャマッチングを確保するもので、パフォーマンスクリティカルなパスには変更がありません。

関連Issue

#112262

その他

  • 修正の対象は32ビットターゲット（wasm32など）上の64ビット基礎型enumのみで、既存のworkaround（enumをulongにキャストする）が不要になります。
  • AOT compiler（type_to_c）とjiterpreterの署名パスは既にenumを基礎型に展開しているため、並行する変更は不要。
  • 修正は interp_type_as_ptr（interpreter-transform限定）のロジック改善であり、公開APIへの影響はありません。

#131020 [mono][wasm] Fix AOT + BlazorWebAssemblyLazyLoad startup crash

概要

AOT (Ahead-of-Time) コンパイルされた Blazor WebAssembly アプリが BlazorWebAssemblyLazyLoad を使用する場合のランタイム起動時のクラッシュを修正します。根本原因は、AOT イメージが起動時にすべての参照アセンブリをロードしようとするため、遅延ロードされるアセンブリが見つからず、フォールバック処理で interp.c のアサーション失敗が発生していました。修正では、AOT + 遅延ロード条件下で aot-lazy-assembly-load ランタイムオプションを自動的に有効化し、アセンブリのバインディングを実際のロード時点まで遅延させます。

変更内容

  • Microsoft.NET.Sdk.WebAssembly.Browser.targets: RunAOTCompilation=true かつ BlazorWebAssemblyLazyLoad アイテムが存在する場合、--aot-lazy-assembly-load をランタイムオプションに自動追加（+6 行）
  • LazyLoadingTests.cs: AOT + リリースビルド + 遅延ロード構成を検証する LoadLazyAssemblyWithAOT テストを追加（+22 行）

修正は WebAssembly SDK のビルドターゲット内で行われ、runtimeOptions → mono_wasm_parse_runtime_options → mono_options_parse_options を通じてランタイムに流れます。非 AOT・非遅延ロードビルドは影響を受けません。

パフォーマンスへの影響

影響なし。本修正は起動時のクラッシュ回避を目的とした機能有効化であり、パフォーマンスの最適化ではありません。

関連Issue

#125794

その他

  • 修正前：module WasmBasicTestApp is unusable because dependency Json is not found → interp.c:4135 アサーション失敗
  • 修正後：AOT イメージが正常にロードされ、遅延ロードされたアセンブリが実行時に正しく機能することを確認
  • 既存の LazyLoadingTests はインタプリタ（Debug）構成のみをカバーしていたため、新テストにより AOT + 遅延ロード経路のリグレッション防止が実現されます

#131017 Link statically to GrowableFunctionTable

概要

Windows x64のアンワインド情報公開処理をリファクタリングし、RtlAddGrowableFunctionTableなどのWindows 8+API を直接呼び出すように変更しました。従来の動的なGetProcAddressベースの関数発見を廃止し、リンク時にntdll.libから直接シンボルを解決するようにしています。

変更内容

  • src/coreclr/vm/codeman.cpp: 動的関数ポインタ初期化ロジックを削除（約87行削減）し、RtlAddGrowableFunctionTable、RtlGrowFunctionTable、RtlDeleteGrowableFunctionTableを直接呼び出すように変更
  • src/coreclr/vm/codeman.h: UnwindInfoTable::Initialize()宣言を削除
  • src/coreclr/vm/ceemain.cpp: 起動時のUnwindInfoTable::Initialize()呼び出しを削除
  • src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt: Windows ビルドにntdll.libをリンク対象に追加

パフォーマンスへの影響

影響なし（ランタイムコスト削減）。起動時の動的関数発見処理が不要になり、わずかな初期化オーバーヘッド削減が期待されます。

関連Issue

なし

その他

  • Windows 8以上が対象環境であり、RtlAddGrowableFunctionTableAPIはWindows 8で導入されたため、互換性上の問題はありません
  • この変更は内部実装（CoreCLRランタイムのアンワインド情報管理）の最適化であり、公開APIへの影響はありません
  • NativeAOTのWindowsAPI許可リストに含まれているため、適切な対応と判断されています

#130966 Fix linux-musl-rsicv64 build

概要

Alpine Linuxの互換性確保のため、RISCV_HWPROBE_EXT_ZICONDマクロを定義するネイティブコード修正です。linux-musl-riscv64ビルドの問題を解決します。

変更内容

  • src/native/minipal/cpufeatures.c: RISCV_HWPROBE_EXT_ZICONDマクロ定義を追加（5行追加）

パフォーマンスへの影響

影響なし

関連Issue

#130966

その他

RISC-V CPU機能検出に関わるネイティブレイヤの変更で、Alpine Linux環境でのビルド互換性向上を目的とした修正です。

#130960 [wasm] Html Encode incoming parameters to debug page

概要

WebAssemblyデバッグヘルプページへの受信クエリパラメータをHTML エンコードして、HTML/スクリプトインジェクションのリスクを軽減します。urlクエリパラメータとデバッガタブリスト URLを事前にエンコードし、エラー/ヘルプHTMLで再利用します。

変更内容

  • src/mono/wasm/host/DevServer/WebAssemblyNetDebugProxyAppBuilderExtensions.cs
    • クエリパラメータ由来の値をHTML生成前にエンコード処理を追加
    • エンコード済みの値をエラーメッセージとヘルプページで再利用

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

Copilotレビューで追加の懸念事項が指摘されています：

  • 例外メッセージもHTML エンコードなしでHTML内に埋め込まれている（<pre>{ex}</pre>）点が未対応です。例外メッセージにユーザー制御値（ホスト/URL文字列など）が含まれる場合、XSS脆弱性となる可能性があります
  • HTMLマークアップの構文エラー（<strong>タグが</p>で閉じられている）も報告されています

#130957 Speed up Decimal32/64/128 arithmetic, conversions, and equality

概要

IEEE 754 decimal実装（Decimal32/Decimal64/Decimal128）の算術演算と変換処理を高速化するPRです。長除算の高速化、直接エンコーディング、浮動小数点変換の最適化、専用の等値性チェックルーチンなどを追加し、全体的なパフォーマンスを大幅に改善します。

変更内容

  • Number.DecimalIeee754.cs: 以下の高速パス機構を追加

    • Divide: 剰余の先頭ゼロ数に基づいて複数桁を一度に抽出（従来は1桁ずつ）
    • FromInt32: 係数がすでに範囲内の場合は直接エンコード
    • FromDouble: Dragon4で正確にPrecision有効桁数を出力し、単一ラウンドで変換（二重丸めを排除）
    • ToDouble: 浮動小数点パーサから抽出したTryFloatingPointBitsFromMantissa（Clinger + Eisel-Lemire）を再利用
    • Equality: ビット完全一致の短絡評価と除数ベースの同等性チェックで専用最適化

  • Number.NumberToFloatingPointBits.cs: TryFloatingPointBitsFromMantissaヘルパーを抽出・共有化

  • Decimal32/64/128.cs: 調整済み指数インターフェースプロパティを実装

パフォーマンスへの影響

大幅な高速化を達成（ローカルマイクロベンチ、ns/op、小さいほど良い）：

Method D32改善 D64改善 D128改善
Add 12.4→7.0 (-44%) 16.4→8.3 (-49%) 61.5→29.4 (-52%)
Subtract 13.1→7.7 (-41%) 17.1→8.9 (-48%) 63.5→31.2 (-51%)
Multiply 15.1→12.8 (-15%) 40.5→14.6 (-64%) 58.3→40.0 (-31%)
Divide 30.1→21.4 (-29%) 74.3→20.5 (-72%) 417.7→109.0 (-74%)
FromInt32 74.3→1.8 (-98%) 74.2→1.9 (-97%) 78.6→5.8 (-93%)
FromDouble 314→76.8 (-76%) 314→125.5 (-60%) 338→291.7 (-14%)
ToDouble 102.6→5.8 (-94%) 129.2→6.8 (-95%) 137.0→19.2 (-86%)

懸念: Decimal128等値性で若干の退行（19→22 ns）が見られますが、原因は周辺コードのコード生成レイアウト変動で、他の大幅改善（例：Divide -309 ns、ToDouble -118 ns）によって補われます。

関連Issue

なし

その他

  • 検証済み：Decimal32/64/128 xunitスイート4482テスト（Intel BIDリファレンスベクトル含む）、Double/Single/Halfパーサテスト合格
  • FromDouble差分テスト：790万個のランダムダブルと完全一致（値ミスマッチ0件

#130928 Clean up redundant defines and warning suppressions in coreclr/vm/common.h

概要

CoreCLR の vm/common.h から冗長/陳腐なプリプロセッサ定義と MSVC 警告抑制ブロックを削除し、複数の stdafx.h ファイルから未使用の定義を削除するコード整理です。警告抑制に依存していた2つの呼び出し位置（gchelpers.cpp、olevariant.cpp）は、名前付きローカル変数を導入して対応しており、機能的な変更はありません。

変更内容

  • src/coreclr/vm/common.h: MSVC警告抑制ブロック（#pragma warning(disable:...)）を削除。意味のある警告（4201, 4100, 4127, 4245, 4291, 4505）は既に eng/native/configurecompiler.cmake で全体適用済み。
  • src/coreclr/vm/gchelpers.cpp: C4238警告（rvalueをlvalueとして使用）の抑制に依存していた箇所に名前付き OBJECTREF ローカル変数を導入。
  • src/coreclr/vm/olevariant.cpp: 同様に memcpyNoGCRefs 呼び出し前に名前付き DECIMAL ローカル変数を導入。
  • 各 stdafx.h ファイル: USE_COM_CONTEXT_DEF と _CRT_DEPENDENCY_ 定義を削除（src/coreclr 内に参照なし）。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 内部実装（ランタイム VM レイヤー）の整理であり、公開APIには影響しません。
  • 破壊的変更なし。

#130905 Cleanup multicast delegate handling

概要

マルチキャストデリゲートの内部実装をリファクタリングし、呼び出しリストの保存形式を object[] から Delegate.Wrapper[] に変更します。これにより、型安全性を向上させ、combine/remove パスを簡潔にし、VM側の呼び出しスタブ生成を更新します。

変更内容

  • Delegate.CoreCLR.cs: マルチキャスト呼び出しリスト保存を Wrapper[] に変更。TryGetInvocations、GetInvocationList、Target、GetMethodImpl、CombineImpl、RemoveImpl などのメソッドを Wrapper[] ベースに更新し、Span を活用した実装に刷新（+135行/-207行）
  • comdelegate.cpp: VM側マルチキャスト呼び出しILスタブの生成を更新。Wrapper[] から ldelema + ldfld Value で実際のデリゲートをロードするように変更（+2行/-1行）
  • corelib.h: System.Delegate+Wrapper 型と Wrapper.Value フィールドの CoreLibBinder エントリを追加（+3行）

パフォーマンスへの影響

影響なし（リファクタリングにより型安全性向上と可読性改善が主目的）

関連Issue

なし

その他

  • 前のPRに基づくビルド（継続的なマルチキャストデリゲート最適化の一環）
  • 公開API自体には変更なく、内部実装（CoreCLRランタイム）のクリーンアップ
  • object[] キャストへの依存を削減し、型安全性を強化

#130761 Add openbsd-x64 CI leg

概要

OpenBSD x64プラットフォームのCI環境を追加するための変更です。既存のCI/CDパイプライン構成を拡張して、OpenBSD x64ターゲットのビルドとテストを実行できるようにします。

変更内容

  • eng/pipelines/common/platform-matrix.yml: OpenBSD x64プラットフォームの定義を追加（+20行）
  • eng/pipelines/common/templates/pipeline-with-resources.yml: パイプラインリソース設定にOpenBSD x64対応を追加（+5行）
  • eng/pipelines/common/templates/runtimes/xplat-job.yml: クロスプラットフォームジョブ設定を更新（+2行）
  • eng/pipelines/common/xplat-setup.yml: セットアップスクリプトを調整（+2/-2行）
  • eng/pipelines/coreclr/templates/sccache-stats.yml: キャッシュ統計設定を更新（+1/-1行）
  • eng/pipelines/coreclr/templates/setup-sccache.yml: キャッシュセットアップを更新（+1/-1行）
  • eng/pipelines/runtime.yml: ランタイムパイプラインに新しいジョブを追加（+1行）

パフォーマンスへの影響

影響なし（CI インフラストラクチャの追加で、ランタイムパフォーマンスへの直接的な影響なし）

関連Issue

#124911

その他

なし

#130435 Preserve checked overflow for unsigned range additions

  • 作成者: @Copilot
  • 作成日時: 2026年07月09日 21:20:55(UTC)
  • マージ日時: 2026年07月19日 14:15:49(UTC)
  • ラベル: area-Infrastructure

概要

JIT範囲分析において、符号なし加算のオーバーフロー検査が誤って削除される問題を修正しました。JIT範囲が符号付き区間を使用しているため、Tier 1のアサーション伝播が符号なし加算の検査条件を不正に削除していました。

変更内容

  • rangecheck.h: 符号なし範囲が符号付きゼロを跨がるケースを拒否し、合計値が符号付き範囲モデルで表現可能なままであることを保証する条件を追加（+17/-1）
  • Runtime_130431.cs: 報告されたチェック済み加算失敗と符号跨ぎ範囲に対する回帰テストを追加（+40/-0）
  • Regression_ro_2.csproj: テストプロジェクト設定を更新（+1/-0）

パフォーマンスへの影響

影響なし

関連Issue

#130431

その他

このコミットは符号なし整数型におけるcheckedキーワード付き加算でのオーバーフロー例外の正確性を改善するものです。JITの範囲分析アルゴリズムが符号付き・符号なし型の混在を扱う際の境界条件を正しく処理するようになりました。

#130339 Add scheduled holistic reviews for all PRs and path-specific review instructions

  • 作成者: @jeffhandley
  • 作成日時: 2026年07月08日 08:45:41(UTC)
  • マージ日時: 2026年07月19日 02:42:17(UTC)
  • ラベル: area-skills

概要

dotnet/runtimeのコードレビュー自動化をスケジュール型オーケストレータ+ワーカー型の設計に再構築し、レビュールールをパス固有の .github/instructions/ ファイルに分離します。これにより、カスタム Holistic Review ワークフローと GitHub 組み込み Copilot コードレビューが同一のルールセットを共有できるようになります。従来の pull_request トリガー型から、10分単位でスケジュール実行される deterministic オーケストレータが必要な PR を選定し、dispatch する per-PR ワーカー（workflow_dispatch ベース）に移行します。

変更内容

  • holistic-review-orchestrator.yml（新規）：スケジュール実行される deterministic オーケストレータ。10分ごとに非Draft PR をポーリングし、新規またはヘッドコミットが変更された PR に対してワーカーを dispatch。フォークではスケジュール実行をスキップ。
  • holistic-review.md（新規）：workflow_dispatch ベースの agentic ワーカー。初回レビューは完全な merge_base..head 範囲を分析、再レビューは range-diff/patch-diff を使用した差分スコープで実行。最大10個のインライン comments と1つの COMMENT イベント review のみを submit（APPROVE/REQUEST_CHANGES は非実装）。
  • path-scoped instruction ファイル群（新規）：
    • review-all-src.instructions.md (src/**)：PR 全体評価、コード再利用、規約
    • review-csharp.instructions.md (**/*.cs)：C# エラーハンドリング、スレッド安全性、セキュリティ、パフォーマンス
    • review-native.instructions.md (C/C++/asm)：JIT 正確性、VM 規約、P/Invoke marshalling
    • review-all-tests.instructions.md (test globs)：テスト規約
    • review-core-runtime.instructions.md (src/coreclr/**,src/native/corehost/**)：CoreCLR 固有の規約
  • SKILL.md（修正）：従来のインライン review ルールを削除し、上記 instruction ファイルへのポインタに置き換え（-262行 → +28行）。
  • .github/aw/actions-lock.json（修正）：actions/cache/restore@v4 と actions/cache/save@v4 をピン留め追加。

パフォーマンスへの影響

影響なし（コードレビュー自動化ツールの設定変更であり、ランタイムやコンパイラのパフォーマンスに直接的な影響なし）

関連Issue

なし

その他

  • セキュリティ設計：オーケストレータは actions: write / pull-requests: write に制限。ワーカーは contents: read, issues: read, pull-requests: read のみで、安全な出力層経由で review/comment。PR コンテンツを信頼できない入力として扱い、.github 全体や configuration ファイルを main から復元後に読み込み。
  • 状態管理：各 PR の managed issue comment に JSON 状態を保持（version 5）。最後の dispatch/review の commit/base SHA、ワーカー実行 ID、再試行回数を記録。再試行上限は `MAX_REVIEW

#128498 Migrate eng/pipelines from PublishBuildArtifacts to PublishPipelineArtifact

  • 作成者: @mmitche
  • 作成日時: 2026年05月22日 18:15:42(UTC)
  • マージ日時: 2026年07月19日 08:25:27(UTC)
  • ラベル: area-Infrastructure

概要

Azure Pipelines のeng/pipelines/配下において、レガシーな Build Artifacts（PublishBuildArtifacts@1 / DownloadBuildArtifacts@0）から Pipeline Artifacts（PublishPipelineArtifact@1 / DownloadPipelineArtifact@2）への移行。Pipeline Artifacts はデデュプベースのアップロードで、レガシー Build Artifacts に比べて10～100倍高速化され、エージェント時間を削減してプール圧力を軽減します。

変更内容

  • Publish ラッパー: publish-build-artifacts.yml の PublishBuildArtifacts@1 → PublishPipelineArtifact@1 に置き換え、入力パラメータ名をPathtoPublish → targetPath等に更新
  • アーティファクト命名戦略:
    • 診断アーティファクト（ログ、binlog等）は _Attempt$(System.JobAttempt) をサフィックスして再試行時の衝突を回避
    • 下流ジョブが消費する中間アーティファクトは安定名（Attempt サフィックスなし）を使用し、succeeded() 時のみ公開
  • パフォーマンステンプレート: build-perf-*.yml の binlog パブリッシュステップを Pipeline Artifacts に移行（_Attempt サフィックス付与）
  • ダウンロード: download-artifact-step.yml / download-specific-artifact-step.yml / ブラウザ WASM テストテンプレートを DownloadPipelineArtifact@2 に移行
  • WASM: wasm-post-build-steps.yml の2つの直接呼び出しを移行、下流消費用に安定アーティファクト名を保持

パフォーマンスへの影響

Pipeline Artifacts はデデュプベースのアップロード実装により、レガシー Build Artifacts 比で10～100倍高速。エージェント時間削減によりエージェントプール圧力軽減と全体スループット向上が期待される。

関連Issue

なし

その他

  • eng/common/ ファイルは Arcade により管理されているため変更対象外
  • SuperPMI/libraries テンプレートの enablePublishBuildArtifacts: true パラメータはパラメータ名のみで、既に Arcade ラッパーにより _Attempt サフィックス付きで処理される

#128205 ci: declare contents:read on jit-format workflow

概要

.github/workflows/jit-format.yml ワークフローにおいて、セキュリティ強化を目的として permissions: contents: read を宣言します。このワークフローは .NET と Python のセットアップ、JIT フォーマットスクリプトの実行、format.patch アーティファクトのアップロードを行いますが、GitHub API への書き込みアクセスを必要としないため、読み取り権限のみに制限することで、万が一 GITHUB_TOKEN が漏洩した場合の被害範囲を最小化します。

変更内容

  • .github/workflows/jit-format.yml: ワークフローレベルで permissions: contents: read を追加（+3/-0）

パフォーマンスへの影響

影響なし

関連Issue

CVE-2025-30066 に関連する防御強化（2025年3月の tj-actions/changed-files サプライチェーン攻撃を背景とした対策）

その他

  • このワークフローはアーティファクトのアップロード（actions/upload-artifact）を行いますが、これはワークフロー実行自体のスコープ内の操作であり、GitHub API への書き込みを必要としません
  • YAML は yaml.safe_load で検証済み
  • 複数の actions/* および actions/setup-* の依存関係がある中で、最小権限の原則（Least Privilege）を適用する防御型戦略です
  • ワークフローレベルでの権限宣言により、リポジトリまたは組織のデフォルト設定の変更による影響から保護され、OpenSSF Scorecard の Token-Permissions チェックの対象要件を満たします

#126187 Reduce unsafe code in System.Decimal

概要

System.Decimalのunsafeコード使用量を削減し、安全な等価物で置き換える。decimal等値比較（Equals、==、!=）を新しいDecCalc.Equals高速パスでルーティングし、IFloatingPoint<decimal>.TryWriteSignificand*Endianのunsafeなアンアライン書き込みをBinaryPrimitives.Write*Endianで置き換える。変更はすべてパフォーマンス中立またはパフォーマンス改善。

変更内容

  • System/Decimal.cs: decimal等値比較をDecCalc.Equalsに統一、significand書き込みをBinaryPrimitivesへ移行、数値ヘルパーのロジック簡略化
  • System/Decimal.DecCalc.cs: DecCalc.Equals導入、ポインタベースの除算ヘルパー削除、指数抽出ヘルパーをBiasedExponentに統一、内部バッファ構造体をunsafeキャスト/ポインタ回避のようにリファクタリング
  • System/Number.Parsing.cs: 軽微な変更（3行）
  • System/UInt128.cs: 軽微な変更（1行）

パフォーマンスへの影響

パフォーマンス中立またはパフォーマンス改善。残りのunsafeコード削減ケースはより複雑であり、詳細なパフォーマンス測定が必要とのこと。

関連Issue

#126187

その他

PR作成者によれば、より複雑なunsafeコード削減ケースについては、パフォーマンス低下をオフセットするための工夫が必要。本PRは低リスクで削除可能なunsafeパターンに焦点を当てている。

#125872 Avoid SocketException flood in NamedPipeClientStream on Unix

概要

Unix上でNamedPipeClientStream.Connect()が存在しないパイプへの接続を試みる際、リトライループ内で大量のSocketExceptionが発生・キャッチされる問題を修正しました。Statシステムコールでパイプファイルの存在確認を事前に行い、ENOENTエラーの場合はSocket割り当て前に即座にfalseを返すことで、例外フローディングとCPU浪費を削減します。

変更内容

  • NamedPipeClientStream.Unix.cs: TryConnectメソッドの先頭にInterop.Sys.Statによる存在確認ガードを追加。ファイルが存在しない場合（ENOENT）はSocket割り当てなしでfalseを返却。権限エラー（EACCES）その他の条件は既存のsocket.Connectパスを使用し、例外動作を保持
  • NamedPipeTest.Specific.cs: 新規Unix固有テストClientConnect_PipeNotFound_DoesNotFloodFirstChanceExceptionsを追加。存在しないパイプへの接続時、500ms間でSocketExceptionが5件未満であることを検証

パフォーマンスへの影響

改善あり：

  • 非存在パイプへの接続試行時、従来は数百〜数千のSocketExceptionが発生していたのに対し、新実装では5件未満に削減
  • Stat呼び出しのオーバーヘッドは軽微（システムコール1回）で、例外割り当てと比較して大幅にコスト削減
  • CPU浪費（FirstChanceExceptionハンドラの過度な呼び出し）を防止

関連Issue

#117718

その他

TOCTOU（Time of Check, Time of Use）ウィンドウが導入されますが、Statチェック後に次のリトライループ反復までの間にパイプファイルが作成された場合でも、ConnectInternalのポーリングループで次回リトライ時に検出されるため、例外フローディングは再発生しません。既存のClientConnect_Throws_Timeout_When_Pipe_Not_Foundテストにより、タイムアウト時のTimeoutException動作は変更なく維持されることを確認済みです。

目次