Pull Request on 2026年10月19日

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

注意点

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

目次

  1. #136094 Prevent unsafe folding of method-specific self imports in Wasm R2R
  2. #136085 JIT: Exclude byref-like structs from async continuation capture
  3. #136084 Fix InsertScalarFromVectorDisasm in no-intrinsics runs
  4. #136083 [release/11.0] Preserve ARM64 flags dependencies during indirection reordering
  5. #136082 [release/11.0] Report byref-like struct arguments to the GC in helper-based tail calls
  6. #136080 [release/11.0] JIT: Make GenTree::Compare more conservative around several node types
  7. #136079 [release/11.0] JIT: Use local's GC type when unspilling a register candidate
  8. #136077 [release/11.0] Filter leading GC polling frames from EventPipe stacks.
  9. #136043 JIT: clear BBF_DONT_REMOVE on the new preheader in loop inversion
  10. #136029 Fix ILVerify endfinally check for nested regions
  11. #136022 Queue RevocationResponder work items to the global thread pool queue
  12. #136002 ILC: make IsAsyncCall instantiation-invariant
  13. #135999 fold more redundant nullchecks
  14. #135989 Document ILVerify.Verifier thread safety, PEReader lifetime and the rest of the public API
  15. #135987 [release/11.0] Allow uncontended synchronous waits on single-threaded runtimes
  16. #135972 Keep corerun host-runtime contract state alive for the process lifetime
  17. #135954 Preserve NativeAOT WASI numeric exit codes
  18. #135949 Require matching WASM function types when folding method bodies
  19. #135941 Serialize HTTP/2 loopback writes and join reader before disposal
  20. #135940 Synchronize WebSocket keep-alive timeout test with heartbeat completion
  21. #135939 [Interpreter] Raise a pending thread abort again at the resume point after a catch
  22. #135932 Managed ilasm: keep invalid LocalScope/LocalVariable rows and report them as errors
  23. #135929 [release/11.0] Swallow ObjectDisposedException when restoring blocking mode after connect async
  24. #135921 Validate pcMap, not pcClauses, in CordbReJitILCode::GetInstrumentedILMap
  25. #135915 Do not adjust wasm virtual IPs in the thread abort stack walk
  26. #135906 crossgen2: allow struct/unmanaged-constrained generics over primitives in the version bubble
  27. #135900 [release/11.0] Exclude mobile targets from Helix dump-doc generation
  28. #135862 [QUIC] Remove buffer-size payload
  29. #135820 [CI] Prune Roslyn caches before saving snapshots
  30. #135806 Eagerly resolve intrinsic ReadyToRun type handles and arrays
  31. #135804 Treat Wasm Vector<T> layout as fixed
  32. #135801 Recognize static field intrinsics before Wasm static helpers
  33. #135797 Fix background GC zeroing of arrays larger than 4 GiB
  34. #135790 Return generated GUIDs by value
  35. #135777 [release/11.0] [EventPipe] Align EventPipeThreadSamplingRate parsing on CoreCLR and NativeAOT
  36. #135768 Absolute/global addressing changes for native AOT/WASM
  37. #135749 Update MsQuic to version 2.5.12
  38. #135748 Improve tar symlink validation during extraction
  39. #135734 Make TryGetSymbol cross-os
  40. #135733 Merging internal commits for release/8.0
  41. #135728 Merging internal commits for release/9.0
  42. #135700 Fix TlsSession's ClientHello peek failure message
  43. #135626 Fix GNU sparse 1.0 maps spanning multiple TAR records
  44. #135449 Zero-initialize the return-value range in the Leave2 slow path
  45. #135219 Filter leading GC polling frames from EventPipe stacks.
  46. #135167 Enable Unix domain sockets on iOS and tvOS
  47. #134987 Check the RESOLVE_UPDATE_METADATA_1 result hr in CordbModule::RefreshMetaData
  48. #125304 Use ICollection<T> check instead of IList<T> in TryCopyTo

#136094 Prevent unsafe folding of method-specific self imports in Wasm R2R

  • 作成者: @radekdoulik
  • 作成日時: 2026年10月19日 17:28:23(UTC)
  • マージ日時: 2026年10月19日 20:47:20(UTC)
  • ラベル: area-ReadyToRun

概要

ブラウザ/CoreCLR 向け Wasm ReadyToRun (R2R) のメソッド本体の重複排除（folding）で、メソッド固有のインポートセルを選択する自己リロケーションが正規化され、誤ったメソッドに処理が振り向けられる問題を修正します。WASM_MEMORY_ADDR_REL_LEB は、delegate 構築ヘルパーや仮想呼び出しのインポートセルをイメージ相対でロードする際に使われるため、異なる自己ターゲットを正規化すると不正な折りたたみが起きます。このリロケーションを、すでに保護されている符号付き形式と同様に「同一性を露出するもの（identity-exposing）」として分類するようにしました。

変更内容

  • src/coreclr/tools/Common/Compiler/ObjectWriter/WasmFunctionBodyDeduplicator.cs（+2/-1）: WASM_MEMORY_ADDR_REL_LEB を identity-exposing なリロケーションとして扱うよう変更。incoming-PEP 最適化、funclet 保護、既存の folding チェックは維持。
  • src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs（+33/-0）: 最適化有効の実 crossgen2 を用いた回帰テストを2件追加（明示的な self-delegate の .Method、仮想 self-slot フォワーディング）。安全な本体は引き続き定義を共有しつつ、論理テーブルスロットは別々に保たれることも検証。
  • src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/Webcil/WasmWebcilModule.cs（+24/-0）: 上記テスト用のフィクスチャを追加。

テストは既存の PR 時 browser clr.r2rtests レーンで実行され、パイプライン変更はありません。

パフォーマンスへの影響

実行速度のスループットに関する主張はなく、コードサイズ／コード生成面の影響のみが示されています。正しさのために重複排除が一部無効化されるため、サイズはわずかに増加します（同一入力・未トリム状態でのライブラリコンパイル比較）。

モジュール 関数定義数 モジュールサイズ（bytes） 論理テーブルスロット
System.Linq.Queryable 286 → 292 262,645 → 265,963（+3,318、1.26%） 320（変化なし）
System.Private.Xml 11,927 → 11,928 10,710,292 → 10,710,509（+217、0.0020%） 13,964（変化なし）

これは Queryable で6件、XML で1件の定義が、正しさのために復元されたものです。保持される正規本体はバイト単位で同一です。

関連Issue

#136093（Resolves）

その他

  • 検証（macOS/arm64 ホスト、browser/CoreCLR Release）:
    • 修正前は clr.r2rtests で 132 件パス、新規2件のみ失敗、39 件スキップ。修正後は 134 件パス、失敗 0、スキップ 39。
    • 同一フィクスチャ・同一 IL の実行ファイルを Node 上のブラウザ CoreCLR で実行したところ、修正前 6/12、修正後 12/12 のチェックにパス（DOTNET_ReadyToRun=0 のインタープリタ対照も 12/12）。
    • トリム済み R2R アプリを headless Chrome で実行: System.Linq.Queryable.Tests は 1,498 件パス（失敗/スキップ 0）、System.Private.Xml.Tests は 48,713 件パス（失敗 0、スキップ 68）。従来失敗していた 22 テスト（Average の全 70 ケースを含む）も個別にパス。
  • この PR は GitHub Copilot により作成されました。

#136085 JIT: Exclude byref-like structs from async continuation capture

概要

JITのasync continuation capture（async関数のサスペンドポイントをまたぐローカル変数の退避）において、byrefを含まないbyref-like struct（ref struct）も退避対象から除外するよう修正しています。これらの構造体を退避すると、レイアウトがスタック専用とみなされているためwrite barriersなしでヒープへのストアが生成され、continuationの再利用時にGC corruptionを引き起こす問題（#136000）を修正します。

runtime-asyncの仕様には「Byref-like structs will also not be hoisted across suspension points and will have their default value after a suspension point.」と明記されており、この修正は仕様に沿ったものです。

変更内容

  • src/coreclr/jit/asyncanalysis.cpp（+3/-2）: async continuationへのcaptureから除外する対象を、byrefを含むbyref-like structだけでなく、byrefを含まないものにも拡張（JIT内部の実装変更で、公開APIへの変更なし）
  • src/tests/JIT/Regression_ro_2/Runtime_136000.cs（+57/-0）: #136000の回帰テストを追加

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載もなし）

関連Issue

その他

  • 作成者は、仕様上禁止されているものの、将来的にはこれらの構造体のcaptureを許可できる可能性にも触れています。その場合、async-v2の文脈で「ref structはwrite barrier不要」というJITの前提を見直す変更が必要になります。
  • 今回は仕様の記述に従い、保守的に除外する対応が取られています。

#136084 Fix InsertScalarFromVectorDisasm in no-intrinsics runs

  • 作成者: @Copilot
  • 作成日時: 2026年10月19日 12:03:27(UTC)
  • マージ日時: 2026年10月19日 21:10:19(UTC)
  • ラベル: area-Infrastructure

概要

jitstress_isas_nohwintrinsic 構成下で InsertScalarFromVectorDisasm テストが失敗する問題の修正です。この構成ではintrinsic認識が無効化されるため、テストが期待する insertps のソースレーン畳み込みが行われませんでした。そこで、テスト専用の設定として DOTNET_EnableHWIntrinsic=1 を指定し、厳密な逆アセンブリ検証をそのまま維持します。

変更内容

  • src/tests/JIT/opt/Vectorization/InsertScalarFromVectorDisasm.csproj: テスト用プロジェクトに DOTNET_EnableHWIntrinsic=1 を設定する1行を追加（+1/-0）。このプロジェクトはすでに他のテストから分離されています。

パフォーマンスへの影響

影響なし（テスト構成のみの変更で、ランタイム/JITの実装や公開APIへの変更はありません）。

関連Issue

#136048

その他

  • 変更はテストプロジェクトの環境設定に限られ、互換性への影響はありません。
  • テストの期待値（insertps の逆アセンブリチェック）は緩和されていません。

#136083 [release/11.0] Preserve ARM64 flags dependencies during indirection reordering

概要

release/11.0 向けのバックポート（main の #135575）です。ARM64 で間接参照（indirection）やストアの並べ替え、およびポストインデックス・アドレッシングを行う際に、暗黙のフラグ依存関係が保持されず、アロケーション後に符号付き剰余の結果が誤って計算される問題（Issue #135521）を修正します。例として、非負の奇数値に対する k % 2 が -1 を返すケースがあります。

変更内容

  • src/coreclr/jit/lower.cpp（+3/-1）: 並べ替え時に暗黙のフラグ依存関係を保持するよう変更
  • src/coreclr/jit/lowerarmarch.cpp（+3/-1）: ARM64 のストア並べ替えとポストインデックス・アドレッシングで、同様にフラグ依存関係を保持するよう変更
  • src/tests/JIT/Regression/JitBlue/Runtime_135521/Runtime_135521.cs（+67/-0）: 回帰テストを追加（release ブランチ既存のマージ済みランナー向けに調整）
  • src/tests/JIT/Regression/Regression_ro_2.csproj（+1/-0）: 上記テストをプロジェクトに追加

パフォーマンスへの影響

影響なし（記載された情報の範囲では、パフォーマンスに関する言及はありません）。暗黙のフラグ依存関係をまたぐ並べ替えを抑止するのみで、リスクは低いとされています。

関連Issue

#135521（main 側の修正 PR: #135575）

その他

  • 顧客報告の問題です。.NET 10 で誤った結果が報告されており、根本原因の命令順序バグは .NET 9 にも存在します。.NET 11 で導入された回帰ではありません。
  • 作成者によるリスク評価は「低」で、フラグ依存関係をまたぐ並べ替えを防ぐだけの変更とされています。
  • テストは追加済みです。

#136082 [release/11.0] Report byref-like struct arguments to the GC in helper-based tail calls

概要

release/11.0 への #136019（main）のバックポートです。ヘルパーベースの tail call で引数をバッファリングする際、byref-like 構造体（例: Span<T>）を GC 記述子に含めるよう修正します。 修正前は、Span<T> を引数に取るヘルパーベース tail call の最中に GC が基になる配列を移動すると、メモリ破損・誤った結果・ハング・致命的クラッシュが起こり得ました（F# / Windows x64 で報告）。

変更内容

  • src/coreclr/vm/tailcallhelp.cpp（+2/-1）: tail call 引数バッファ用の GC 記述子生成時に、byref-like 構造体を含めるように変更。既存の byref-like 構造体用 GC レイアウト処理を利用しています。
  • src/tests/JIT/Regression/JitBlue/Runtime_136010/Runtime_136010.il（+117）: 回帰テスト（IL）を追加。release ブランチ既存のマージ済みランナーに配置されています。
  • src/tests/JIT/Regression/JitBlue/Runtime_136010/Runtime_136010.ilproj（+9）: 上記テストのプロジェクトファイルを追加。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載はありません）。

関連Issue

#136010 main ブランチの修正 PR: #136019

その他

  • 顧客報告の問題です。リグレッションではなく、.NET 8、9、10 でも再現します。
  • リスクは Low と評価されています（既存の byref-like 構造体用 GC レイアウト処理を使用するため）。
  • 公開 API の変更や互換性への影響についての記載はありません。

#136080 [release/11.0] JIT: Make GenTree::Compare more conservative around several node types

概要

GenTree::Compare を、複数のノード種別に対してより保守的に比較するよう変更し、head/tail merging が誤って異なるツリーを同一と見なさないようにします。main の #135363 の release/11.0 へのバックポートです。

修正前は、JIT が同一オフセットにある別々のフィールドへのアクセスをマージし、その結果として型チェックを誤って除去することがありました。これにより Microsoft.CodeAnalysis を用いたコンパイル emit 中に、断続的な NullReferenceException が発生していました（顧客報告。.NET 10.0.12 で報告されており、.NET 11 固有の回帰ではありません）。

変更内容

  • src/coreclr/jit/gentree.cpp（+38/-19）
    • GenTree::Compare がフィールドの同一性（field identity）など、正しさに関わるノードのメタデータを考慮するよう変更。
    • 比較を保守的にするのみで、比較結果が「等しい」となる場面を減らす方向の変更です。

パフォーマンスへの影響

ベンチマーク結果等の記載はなく、パフォーマンスへの影響についての言及はありません。比較が保守的になるため、マージされるケースが減る可能性はありますが、具体的な影響は提供情報からは不明です。

関連Issue

その他

  • 対象は JIT（コンパイラ）の内部実装であり、公開 API や互換性（破壊的変更）への影響は記載されていません。
  • 回帰ではありません（Regression: No）。
  • テストはローカルテストのみ実施。
  • リスクは Low（ツリー比較をより保守的にするだけ）と評価されています。

#136079 [release/11.0] JIT: Use local's GC type when unspilling a register candidate

概要

release/11.0 への #135381 のバックポートです。JIT のコード生成で、レジスタ候補のローカル変数を unspill する際に、そのローカル自身の GC 型を使うよう修正します。あわせて、アンマネージ呼び出しの時点でコールee-saved レジスタが GC-live になっていないことを assert で検証します。

報告されている症状は、アンマネージ関数ポインタを使う COM 相互運用コード (Paint.NET のテストハーネスで確認) で、断続的に致命的な GC クラッシュが発生するというものです。

変更内容

  • src/coreclr/jit/codegenlinear.cpp (+2/-5): レジスタ候補を unspill する際に、ローカルの GC 型を使うよう変更。
  • src/coreclr/jit/codegenxarch.cpp (+4/-0): アンマネージ呼び出し時に、callee-saved レジスタが GC-live でないことを確認する assert を追加。
  • src/coreclr/jit/codegenarmarch.cpp (+4/-0): ARM/ARM64 向けにも同様の assert を追加。
  • src/tests/JIT/Regression/JitBlue/Runtime_135374/Runtime_135374.cs (+91/-0): 回帰テストを追加。リリースブランチの既存のマージ済みランナーに合わせて調整されています。
  • src/tests/JIT/Regression/Regression_ro_2.csproj (+1/-0): 上記テストをプロジェクトに登録。

パフォーマンスへの影響

影響なし (記載された情報では、パフォーマンスに関する変更や計測結果は示されていません)。

関連Issue

その他

  • 回帰かどうか: 作成者の説明では「Yes」とされています。根本原因の GC 追跡バグ自体はより古くからありますが、.NET 11 ではインライン化が増えたことでクラッシュが顕在化したとのことです。.NET 10 では再現しないとされています。
  • 顧客報告: 顧客報告の問題です。
  • リスク: 作成者は「低」と評価しています。ローカルの GC 型を使う方法は LSRA (線形スキャンレジスタ割り当て) の扱いと一貫しているためです。
  • テスト: 回帰テストが追加されています。

#136077 [release/11.0] Filter leading GC polling frames from EventPipe stacks.

概要

EventPipeのサンプリング（スレッド中断）時に、スレッドがマネージドのGCポーリングヘルパー（PollGC / PollGCWorker）内に入ることがあり、これがキャプチャされたスタックの先頭に現れて実際のワークロードを覆い隠す問題を修正するバックポート（release/11.0向け）です。PollGCWorkerをバインダーから参照可能にしてランタイム起動時にバインドし、EventPipeのスタックウォーカーが、メソッドのロードを行わずに先頭のGCポーリングフレームのみを除外できるようにします。呼び出し元フレーム、サンプル、サンプル分類は保持されます。main側のPR（#135219）を手動で調整したバックポートで、.NET 11向けのThread.CoreCLR.csとフィーチャーガードを使用しています。

変更内容

  • src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs: PollGCWorkerをバインダーから参照可能にする変更（+5/-3）
  • src/coreclr/vm/appdomain.cpp: ランタイム起動時にPollGCWorkerをバインドする処理を追加（+4）
  • src/coreclr/vm/corelib.h: PollGCWorkerのバインダー定義を追加（+3）
  • src/coreclr/vm/eventing/eventpipe/ep-rt-coreclr.cpp: EventPipeスタックウォーク時に先頭のPollGC/PollGCWorkerフレームを省略する処理を追加（+9/-1）
  • src/tests/tracing/eventpipe/eventsvalidation/SampleProfilerSampleType.cs: 回帰テストを追加（+211）。生のサンプルスタック、マネージドサンプル内のワークロードフレーム、通常のイベントスタック内のワークロードフレームの保持を検証

パフォーマンスへの影響

ランタイムの実行性能への影響に関する記載はありません。ただしCPUサンプリングプロファイルにおいて、ほぼ全サンプルがPollGCWorkerに帰属されてアプリケーションのワークロードが見えなくなる問題が解消されます（プロファイリング上のアーティファクトであり、同等のCPU使用率やGC負荷を示すものではないとされています）。GCポーリングやサスペンションのセマンティクスは変更されず、サンプルの破棄も行いません。

関連Issue

#135050（mainのPR: #135219）

その他

  • .NET 9から.NET 10へのリグレッションとして報告された問題で、GCポーリングがマネージドヘルパーに移った後に発生します。未修正の.NET 11ブランチでも再現します。
  • テスト結果（Windows x64、Checked CoreCLR + Release libraries）: 修正前はGCポーリングヘルパーがサンプル先頭に現れて終了コード101で失敗。修正後は終了コード100で成功し、12,606件のサンプルスタックを検証、ロストイベントは0でした。DOTNET_TieredCompilation=0でも既存のサンプル分類テストと新規回帰テストの双方が成功しています。
  • 他プラットフォームおよび.NET 10は未検証です。
  • リスクは低いとされています。変更の範囲はGCポーリングヘルパーの識別と、EventPipeスタックの先頭フレームである場合のみの除外に限定されています。ワーカーはマネージド実行前にバインドされるため、スタックウォーク中のメソッドロードを回避しています。

#136043 JIT: clear BBF_DONT_REMOVE on the new preheader in loop inversion

  • 作成者: @lewing
  • 作成日時: 2026年10月19日 01:05:34(UTC)
  • マージ日時: 2026年10月19日 23:07:53(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITのループ反転（loop inversion）で fgSplitBlockAtEnd により preheader を分割すると、新しい preheader が BBF_DONT_REMOVE フラグを継承してしまいます。旧 preheader が catch ハンドラのエントリであり、かつループ条件が後に false へ畳み込まれる場合、新ブロックは到達不能になりますが削除できません。

その結果、Wasm では古い bbPreorderNum が原因で fgWasmControlFlow の block order disagrees with preorder num に引っかかります。他のターゲットでは不要な int3/brk が出力されます。

本PRでは新しい preheader から BBF_DONT_REMOVE を明示的にクリアします。旧 preheader が EH エントリのまま残るため、この対応で問題ありません。fgopt.cpp の OSR エントリ処理と同様の方針です。

変更内容

  • src/coreclr/jit/optimizer.cpp（+5/-0）: ループ反転時に生成される新しい preheader の BBF_DONT_REMOVE をクリア
  • src/tests/JIT/Regression_ro_2/Runtime_136041.cs（+44/-0）: Runtime_136041 の回帰テストを追加

補足として、fgSplitBlockAtEnd 自体はフラグのコピーを維持する必要があります。ループの正規化（canonicalization）が try エントリ分割時にこの挙動に依存しているためです。

パフォーマンスへの影響

実行時のスループットやメモリへの直接的な影響に関する記載はありません。SuperPMI の diffs では、到達不能な dead throw の除去のみが確認されたとのことです（他ターゲットで出力されていた不要な int3/brk の削減に相当）。

関連Issue

#136041

その他

  • 影響範囲はランタイム内部（JITコンパイラ）の実装であり、公開APIや互換性への影響はありません。
  • 作成者によると、PR説明文は GitHub Copilot の支援で作成されています。

#136029 Fix ILVerify endfinally check for nested regions

概要

ILVerify が endfinally/endfault の発生位置を検証する際、最も内側の「ハンドラ」しか確認しておらず、finally/fault ハンドラの内側にネストされた try ブロックや filter 内にある endfinally/endfault を誤って有効と判定していた問題を修正します。ECMA-335 I.12.4.2.8.2.6 では「最も内側を囲む保護ブロック・filter・ハンドラが finally または fault ハンドラであること」と規定されています。

修正前は、以下のような IL が検証エラーなしで通っていました（endfinally の直近を囲むのは try ブロックであり、ハンドラではない）。

.finally
{
    .try
    {
        endfinally    // 最も内側を囲むのはこの try
    }
    catch [System.Runtime]System.Exception
    {
        pop
        leave HandlerEnd
    }
HandlerEnd:
    endfinally
}

endfault や、ネストした filter 内の命令でも同様でした。

変更内容

  • src/coreclr/tools/ILVerification/ILImporter.Verify.cs: ImportEndFinally において、基本ブロックが持つ既存の TryIndex / FilterIndex / HandlerIndex を使い、最も内側の try ブロックまたは filter が最も内側のハンドラの内側に存在する場合にも Endfinally エラーを報告するようにしました（+31/-1）。新しいエラーコードは追加していません。
  • src/coreclr/tools/ILVerification/Strings.resx / VerifierError.cs: 軽微な変更（各 +1/-1。内容の詳細は提供情報からは不明）。
  • src/coreclr/tools/ILVerification.Tests/ILTests/ExceptionRegionTests.il: テストを追加（+163）。
    • 無効ケース（いずれも Endfinally エラーを期待）: Finally.EndfinallyInNestedTry_Invalid_Endfinally、Finally.EndfinallyInNestedFilter_Invalid_Endfinally、Fault.EndfaultInNestedTry_Invalid_Endfinally、Fault.EndfaultInNestedFilter_Invalid_Endfinally
    • 有効ケース（エラーなし）: Finally.EndfinallyInFinallyInsideNestedTry_Valid（別の finally 内にネストされた try の中の finally 内の endfinally。直近を囲むのが finally であるため引き続き許可）

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）。検証時に既存のインデックス情報を参照する条件チェックが追加されるのみです。

なお作成者の検証では、実際の JIT の挙動として以下が確認されています（linux-x64、tiered compilation off）。

  • ネストした try 内の endfinally: .NET 8.0.26 / 9.0.15 / 10.0.9 / 10.0.12 / 11.0 preview 5, 7 で InvalidProgramException
  • ネストした filter 内の endfinally: 8.0.26 / 9.0.15 ではコンパイル・実行され、10.0.9 / 10.0.12 ではコンパイル中に SIGSEGV でクラッシュ、11.0 preview では InvalidProgramException

関連Issue

  • #124882（JIT の "Unexpected endfinally" チェックのタイプミスを main で修正。release/10.0 には残存）

その他

検証結果:

  • テスト結果: main 未変更で 508/508、本変更後は 513/513 パス（スキップなし）。
  • ミューテーション確認: 新条件を削除すると新規無効テスト 4 件が失敗（509/513）。try 側のみ/filter 側のみを無効化すると該当する 2 件のみ失敗（511/513）。
  • 実アセンブリでの回帰確認: .NET 10.0.12 共有フレームワークの 172 DLL と .NET 10.0.401 SDK の 97 DLL に対して、main ビルドと本変更ビルドの ILVerify を実行し、[IL]/[MD] エラー行が完全に一致（フレームワーク 84,245 行、SDK 14,042 行）。新チェックは 11,825 回実行され、うち 2,468 回は try ブロック内にネストされた finally ハンドラ内の命令でしたが、エラーは報告されませんでした。

作成者によると、本 PR は AI（Anthropic Claude、OpenAI Codex）の支援を受けて作成され、作成者がレビューしています。Copilot レビューは承認推奨で、未解決の指摘はありません。

#136022 Queue RevocationResponder work items to the global thread pool queue

概要

テスト用のループバックOCSP/CRLサーバーである RevocationResponder が、スレッドプールが高負荷の状態でリクエストに応答しなくなる問題の修正です。原因は、ThreadPool.QueueUserWorkItem の preferLocal: true により、リクエストハンドラがワーカースレッドのローカルキューに積まれる点にあります。そのスレッドは直後に HttpListener.GetContext() でブロックするため、他のワーカーがスティールしない限りハンドラが実行されません。グローバルキューが忙しい間は応答が返らず、チェーンエンジンのフェッチがタイムアウトして RevocationStatusUnknown となり、ConnectWithRevocation_WithCallback(checkRevocation: True) が期待する Revoked を得られず失敗していました。

修正は、アクセプトループとリクエストハンドラのキュー投入を preferLocal: false に変更するものです（ThreadPool.QueueUserWorkItem(state => HandleRequest(state), context, false) の形）。テスト専用の変更です。

変更内容

  • src/libraries/Common/tests/System/Security/Cryptography/X509Certificates/RevocationResponder.cs (+10/-3)
    • アクセプトループとリクエストハンドラの両方を preferLocal: false でキューに投入するよう変更
    • その理由を説明するコメントを追加
    • RevocationResponder をコンパイルする全テストプロジェクト（System.Net.Http、System.Net.Mail、System.Net.Quic、System.Net.Security、System.Security.Cryptography）に影響

パフォーマンスへの影響

本番コードへの影響なし（テストコードのみ）。

作成者によるLinux x64（32コア）でのコンソールアプリ再現結果（グローバルキュー負荷ごとの結果）:

グローバルキュー負荷 修正前 修正後
アイドル 5/5 Revoked 5/5 Revoked
24項目（ワーカー数未満） 5/5 Revoked 5/5 Revoked
40項目 × 5 ms 2/10 RevocationStatusUnknown 10/10 Revoked
64項目 × 5 ms 10/10 RevocationStatusUnknown 10/10 Revoked
128項目 × 20 ms 10/10 RevocationStatusUnknown 10/10 Revoked
  • 修正前は失敗するチェーン構築1回あたり約6秒（3秒のフェッチタイムアウト×2と整合）。リーフの状態は [RevocationStatusUnknown, OfflineRevocation] で、WindowsのCI失敗と同じ。
  • 作成者によれば、CIプロセスがこの水準のグローバルキュー飽和に達するかどうかは、タイミングからの推定であり実測ではありません。

関連Issue

#134230（Fixes）

その他

  • 作成者の調査では、Issue報告の47行のうちリンクが有効な30件の内訳は、OSX.26.Arm64.Open が25件、Windows x86 checkedが3件、macOS 15 x64が2件です。確認した失敗ワークアイテム6件では、macOSは Collection: [RevocationStatusUnknown]、Windowsは [RevocationStatusUnknown, OfflineRevocation] を報告し、このテストのみが失敗していました。
  • 失敗時のテスト所要時間は、macOSで約10〜15秒、Windows x86で48秒です。ビルド1638535では、同じケースが他16レグで0.12〜8.4秒で成功しています。
  • macOSおよびWindowsのレグはローカルで実行できておらず、Linux上のコンソールアプリで仕組みと修正の効果を確認したものです。
  • 本PRはAI（Anthropic Claude、OpenAI Codexによる確認）の支援で作成され、作成者がレビュー済みと記載されています。

#136002 ILC: make IsAsyncCall instantiation-invariant

概要

NativeAOT（ILC）で OptimizationPreference=Size の場合に、Task<ValueTask> / Task<ValueTask<int>> を await すると NullReferenceException が発生する問題の修正です。原因は MethodExtensions.IsAsyncCall がインスタンス化後のシグネチャで Task/ValueTask の戻り値判定を行っており、AsyncHelpers.TransparentAwait<T> では T = ValueTask 等のときに判定結果が反転していたことです。ランタイム（vm/class.cpp）は AsyncMethodFlags をジェネリックメソッド定義から一度だけ算出するため、インスタンス化に依存しない判定に揃えました。

var tcs = new TaskCompletionSource<ValueTask>();
tcs.SetResult(ValueTask.CompletedTask);
ValueTask inner = await tcs.Task.ConfigureAwait(false);
await inner.ConfigureAwait(false);

変更内容

  • src/coreclr/tools/Common/Compiler/MethodExtensions.cs: IsAsyncCall の判定を method.Signature ではなく method.GetTypicalMethodDefinition().Signature に対して行うよう変更（1行の修正）。これにより getJitFlags で CORJIT_FLAG_ASYNC が、Get_CORINFO_SIG_INFO で CORINFO_CALLCONV_ASYNCCALL が、該当インスタンス化でも設定され、JIT側の前提（impWrapTopOfStackInAwait が awaitSig.isAsyncCall() を assert し、非同期継続引数を常に追加する）と一致します。
  • src/tests/async/regression/135922.cs（新規）: Task<ValueTask> と Task<ValueTask<int>> を await し、結果をラウンドトリップで検証するリグレッションテスト。
  • src/tests/async/regression/135922.csproj（新規）: 上記テストのプロジェクトファイル。

根本原因の補足: 呼び出し側は非同期継続引数を渡す一方、呼び出される側が async 呼び出し規約なしでコンパイルされるため、16バイト構造体の戻り値バッファが RCX を使う場合に引数レイアウトがずれ、task が R8 に入るのに callee は RDX（=0）から読み、Task.m_stateFlags 参照時にクラッシュしていました。int/void 戻りでは戻り値バッファがないため影響が出ず、Task<int> では発生しませんでした。

パフォーマンスへの影響

影響なし（正しさの修正で、ベンチマーク結果の記載もなし）。

関連Issue

#135922（修正対象）。作成者は関連として #129896 / #130482 にも言及しています（JIT挿入の呼び出しをインライン可能にした変更で、JIT側およびSpeed最適化時には問題が隠れるが、呼び出しがインライン化されない場合は引数の不一致が残る）。

その他

  • 手動検証（本ブランチからビルドした NativeAOT ツールチェーン）: NativeAOT Size での Task<ValueTask> / Task<ValueTask<int>> は修正前 NullReferenceException、修正後 pass。Task<int> / Task / Task.Run(() => ValueTask)、NativeAOT Speed、CoreCLR は修正前後とも pass。
  • テストの制約: 実際の障害は NativeAOT・OptimizationPreference=Size・挿入された TransparentAwait 呼び出しが非インライン、の3条件が揃う必要があります。CoreCLR では await が畳み込まれ、AOTテストパイプラインは既定（Speed）設定でxunitテストをコンパイルするため、追加テストは AOT クラッシュの直接再現ではなく、セマンティクスのリグレッションテストです。

#135999 fold more redundant nullchecks

  • 作成者: @EgorBo
  • 作成日時: 2026年10月17日 14:50:26(UTC)
  • マージ日時: 2026年10月19日 21:09:56(UTC)
  • ラベル: area-CodeGen-coreclr

概要

CoreCLR JITにおいて、Value Number（VN）・アサーション・SSAを活用して、より多くの冗長なnullチェックを除去する変更です（作成者によるとドラフト状態で、EH（例外処理）のPHI入力の扱いは要レビュー）。

作成者が示した例では、holder.Item == null を確認済みのフィールドに対する呼び出しで、x64のコードサイズが37バイトから35バイトに縮小しています。

[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
public static int Test_FieldGuardCall(Holder holder, int value) {
    if (holder.Item == null) return -1;
    return holder.Item.Touch(value);
}

 G_M21527_IG03:
-       cmp      dword ptr [rcx], ecx
        call     [Box:Touch(int):int:this]

変更内容

  • src/coreclr/jit/assertionprop.cpp（+24/-2）: null比較に関するアサーション生成を拡張（参照型の式に対するnull比較の認識など）
  • src/coreclr/jit/utils.cpp（+10/-2）: ヘルパーの「非null返却」プロパティを更新
  • src/coreclr/jit/valuenumfuncs.h（+2/-2）: 2つのVN関数を「非nullを返す」ものとしてマーク
  • src/coreclr/jit/compiler.h（+1/-1）: サブタイプアサーションの契約に関するコメントを明確化

Copilotによる概要では、一部ヘルパーとその配列引数に対する非nullの事実の追加も含まれるとされています。

パフォーマンスへの影響

冗長なnullチェック（cmp dword ptr [rcx], ecx）の除去により、コードサイズ削減と実行命令の削減が見込まれます（例：37→35バイト）。ベンチマーク結果は提供された情報には含まれていません。

関連Issue

なし

その他

  • 公開APIの変更はなく、JIT内部の最適化の変更です。
  • Copilotのレビューでは、EHのPHIの相互作用について専門家による確認が必要であり、ランタイムでの検証は行われていないとされています。
  • 未解決の指摘として、フィールドおよび配列のnullアサーション伝播に対するテスト追加が挙げられています（重要度: Medium）。

#135989 Document ILVerify.Verifier thread safety, PEReader lifetime and the rest of the public API

概要

ILVerify.Verifier と IResolver の既存の振る舞い（スレッドセーフ性、検証の実行タイミング、PEReader の寿命、リゾルバが同一の PEReader インスタンスを返すべき理由）を XML ドキュメントコメントとして明文化する PR です。src/coreclr/tools/ILVerification で公開されている残りの API（VerificationResult、ErrorArgument、VerifierOptions、VerifierError、Verifier のコンストラクタ/メソッド）にもドキュメントを追加しています。動作の変更はありません。

ドキュメント化された主な事実（コード根拠に基づく）:

  • ILVerifyTypeSystemContext は PEReader ごとに EcmaModule を Dictionary にキャッシュし、ロックなしで追加・削除は行わないため、1つの Verifier を複数スレッドで共有するとスレッドセーフではありません。
  • Verify メソッドはイテレータを返すため、検証とリゾルバ呼び出しは列挙時に実行されます（SetSystemModuleName はシステムモジュールを即時に解決）。
  • EcmaModule は PEReader と MetadataReader を保持し、ILVerification 側では PEReader を破棄しないため、呼び出し側は PEReader を使用可能な状態に保つ必要があります。
  • モジュールは PEReader インスタンスをキーにするため、同一アセンブリに別インスタンスを返すリゾルバは、型が別物の複数モジュールを生成します。

変更内容

  • IResolver.cs: 要件の記述を「should」から「must」に変更し、同一アセンブリ/モジュールに対して同一の PEReader インスタンスを返す必要がある旨を記載（+25/-2）
  • Verifier.cs: コンストラクタ・メソッドへの XML ドキュメント追加（スレッドセーフ性、実行タイミング、PEReader の寿命）（+114）
  • VerificationResult.cs: VerificationResult、ErrorArgument、VerifierOptions の XML ドキュメント追加（+97）
  • VerifierError.cs: VerifierError 列挙型のドキュメント追加。None 以外の値は、ライブラリが報告するメッセージの繰り返しになるため個別の summary は付けていません（+8）
  • EcmaSignatureParser.ILVerify.cs: ドキュメント関連の小変更（+3）
  • PACKAGE.md: パッケージの目的と短い使用例を記載（+77）。レビューを受け、スレッドセーフ性・リーダー寿命・リゾルバ要件の詳細な節は削除
  • README.md: PACKAGE.md の例と XML ドキュメントコメントへの案内を追加。ライブラリにコンパイルされている共有型システム（ExceptionStringID を除く）は API の一部ではない旨を記載（+4）

パフォーマンスへの影響

影響なし（ドキュメントのみで、動作変更なし）。

参考として、作成者による検証結果（main の 11ce222b5d6、linux-x64 Release でビルドした ILVerification）:

  • 8スレッドで1つの Verifier を共有した場合、10回の実行すべてで 2400 呼び出しのうち 2〜506 件が InvalidOperationException または ArgumentException で失敗。単一スレッドでは例外なし。重複しない呼び出し（毎回新しいスレッド）600 件は単一スレッド時と同じ結果。
  • 呼び出しごとに新しい PEReader を返すリゾルバでは、System.Collections.Specialized で 200 メソッド中 41、System.Text.Json で 300 メソッド中 147 の結果が変化（例: StackUnexpected が追加される）。
  • CoreLib を再ビルドして検証した場合、リゾルバがディスク上の CoreLib を返すと 300 メソッド中 72 が参照結果と異なり、Verify に渡したインスタンスを返すと 1000 メソッド中 1000 が一致。
  • Verify(peReader, method) 自体はリゾルバを呼ばず、結果の列挙時に呼ばれる。
  • キャッシュ済みモジュールの PEReader を破棄してから検証を続けると、配列ベースのリーダーでは ObjectDisposedException、ファイルベースのリーダーでは AccessViolationException が発生しプロセスが異常終了。
  • ILVerification.Tests（Release）: 501/501 成功。

関連Issue

なし

その他

  • PR の作成者は、AI支援（Anthropic Claude と OpenAI Codex）を用い、自身の指示のもとで作成し、投稿前にレビューしたと記載しています。
  • 実装上の注意点として、検証対象のアセンブリを名前で解決する場合（例: System.Private.CoreLib がシステムモジュールかつ検証対象の場合）にも、同一 PEReader インスタンスを返す必要があります。

#135987 [release/11.0] Allow uncontended synchronous waits on single-threaded runtimes

概要

シングルスレッドランタイム（browser、WASI）で、SemaphoreSlim.Wait、ManualResetEventSlim.Wait、Monitor.Wait/Condition、Task.Wait などの同期待機が、実際にはブロックしない場合でも PlatformNotSupportedException をスローしていた問題を修正します。本変更により、競合のない（uncontended）待機は成功し、実際にブロックが必要になる場合にのみ例外をスローします。マルチスレッドランタイムの動作は変更されません。

これは .NET 10 からのリグレッション（dotnet/runtime#123329 が原因）で、Roslyn workspaces のように SemaphoreSlim を使うBrowser/WASIアプリやライブラリに影響していました。本PRは main の dotnet/runtime#135413 の release/11.0 へのバックポートです。

変更内容

  • CoreLib（Condition.cs、ManualResetEventSlim.cs、Monitor.cs、SemaphoreSlim.cs、Task.cs、Mono の Monitor.Mono.cs）：シングルスレッドランタイムで、ブロックしない待機を許可するよう PlatformNotSupportedException のスロー条件を緩和
    • Task.cs は変更量が最も大きい（+44/-29）
  • テスト追加：SemaphoreSlimTests、ManualResetEventSlimTests、MonitorTests、TaskRtTests_Core に、シングルスレッドランタイムでのみ実行される Wait_SingleThreaded テストを追加
  • ドキュメント：src/mono/wasm/threads.md に動作を記載

パフォーマンスへの影響

影響なし（デスクトップのマルチスレッドの待機パスは変更なし）。

関連Issue

その他

  • マルチスレッドのブラウザ（WasmEnableThreads）では、Task.Wait/WaitAll/WaitAny が JS interop スレッドでブロック可否を事前チェックしなくなります。実際にブロックする待機は引き続き ManualResetEventSlim.Wait 経由でスローまたは警告されますが、タイムアウト0の WaitAll/WaitAny は例外をスローせず戻るようになります。
  • テスト結果（PR記載）：
    • デスクトップCoreCLR：System.Threading.Tests 717件中失敗0、System.Threading.Tasks.Tests 980件中失敗0
    • Browser/wasm（Mono, V8）：System.Threading.Tests 635件実行で失敗0、System.Threading.Tasks.Tests 724件実行で失敗0。新規の Wait_SingleThreaded テスト4件はすべて成功
  • リスクは低いと記載されています。プロダクト変更はCoreLibの6ファイルとドキュメントに限定され、release/11.0 にクリーンに適用されています。

#135972 Keep corerun host-runtime contract state alive for the process lifetime

  • 作成者: @MihaZupan
  • 作成日時: 2026年10月16日 19:45:58(UTC)
  • マージ日時: 2026年10月19日 06:01:40(UTC)
  • ラベル: area-Host

概要

corerun が run() / main の終了後もランタイムの別スレッドから呼ばれ得る host_runtime_contract コールバック（resolve_assembly_to_path / get_runtime_property）で、破棄済みのスタック上の状態を参照して SIGSEGV するクラッシュを修正します。#132861 で TPA が プロパティ文字列から host_runtime_contract のコールバックへ移行された影響で、run() 内のスタックローカルだった contract とそのコンテキスト（assembly パスの unordered_map を保持）が、終了処理中に別スレッドから参照されていました。

  • 修正内容：contract とコンテキストをヒープ確保し、意図的に解放しない（プロセス終了まで必要なため）。
  • 併せて、コンテキストが main の（コピー不可の）configuration を指すのをやめ、get_runtime_property が必要とするフィールドをコピーして保持するようにしています。
  • 本件は hostpolicy に対する #135908 の corerun 版です。

変更内容

  • src/coreclr/hosts/corerun/corerun.cpp（+13/-8）
    • host_runtime_contract とそのコンテキスト（host_runtime_contract_context）をスタックローカルからヒープ確保に変更し、解放しない。
    • コンテキストが configuration へのポインタを持つ代わりに、entry_assembly_fullpath、user_defined_keys、user_defined_values をコピーして保持する。

パフォーマンスへの影響

影響なし（ランタイム性能に関する変更ではありません）。意図的なリークは、プロセス終了まで必要なオブジェクトに限られます。

関連Issue

  • #132861（TPA を host_runtime_contract コールバックへ移行した変更。原因として言及）
  • #135908（hostpolicy 側の同種の修正）

その他

  • 症状：多数の corerun を並列実行する MihuBot の JitDiffs で、小さなアセンブリに対して散発的に "Error running corerun on <assembly>"（exit code 139）が発生していました。負荷下で単一アセンブリ実行時に約250回に1回の割合で再現します。コアダンプでは、メインスレッドが exit() 内にある間に、PMI メソッドを JIT 中の別スレッドが resolve_assembly_to_path 内の unordered_map::find でフォールトしていました。
  • 検証（Linux x64、checked JIT 付き Release ランタイム）：
    • System.Numerics に対する corerun + PMI の並列2000回実行（32並列）：修正前は8件クラッシュ、修正後は0件（3000回中0件）。
    • jit-diff diff --cctors --frameworks --pmi を main と PR で並列に3回実行：「Error running」失敗0件、dasm ファイル439個すべて生成。修正前は4回中3回で失敗していました。
  • 作成者は、このコードベースの該当部分には詳しくないため、別の修正方針があれば PR のクローズも可とコメントしています。

#135954 Preserve NativeAOT WASI numeric exit codes

概要

NativeAOT の WASI アプリケーションで、マネージドのエントリポイントが返す数値の終了コードを保持するようにする変更です。

WASI Preview 2 の libc の通常の起動処理は main を呼び出し、r != 0 を CLI run インターフェイス経由で返します。そのため、テストが 100 を返しても、Wasmtime の exit-with-code オプションを使ってもホストの終了コードは 1 になります（libc の時点で数値が破棄されているため）。

WASI では exit(__managed__Main(...)) を呼び出すことで、libc が数値の exit-with-code インターフェイスを使えるようにします。他プラットフォームのブートストラップ経路は変更されません。なお、Wasmtime 側でこのインターフェイスを有効にするには -S cli-exit-with-code=y が引き続き必要です。

変更内容

  • src/coreclr/nativeaot/Bootstrap/main.cpp (+4/-0): WASI 向けに exit(__managed__Main(...)) を呼び出すようにし、マネージドの終了コードを libc に渡す

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 検証（作成者による、他の未マージの WASI 対応を含むローカルのブリングアップ用ツリー上での実施）:
    • .\build.cmd clr.nativeaotruntime -rc Checked -lc Release -os wasi -arch wasm が成功
    • .\src\tests\build.cmd nativeaot checked test nativeaot\SmokeTests\AttributeTrimming\AttributeTrimming.csproj wasm wasi が成功
    • wasmtime run -W exceptions=y -S cli-exit-with-code=y ...AttributeTrimming.wasm が終了コード 100 を返すことを確認
    • SDK の libc 起動ソースとインストール済み CRT の逆アセンブルを確認し、真偽値への変換が行われていることを確認
  • このブランチには main から cherry-pick した本コミットのみが含まれ、単独ではビルドしていないとのことです。

#135949 Require matching WASM function types when folding method bodies

概要

NativeAOT コンパイラ（WASM ターゲット）で、メソッド本体を重複排除（folding）する際に、WASM の関数型（lowered function type）が一致していることを要求するようにする変更です。命令バイト列が同一でも、未使用パラメータの違いなどにより WASM のシグネチャが異なる場合があります。アドレスが取得されたメソッドの forwarding stub は、パラメータを folding 先のターゲットへ渡すため、ターゲットの関数型が異なるとモジュールが不正になる問題がありました。これを防ぐため、隠し ABI パラメータを含む lowered 関数型の比較を、WASM におけるメソッド本体の等価判定に追加しています。既存の本体／リロケーション比較および非 WASM の挙動は変更されません。

変更内容

  • src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/MethodBodyDeduplicator.cs（+9/-0）
    • メソッド本体の等価比較に、WASM 向けの lowered 関数型（隠し ABI パラメータを含む）の一致チェックを追加

パフォーマンスへの影響

影響なし（記載された情報なし）

関連Issue

なし

その他

  • 検証は、未マージの他の有効化変更を含むローカルの NativeAOT WASI 統合ツリー上で実施されたと記載されています。
    • .\build.cmd clr.tools -rc Checked -lc Release -os wasi -arch wasm が成功
    • AttributeTrimming と Determinism を強制再生成し、いずれも Wasmtime 上で終了コード 100 で実行成功
    • Determinism の並列／シングルスレッドのコンパイラ出力が同一であることを確認
  • このブランチは main から cherry-pick した本コミットのみを含み、単独ではビルドされていません。また、スモークテストは WASM ランタイム全般の正しさを主張するものではないと明記されています。

#135941 Serialize HTTP/2 loopback writes and join reader before disposal

  • 作成者: @rzikm
  • 作成日時: 2026年10月16日 11:22:23(UTC)
  • マージ日時: 2026年10月19日 10:49:30(UTC)
  • ラベル: area-System.Net.Http

概要

HTTP/2のループバックテストにおいて、同一接続上で複数の書き込みが同時に発行され、SslStream が NotSupportedException: This method may not be called when another write operation is pending. をスローする問題を修正するテスト側の変更です。保留中の ReadFrameAsync が透過的にPING ACKを送信するのと同時に、テストがレスポンスHEADERSを送信する場合があります。また、keepalive用のリーダーがクライアントのEOFを検知して切断用GOAWAYを送信している最中に、最終レスポンスのDATAが書き込まれる場合もあります。プロダクトコードの変更や共有ヘルパー実装の変更はなく、プロトコルのアサーションも変わりません。

変更内容

  • HttpClientHandlerTest.Http2.cs（+1/-1）: stream-limitテストで、既存の接続スコープの EnsureThreadSafeIO オプションを有効化。
  • SocketsHttpHandlerTest.Http2KeepAlivePing.cs（+3/-3）: keepaliveのフィクスチャで EnsureThreadSafeIO を有効化。あわせて、接続の破棄を TerminateLoopbackConnectionAsync に移し、受信フレーム用タスクをjoinした後に実行するよう変更。これによりリーダーがEOF時に独自にシャットダウンを開始しなくなる。

パフォーマンスへの影響

影響なし（テストコードのみの変更）。

関連Issue

なし

その他

  • 検証はWindows x64で実施。対象の5つのテストは通常実行で15件成功（失敗0、スキップ0）、SocketsHttpHandler_Http2KeepAlivePing_Test クラス全体も10件成功。
  • SslStream 下位のトランスポート書き込み完了を50ms遅延させる増幅条件では、5つのメソッドのうち4つで競合する書き込みを再現。全5テストを3回繰り返した結果、元のコードは12件失敗、直列化のみでは15/15成功、joinのみでは9/15成功、本修正では15/15成功。
  • 遅延なしのベースラインでは自然発生の失敗は確認されていません。max-concurrent-streams keepaliveのバリアントはローカルで再現せず、修正後の実行では全て成功。
  • Linux/ARM、NativeAOT、WinHTTP、System.Net.Http全体のテストスイートは未実施。
  • 作成者の記載によれば、このPRの説明とコード変更はGitHub Copilotで生成されています。

#135940 Synchronize WebSocket keep-alive timeout test with heartbeat completion

  • 作成者: @rzikm
  • 作成日時: 2026年10月16日 11:19:34(UTC)
  • マージ日時: 2026年10月19日 10:58:09(UTC)
  • ラベル: area-System.Net

概要

WebSocket_NoPongResponseWithinTimeout_Aborted テストの同期不良を修正するPRです。従来は固定の2.2秒待機で「最初のping送信」と「そのタイムアウトによるハートビート処理」の両方が完了すると仮定していましたが、ThreadPoolのスケジューリング遅延下では、ping期限切れ前またはハートビート配信前に Open が観測され、アサーションが失敗し得ました。修正では、最初のpingを読み取って検証した後、タイムアウト駆動のストリーム破棄による相手側のEOFを待ってから Aborted を検証するようにしています。いずれの待機も既存の全体キャンセルトークンで制限されます。製品コードの変更はなく、テストのみの修正です。

変更内容

  • src/libraries/System.Net.WebSockets/tests/WebSocketKeepAliveTests.cs（+10/-3）
    • 最初のpingを読み取って検証する処理を追加
    • タイムアウトによるストリーム破棄に伴うピアのEOFを待機してから Aborted をアサート
    • pingの間隔100ms、pongのタイムアウト1秒、およびタイムアウト例外の厳密なアサーションは変更なし

パフォーマンスへの影響

影響なし（テストコードのみの変更で、製品コードの変更はありません）。

関連Issue

なし

その他

  • 作成者による検証結果：
    • build.cmd clr+libs -rc release が成功（MsQuic依存関係に関する既存のNU1902警告が3件）
    • System.Net.WebSockets.Tests を Outerloop=true で実行し、618テストが失敗・スキップなしで成功
    • ThreadPoolを意図的に枯渇させた分離プロセスでの検証：同期変更のみを元に戻すと両theoryケースで Expected: Aborted, Actual: Open が再現し、変更を戻すと1.8秒・2.6秒の枯渇下でも両ケースが成功
  • これはテスト同期上の欠陥であることを示すもので、CI失敗時の正確なスケジューリング履歴を特定したものではないと作成者は述べています。
  • #133374 で追跡されている、キャンセルされた受信ループの状態遷移は本PRでは扱っていません。
  • 本PRの説明とコード変更はGitHub Copilotにより生成されたと記載されています。

#135939 [Interpreter] Raise a pending thread abort again at the resume point after a catch

概要

インタープリターで catch ブロックを抜けた後、保留中のスレッド中断（thread abort）を再開ポイントで再度発生させるよう修正するPRです。コンパイル済みコードの EECodeManager::ResumeAfterCatch と同様の挙動を InterpExecMethod に持たせています。あわせて、catch の leave island への遷移を INTOP_LEAVE_CATCH に統一しました。これにより、再開ポイントが catch の try 領域を囲むすべての try 領域の内側に入り、#135871 で外側の catch が abort を取りこぼす問題が解消されます。

変更内容

  • src/coreclr/interpreter/compiler.cpp: leave 内で catch leave island へ入るすべてのエッジに INTOP_LEAVE_CATCH を使用し、leave 先への最終エッジを含むそれ以外のエッジには INTOP_BR を使用するよう変更しました。これにより catch は INTOP_LEAVE_CATCH で island に抜けます。
  • src/coreclr/vm/interpexec.cpp: catch 後に保留中の thread abort を再開ポイントで再度発生させる処理を追加しました。先に Thread::m_OSContext を設定し、ResumeAfterCatchException の C++ catch の外にある専用の try ブロックから abort を発生させます。INTOP_THROW と同様に、abort 発生前にフレームを faulting としてマークし、ハンドラー検索が再開ポイント自体で行われるようにしています。
  • ControlledExecutionTests.cs: CancelInTryAndExitCatchNormally を再度有効化しました。
  • GitHub_135463（新規回帰テスト、7ケース）: #135871 の2ケースは、JIT コードが #135637 の修正まで誤動作するため、インタープリター実行時のみ動作します。
  • GitHub_135530/test135530.cs: インタープリター下でのスキップを解除しました。

パフォーマンスへの影響

影響なし（記載なし）。ベンチマーク結果はPR説明に含まれていません。

関連Issue

その他

  • 作成者による検証（Checked ランタイム、linux-x64 / osx-arm64 / windows-x64）では次の結果が報告されています。
    • main では GitHub_135463、GitHub_135530、ControlledExecutionTests が ReadyForAsyncException のアサートでプロセスごと失敗します。
    • 本PRでは、インタープリター構成（DOTNET_InterpMode 1/2/3、TieredCompilation=0 の有無）でこれらがすべて通ります。
    • Regressions では新規の失敗はありません。
  • GitHub_135463 は leave island の変更とフレームの faulting マークの両方が必要です。前者がないと #135871 の2ケースが失敗し、後者がないと同じハンドラーに abort が繰り返し捕捉されてテストがハングします。
  • 本PRはAI（Anthropic Claude、OpenAI Codex による確認）の支援で作成されたと明記されています。

#135932 Managed ilasm: keep invalid LocalScope/LocalVariable rows and report them as errors

概要

マネージド版 ilasm が、Portable PDB 仕様上無効な LocalScope / LocalVariable 行を黙って捨てていた挙動（#135311）を改め、行は宣言どおり出力したうえで、ソース上の該当箇所にエラーとして報告するようにする変更です。--error 指定時はエラーがあっても行を宣言どおりに書き出し、「Output file contains errors」を表示します。--error なしでは ***** FAILURE ***** を出力し、何も書き出しません。

追加された診断:

  • ILA0058: 命令のないスコープ（最初の名前付きローカルの位置で報告）
  • ILA0059: スコープ内で既に宣言済みのローカル名
  • ILA0060: スコープ内で他の名前付きローカルが使用済みのスロット

PDB が要求された場合のみスコープを記録するため、PDB なしのビルドには影響しません。

変更内容

  • GrammarActions.BuildImage.cs: 無効な行のフィルタリングをやめ、宣言どおりに出力して診断を報告する処理に変更
  • GrammarActions.Signatures.Actions.cs / MethodBodies.Locals.cs / MethodBodies.Directives.cs / Conversions.cs: ローカル名トークンを捕捉して位置情報を持たせ、各ディレクティブ後にクリア
  • EntityRegistry.cs: ローカル宣言の位置を記録
  • Diagnostic.cs: 診断 3 件を追加
  • MANAGED-ILASM-FIXES.md: 新しい互換性挙動に合わせて更新
  • テスト: LocalScopeTests、生成ケース（LocalScopeCaseGenerator / LocalScopeGeneratedCaseTests）、PdbDocumentTests を更新

パフォーマンスへの影響

影響なし（記載なし）

関連Issue

#135311 のフォローアップ（レビューコメント対応）。Issue 番号の記載はなし。

その他

  • ネイティブ ilasm の挙動（無効な行も出力する）に合わせる変更です。
  • スコープ外スロットの扱いは変更なしです。
  • テスト: ILAssembler.Tests は 5110 件が成功（変更前は 4704 件）。新規診断のチェックや旧フィルタを個別に戻すと、いずれもテストが失敗することを確認済みです。
  • 作成者によると、本 PR は AI（Anthropic Claude、OpenAI Codex でチェック）の支援で作成され、作成者がレビュー済みです。

#135929 [release/11.0] Swallow ObjectDisposedException when restoring blocking mode after connect async

概要

ConnectAsync 完了後にソケットのブロッキングモードを復元する際、ソケットが既に破棄されていると ObjectDisposedException が未処理例外となり、アプリケーションプロセスがクラッシュする問題の修正です。この例外を握りつぶすことでクラッシュを防ぎます。#135857 の release/11.0 へのバックポートです。

  • 11.0 で #124200 により導入されたリグレッションです。
  • CI で散発的に発生しており、11.0 RC1 を使用する顧客からも報告されています（#135681）。
  • 修正は局所的で、副作用は想定されていません（リスク: 低）。

変更内容

  • src/libraries/System.Net.Sockets/src/System/Net/Sockets/SafeSocketHandle.Unix.cs (+2/-2)
  • src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs (+9/-2)

いずれも Unix 向け実装で、Windows 向けコードへの変更はありません。ライブラリ内部実装の修正で、公開 API の変更や互換性への影響は記載されていません。

パフォーマンスへの影響

影響なし

関連Issue

  • #135681（修正対象）
  • #135857（main への元の修正 PR）
  • #124200（リグレッションの原因となった PR）

その他

  • 修正は main でマージ済みで、マージ後は CI での失敗が発生しなくなったとのことです。
  • 具体的な実装内容（どの箇所で例外を握りつぶすか）は、提供された情報からは判断できないため記載していません。

#135921 Validate pcMap, not pcClauses, in CordbReJitILCode::GetInstrumentedILMap

概要

CordbReJitILCode::GetInstrumentedILMap（src/coreclr/debug/di/module.cpp）で、自身のパラメータではなく、直前の GetEHClauses のパラメータである pcClauses を検証していた誤りを修正します。pcClauses を GetInstrumentedILMap 自身の out パラメータ pcMap に置き換えています。

従来コードがコンパイルできていたのは、VALIDATE_POINTER_TO_OBJECT_OR_NULL マクロが何も展開されないためです（src/coreclr/debug/inc/common.h）。このため引数は破棄されており、挙動は変わりません。作成者は linux-x64 Release で libmscordbi.so を変更の前後でビルドし、2つのファイルがバイト単位で同一であることを確認しています。

変更内容

  • src/coreclr/debug/di/module.cpp（+1/-1）
    • CordbReJitILCode::GetInstrumentedILMap 内の VALIDATE_POINTER_TO_OBJECT_OR_NULL の引数を pcClauses から pcMap に変更

パフォーマンスへの影響

影響なし（マクロが展開されず、バイナリもバイト単位で同一であるため）。

関連Issue

なし

その他

  • 公開APIや互換性への影響はなく、コードの正確性（可読性・保守性）を改善するための修正です。
  • 作成者によると、本PRはAI（Anthropic Claude と OpenAI Codex）の支援を受けて作成され、作成者自身がレビュー済みです。

#135915 Do not adjust wasm virtual IPs in the thread abort stack walk

概要

wasm上のReadyToRunフレームのcontrol PCは戻りアドレスではなく仮想IP（fgWasmVirtualIP）であるため、スレッドアボートのスタックウォーク（TAStackCrawlCallBackWorker）で行っている「非アクティブフレームのオフセットを1戻す」補正が誤動作していました。これにより、ハンドラ（finally/catch）の最初のリージョンでの呼び出しがハンドラ外と判定され、そのハンドラ内で再度アボートが発生していました。本PRでは仮想IPに対してこの補正をスキップするよう修正します（SfiInit/SfiNextでは既にスキップ済み）。

結果として、デフォルトのReadyToRun CoreLibで ControlledExecution.Run が OperationCanceledException ではなく ThreadAbortException をスローする問題が解消されます。

変更内容

  • src/coreclr/vm/threadsuspend.cpp（+7/-1）: TAStackCrawlCallBackWorker で仮想IPの場合はオフセット補正を行わないように変更。仮想IPは進行中の呼び出しのリージョンを指し、EH境界はリージョン境界なので補正は不要という理由づけ。アクティブフレームは元々補正対象外で、インタプリタフレームは仮想IPではないため補正を維持。
  • src/libraries/System.Runtime/tests/System.Runtime.Tests/System/Runtime/ControlledExecutionTests.cs（+4/-5）: クラス全体に付いていた IsMultithreadingSupported 条件を、Task.Run からキャンセルする4つのテストのみに移し、第2スレッドを必要としないテスト（CancelBeforeRun など）をシングルスレッドwasmで実行可能にした。

作成者による計測結果（browser-wasm Checked、node、シングルスレッド、デフォルトR2R CoreLib）:

  • CancelBeforeRun: 修正前はインタプリタの #135463 のassertが発生 → 修正後は OperationCanceledException
  • ハンドラなしでスレッドが自身をアボート: ThreadAbortException → OperationCanceledException
  • try/finally のみ: ThreadAbortException（finallyは実行）→ OperationCanceledException（finallyは実行）
  • CancelItselfFromFinally: 変更前後ともパス
  • DOTNET_ReadyToRun=0 の場合: 変更なし

パフォーマンスへの影響

影響なし（パフォーマンス計測の記載なし）。

関連Issue

  • #135914（1つ目の問題を修正。2つ目の問題は未解決で、CTSのR2R catch後のcatch終了時アボートチェックがwasmのCheckedビルドでassertする）
  • #135463（修正前の挙動で言及されるインタプリタのassert）
  • #135520（CancelInTryAndExitCatchNormally の再有効化。Task.Run を使うため、先後どちらかのPRが条件を追加する必要あり）

その他

  • linux-x64、osx-arm64、windows-x64（Checked）では、ランタイムのコードは行番号定数以外mainと差分なしと作成者が確認しており、ControlledExecutionTests は3プラットフォームすべてで8/8パス。
  • wasm上でのライブラリテストのローカル実行およびReleaseランタイムでの検証は未実施。
  • 本PRはAI支援（Anthropic Claude、OpenAI Codexによるチェック）で作成され、作成者がレビュー済みとのこと。

#135906 crossgen2: allow struct/unmanaged-constrained generics over primitives in the version bubble

  • 作成者: @lewing
  • 作成日時: 2026年10月15日 22:58:58(UTC)
  • マージ日時: 2026年10月19日 17:23:12(UTC)
  • ラベル: area-ReadyToRun

概要

crossgen2が、CoreLibのプリミティブ型（char、int など）を型引数とする where T : struct / where T : unmanaged 制約付きジェネリックを、CoreLibのバージョンバブル外のコードからインスタンス化した場合に、プリコンパイルもインライン化もしなかった問題の修正です。

原因は ComputeInstantiationVersionsWithCode が、型制約が1つでもあるとプリミティブ型引数をバージョンバブルの一部と見なさなかった点です。C#は struct / unmanaged 制約を System.ValueType の型制約としてメタデータに出力するため、制約リストが空でなくなり、VersionsWithMethodBody が false を返していました。その結果、定義モジュールへのコンパイルがされず、CanInline も false となり、JITが「cannot get method info」と報告していました。

修正では、型引数がプリミティブの場合に System.ValueType 制約を無視します。インターフェイスやクラスなど他の制約は従来どおり不適格のままです。ランタイム側の変更は不要です。

変更内容

  • ReadyToRunCompilationModuleGroupBase.cs: プリミティブ型引数に対して System.ValueType 制約を無視するよう変更（object/string の分岐は不変）
  • CrossModuleInliningInfoSection.cs（R2Rリーダー）: 自身のコンパイル済み本体を持たないローカルのインライン対象（AggressiveInlining ヘルパーなど）を、イメージのメタデータから名前解決して表示するよう改善（従来は <MethodDef 0x…> と表示）。R2RDump出力も改善
  • crossgen2-compilation-structure-enhancements.md: 上記のルールを明記
  • StructConstrainedGenerics.cs / R2RTestSuites.cs: 新テスト StructConstrainedPrimitiveInstantiations を追加。StructConstrained<int>、UnmanagedConstrained<int>、StructConstrainedBox<int>.GetValueHashCode がコンパイルされること、および struct / unmanaged 制約付き AggressiveInlining ヘルパーがインライン化されることを検証

パフォーマンスへの影響

  • 影響を受ける構成:

    • --opt-cross-module なしのネイティブなアセンブリ単位R2R
    • --opt-cross-module も --inputbubble もない、アプリのみのコンポジット

    これらでは、該当インスタンス化が起動時にJITされ、R2Rインライン化も行われていませんでした。今回の修正でR2Rコードが使われ、インライン化されるようになります。

  • 影響なし（no-op）の構成:

    • browser-wasmのデフォルト（アセンブリ単位 + --opt-cross-module:*）
    • フレームワークを含むコンポジット（browserコンポジット、WASI、Appleモバイル）

  • スタンドアロンの再現では、CallS(char) / CallM(char) のコードサイズが制約なしの CallU(char) と同じになり、インライン化されていることが確認されています。

  • ベンチマーク数値の記載はありません。

関連Issue

  • #135899（同じcrossgen2領域で発見）
  • #134559（INumber<T> 演算子のような静的仮想メソッド呼び出しがバージョンバブルをまたいで解決できない問題。本PRの対象外）

その他

  • IEquatable<T> などインターフェイス制約付きのプリミティブのインスタンス化は、設計上これまでどおりR2Rコンパイルの対象外です（例: IN<int> は未コンパイルのまま）。
  • 検証はosx-arm64のcheckedビルドで実施しました。clr.r2rtests は51件中36件成功、0件失敗、15件スキップ（ターゲット固有）です。修正のみを戻した場合、新テストが Expected compiled method 'StructConstrainedGenerics.StructConstrained<int>' not found で失敗することも確認済みです。
  • CIのbrowser-wasm R2Rテストレグ（CLR_R2R_Tests_browser_wasm）はローカルでは未実行です。
  • PR説明および変更はGitHub Copilotにより生成されたと記載されています。

#135900 [release/11.0] Exclude mobile targets from Helix dump-doc generation

概要

release/11.0 ブランチへのバックポートPR（元PR: #135875）です。Helix用のdump-doc生成の対象から、モバイルターゲットを除外する変更です。

提供された情報には、変更の動機（なぜ除外が必要か）や具体的な不具合の内容は記載されていません。Customer Impact、Regression、Testing、Riskの各セクションもテンプレートのまま未記入です。

変更内容

  • src/libraries/sendtohelixhelp.proj（+1/-1）：Helixのdump-doc生成条件が1行変更されています。変更の詳細な差分内容は提供されていません。

パフォーマンスへの影響

影響なし（ビルド/CIインフラ（Helix）関連の変更で、ランタイム/ライブラリの実行時性能に関する記載はありません）

関連Issue

  • 元PR: #135875（release/11.0へのバックポート元）

その他

  • 公開APIやランタイムの挙動を変更するものではなく、テスト実行インフラ側の変更と考えられます。
  • 作成者は github-actions[bot] で、@steveisok がレビュー対象としてメンションされています。
  • PRテンプレートの各項目（影響、リグレッション有無、テスト、リスク）が未記入のため、これらの評価は提供情報からは判断できません。

#135862 [QUIC] Remove buffer-size payload

  • 作成者: @ManickaP
  • 作成日時: 2026年10月15日 12:08:18(UTC)
  • マージ日時: 2026年10月19日 09:14:47(UTC)
  • ラベル: area-System.Net.Quic

概要

QUICのテストが不安定になる原因として、接続のクローズ処理がストリームデータの受信より先に処理されるタイミング問題が疑われています。これを受け、テスト内でバッファサイズ分のペイロードを送る処理を取り除き、この競合が起きる確率を下げる変更です。ライブラリ本体の実装変更ではなく、テストコードのみの修正です。

変更内容

  • src/libraries/System.Net.Quic/tests/FunctionalTests/QuicStreamTests.cs: 1行を変更（+1/-1）。大きなバッファ（buffer-size payload）を扱う部分を除外し、タイミング問題の発生確率を下げる。

パフォーマンスへの影響

影響なし（テストコードのみの変更）

関連Issue

#135843

その他

  • 作成者は、あくまで確率を下げる対処であり「Likely（おそらく）」タイミング問題が原因、という見立てを述べています。根本的な競合の解消を保証するものではありません。
  • 公開APIや互換性、セキュリティへの影響に関する記載はありません。

#135820 [CI] Prune Roslyn caches before saving snapshots

  • 作成者: @agocke
  • 作成日時: 2026年10月14日 22:24:51(UTC)
  • マージ日時: 2026年10月19日 08:39:24(UTC)
  • ラベル: area-Infrastructure

概要

Azure Pipelinesがキャッシュスナップショットを保存する前に、Roslynのコンパイルキャッシュを削除（プルーニング）するCI変更です。VBCSCompiler -purgecache:<job-start-time> を使い、そのジョブで使われなかったエントリを破棄し、再利用されたエントリと新規作成されたエントリは保持します。

背景として、Linux Debugのキャッシュ保存がアーカイブ作成時の No space left on device で失敗しており、新しいスナップショットを公開できていませんでした。サンプルのLinux Releaseキャッシュでは、未使用エントリが11,430件、再利用エントリが288件、新規保存エントリが881件でした（バイト数ではなくエントリ数）。

変更内容

  • eng/pipelines/coreclr/templates/prune-roslyn-cache.yml（新規、+59）
    • BashとPowerShell向けのプルーニングステップを追加します。
    • プルーニング前後のキャッシュサイズ、空きディスク容量、コンパイラのプルーニング概要をログに出力します。
    • コンパイラが終了コード0を返した場合でも、削除エラーを検出して表面化させます。
  • eng/pipelines/common/global-build-job.yml（+4）
    • ジョブが成功し、かつキャッシュが有効な場合に、postBuildSteps の後でプルーニングを呼び出します。既存の統計収集ステップと並べず postBuildSteps の後に置いたのは、統計収集の後にもCoreCLRテストをコンパイルするレグがあるためです。
  • eng/pipelines/coreclr/templates/setup-build-caches.yml（+2/-3）
    • キャッシュキーと復元を世代 roslyn | v3 に移行し、プルーニング前の v1/v2 へのフォールバックを行いません。プラットフォーム・レグ・Debug/Releaseの分離は維持します。

パフォーマンスへの影響

  • 既存のRoslyn v1/v2 スナップショットは復元されないため、各レグで最初の1回はコールドなRoslynビルドが発生します。
  • プルーニングで保持履歴が減り、キャッシュ保存時のディスク逼迫の解消が期待されます。
  • バイト数の硬い上限は課しません（完了したジョブのワーキングセットを保持するだけです）。エンドツーエンドの高速化は主張されておらず、ベンチマーク結果もありません。
  • Sccacheの挙動は変更ありません。

関連Issue

なし

その他

  • 検証内容
    • 変更したYAMLを解析し、最終ステップの配置と世代ごとに分離された復元を確認しています。
    • ピン留めされたSDK 11.0.100-rc.1.26420.103 と使い捨てのキャッシュフィクスチャで、PowerShell/Bashのクリーンアップスクリプトを実行しています。
    • 不要エントリの削除、再利用・新規エントリとステージングディレクトリの保持を確認しています。
    • 無効なタイムスタンプ指定時に、保持すべきエントリを削除せず失敗することを確認しています。
    • Roslynが正常終了しても削除エラーが表面化することを確認しています。
  • 未検証事項
    • Bashの確認はGit BashとWindowsのコンパイラホストで行っています。
    • Linux/macOSエージェントでの実行と、パイプライン全体・スナップショット保存のエンドツーエンド検証は未実施です。
    • ランタイムのフルビルドは実行していません。
  • PR説明とコード変更はGitHub Copilotの支援で作成されています。

#135806 Eagerly resolve intrinsic ReadyToRun type handles and arrays

  • 作成者: @davidwrighton
  • 作成日時: 2026年10月14日 22:13:32(UTC)
  • マージ日時: 2026年10月19日 23:15:04(UTC)
  • ラベル: area-ReadyToRun

概要

crossgen2 の ReadyToRun コンパイルで、CorElementType により直接エンコードされる組み込み型（string、object、TypedReference など）の具象 TYPE_HANDLE インポートを、メソッドごとのフィクスアップではなく モジュール eager インポートセクションに配置するよう変更します。同ルールはこれらの型の配列（多次元配列・ネスト配列を含む）にも適用されます。enum、その他トークン依存の型、ポインター、byref は従来の扱いのままです。

  • 最終的な依存関係トラバーサルで到達したインポートのみが出力され、定義済みの型一覧をルート化するものではありません。
  • eager セルはモジュールロード時に解決され、メソッドごとのフィクスアップリストには現れなくなります。
  • Wasm 専用ではなく、crossgen2 共通のインポート選択ロジックの変更です。
  • 元の変更（#135553）から独立部分を main に切り出したもので、二段階コンパイル、直接呼び出し、prolog/フレーム ID の変更は含みません。

変更内容

  • docs/design/coreclr/botr/readytorun-format.md: eager な型ハンドルのルールを追記（+5）
  • ILCompiler.ReadyToRun/.../ReadyToRunSymbolNodeFactory.cs: 組み込み型およびその（ネスト）配列に対し eager インポートを選択するロジックを追加（+24/-1）
  • ILCompiler.ReadyToRun.Tests/.../Webcil/WasmWebcilModule.cs: 組み込み型とトークン依存型のテスト用フィクスチャを追加（+64）
  • ILCompiler.ReadyToRun.Tests/.../R2RTestSuites.cs: 最適化/非最適化 × 通常/コンポジット コンパイルを対象とした回帰テスト（theory）を追加。インポート配置の正確性と一意性、メソッドフィクスアップリストからの除外、トークン依存型フィクスアップの維持を検証（+126/-3）

パフォーマンスへの影響

メソッドごとのフィクスアップ処理とストレージを削減する代わりに、モジュールロード時に型解決を行うトレードオフです。

作成者が元の開発ブランチで測定した Wasm イメージサイズ（JIT ハッシュ・入力ハッシュは前後で一致、Brotli は quality 11 / window 22）:

Wasm イメージ Raw 削減 Brotli 削減
Retail CoreLib 2,912 B（19,108,544 → 19,105,632） 1,421 B（3,586,039 → 3,584,618）
CoreLib + CallPerformance composite 2,656 B（12,809,630 → 12,806,974） 2,697 B（2,811,171 → 2,808,474）
  • これは今回切り出した PR ではなく元ブランチでの測定値であり、現在の main で同等の削減が得られる保証はありません。
  • スループットのベンチマークではなく、起動レイテンシの新規測定も行われていません。

関連Issue

  • #135553（元の変更。Issue ではなく PR として言及されています）

その他

  • 本 PR はドラフトで、ビルド・ランタイムテスト・新規ベンチマークは作成者の明示的な指示により未実行です。検証したのは git diff --check と、eager インポートの依存関係維持およびメソッドフィクスアップ出力のコード追跡のみです。
  • Copilot のレビューでは、eager な配列解決が VM の型ロードガードに違反し、Checked/Debug ランタイムで CoreLib 以外のモジュールロード中にアサートする可能性があるという High 重要度の指摘が 1 件未解決です（ステータス: 🟡 変更推奨）。
  • 現在の main では、classMustBeLoadedBeforeCodeIsRun が追加の依存関係を通じて eager な型ハンドルを保持し、eager インポートセクションがリロケーション由来のメソッドフィクスアップに対するプリコード出力を無効化するため、追加の依存関係対応は不要とされています。

#135804 Treat Wasm Vector<T> layout as fixed

  • 作成者: @davidwrighton
  • 作成日時: 2026年10月14日 21:50:47(UTC)
  • マージ日時: 2026年10月19日 22:51:19(UTC)
  • ラベル: area-ReadyToRun

概要

Wasm32 では System.Numerics.Vector<T> の幅が 128 ビットに固定されているため、そのレイアウトを固定として扱うように変更します。これにより、このターゲットでは実行時依存のベクターレイアウトチェック（ReadyToRun のフィックスアップ）が不要になります。含有型も、残りのレイアウトが version bubble 内で固定されていれば固定レイアウトになり得ます。他のターゲットでは従来どおり実行時依存のチェックを維持し、含有型に対する通常の version bubble 制限も維持されます。

変更内容

  • docs/design/coreclr/botr/readytorun-format.md: Wasm のベクターレイアウトが固定であるというルールを追記。
  • src/coreclr/tools/Common/Compiler/InstructionSetSupport.cs、src/coreclr/tools/Common/InstructionSetHelpers.cs: 命令セットサポート関連の小規模な変更（詳細な内容は提供情報からは不明）。
  • src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs: Wasm32 における固定レイアウト判定を追加（+2/-2）。
  • src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs、TestCases/Webcil/WasmSimdModule.cs、TestCasesRunner/TestPaths.cs: ベクター、ラッパー、ベクターを含むタプルを対象に、通常/コンポジット両方のコンパイルモードでレイアウトフィックスアップを検証するリグレッションテストを追加。

パフォーマンスへの影響

冗長なランタイム依存チェックの除去によるサイズ削減が見込まれます。以下は元の開発ブランチで測定した過去の値であり、今回抽出・リベースした PR での測定ではありません。JIT のハッシュはベースラインと更新後で一致しています（Brotli は quality 11、window 22）。

Wasm イメージ Raw 前 Raw 後 Raw 削減 Brotli 前 Brotli 後 Brotli 削減
Retail CoreLib 19,395,699 19,140,186 255,513 3,632,758 3,586,455 46,303
CoreLib + CallPerformance composite 13,123,330 12,834,328 289,002 2,875,741 2,844,264 31,477

これらはサイズの測定値であり、スループットのベンチマークではなく、現在の main で同等の削減が得られる保証もありません。

関連Issue

元の変更は dotnet/runtime#135553 から独立した部分として抽出されたものです（ソースコミット: 6a269adea70a2ea611bc2a3da78c43cdc08545c7）。Issue としての関連はなし。

その他

  • 本 PR は Draft です。このブランチでのビルド、ランタイムテスト、新規ベンチマークは未実施で、検証は未完了です（git diff --check のみ通過）。
  • 別件の canonical SIMD-root 除外、2 フェーズコンパイル、ダイレクトコール、プロローグ/フレーム識別の変更は含まれません。
  • Copilot のレビューでは、「ベクターをサポートしない（レイアウトが不確定な）ターゲットで、コンパイル済みのベクターメソッドを期待する無条件のリグレッションテストがある」ことが指摘されており（重要度 High）、Vector<T> の ReadyToRun テストをベクターサポートの有無で条件付けることが推奨されています。

#135801 Recognize static field intrinsics before Wasm static helpers

  • 作成者: @davidwrighton
  • 作成日時: 2026年10月14日 21:42:41(UTC)
  • マージ日時: 2026年10月19日 17:25:56(UTC)
  • ラベル: area-ReadyToRun

概要

Wasm向けReadyToRunコンパイルで、静的ベースヘルパーを選択する前に、既存の静的フィールドintrinsicを認識するよう修正します。IntPtr.Zero、UIntPtr.Zero、BitConverter.IsLittleEndian の読み取りは定数として、String.Empty は文字列ハンドルとして扱えるようになります。アドレス取得、書き込み、通常の静的フィールドアクセスは従来の処理を維持します（mainの IsThreadStaticForTarget(field) によるスレッド静的判定も保持）。これは dotnet/runtime#135553 から独立した修正だけを切り出したもので、two-phase compilation、direct call、prolog/frame-identity の変更は含みません。

変更内容

  • src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs: 静的ベースヘルパー選択の前にintrinsicを認識する処理を追加（+9/-8）
  • src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs: 最適化あり/なし、通常/コンポジットのコンパイルを網羅する回帰テスト（theory）を追加（+52）
  • src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/Webcil/WasmWebcilModule.cs: intrinsicの読み取りとアドレス取得の両方を対象とするフィクスチャを追加（+24）

パフォーマンスへの影響

元の開発ブランチで取得した、同一の入力アセンブリ・プロファイル・コンパイラオプション・参照・JITバイナリによる比較結果です（本PRで抽出・リベースしたブランチでの測定ではありません）。Brotliはquality 11、window 22で圧縮しています。

Wasmイメージ Raw 前 Raw 後 Raw 削減 Brotli 前 Brotli 後 Brotli 削減
Retail CoreLib 19,728,299 19,697,600 30,699 3,685,809 3,677,815 7,994
CoreLib + CallPerformance composite 13,481,936 13,454,067 27,869 2,941,278 2,935,335 5,943
  • 出力されたメソッド本体のノードサイズは、retailで30,932バイト、compositeで27,637バイト縮小し、ノード数は不変です。
  • 単体のintrinsic読み取りフィクスチャでは、ゼロとエンディアンの読み取りが Wasm 本体 47 → 17 バイトに縮小し、静的ベースヘルパー呼び出しが不要になりました。空文字列の読み取りは 47 → 24 バイトです。
  • アドレス取得を行うメソッド本体は変化していません。
  • これらはサイズとコード生成の結果であり、スループットのベンチマークではなく、現在のmainで同等の削減が得られる保証もありません。

関連Issue

  • 元となるPR: #135553（そこから独立した修正を抽出）

その他

  • 検証は git diff --check upstream/main...split/r2r-static-intrinsics のみ実施済みです。抽出された3ファイルの差分を確認し、分離状態と IsThreadStaticForTarget(field) 処理の維持を確認しています。
  • ビルド、ランタイムテスト、新規ベンチマークは、作成者の明示的な要望により未実施です。
  • 本PRはドラフトで、独立ブランチでのビルドおよびランタイム検証が残っています。
  • GitHub Copilotを用いて作成されています。

#135797 Fix background GC zeroing of arrays larger than 4 GiB

  • 作成者: @janvorli
  • 作成日時: 2026年10月14日 21:33:12(UTC)
  • マージ日時: 2026年10月19日 15:49:06(UTC)
  • ラベル: area-GC-coreclr

概要

バックグラウンドGC（BGC）中に割り当てられた4 GiBを超える配列が、ゼロ初期化されない問題を修正するPRです。

UOH（LOH/POH）の割り当てがBGCと重なる場合、make_unused_array が割り当て領域を一時的にフリーオブジェクトとして表現します。4 GiBを超える割り当てでは複数のピースが必要になることがあります。新規メモリ上でヘッダーだけをクリアすると、後続ピースに PREV_EMPTY フリーリストマーカーが残り、ゼロ初期化の保証が破られていました。

修正では、UnsetFree にオブジェクトサイズを渡し、ピースがフリーリストの前方ポインタを格納できる大きさであれば、そのポインタもクリアします。clear_unused_array はすでにすべての一時ピースを走査しているため、割り当てが返される前に各ピースのメタデータがクリアされます。

変更内容

  • src/coreclr/gc/gcinternal.h: UnsetFree がオブジェクトサイズを受け取り、ピースが十分大きい場合に前方フリーリストポインタをクリアするよう変更（+10/-1）
  • src/coreclr/gc/sweep.cpp: 上記に合わせて呼び出し側を更新（+4/-4）
  • src/tests/GC/LargeMemory/Regressions/BackgroundArrayZeroing.cs: BGC中に割り当てた4・6・8 GiB配列の全要素を検証する、プロセス分離・長時間実行のGC回帰テストを追加（+43）
  • src/tests/GC/LargeMemory/Regressions/BackgroundArrayZeroing.csproj: テストプロジェクトを追加。WASMと32bitアーキテクチャを除外し、Monoビルドは無効化、利用可能なGCメモリが16 GiB以上であることを要件とする（+21）

パフォーマンスへの影響

影響なし（提供された情報にパフォーマンスに関する記載はありません）。

関連Issue

#135791

その他

  • 内部のGC実装（ランタイム）の修正であり、公開APIや互換性への影響についての記載はありません。
  • PR説明およびコード変更はGitHub Copilotにより生成されたと記載されています。

#135790 Return generated GUIDs by value

概要

CoreCLR内部のGUID生成ヘルパーについて、出力ポインタ経由で結果を書き込む方式をやめ、GUIDを値渡し（戻り値）で返すように変更するリファクタリングです。あわせて、呼び出し元を更新し、GuidFromName を static にしています。GUID生成の挙動そのものは維持される旨がCopilotの概要に記載されています（ビルド・テストは未実施とのことです）。

変更内容

  • src/coreclr/inc/guidfromname.h: GUID生成関数の宣言を、GUIDを値で返す形に更新
  • src/coreclr/utilcode/guidfromname.cpp: GUIDを値で返す実装へ変更し、GuidFromName を static 化。不要になった出力バッファ関連のコメントを削除
  • src/coreclr/vm/comcallablewrapper.cpp: COMインターフェースGUIDの代入箇所を新しいシグネチャに合わせて更新
  • src/coreclr/vm/interoputil.cpp: GUIDを値で返すよう変更し、ラッパー呼び出し側を更新
  • src/coreclr/vm/interoputil.h: クラスインターフェース用ヘルパーの宣言を更新
  • src/coreclr/vm/methodtable.cpp: 戻り値のGUIDを代入する形に更新

内部実装（VM／utilcode）の変更であり、公開APIへの影響を示す情報は提供されていません。

パフォーマンスへの影響

影響なし（パフォーマンスに関する記載・ベンチマーク結果は提供されていません）

関連Issue

なし

その他

  • 例外処理および同期の挙動は維持されているとCopilotの概要に記載されています。
  • Copilotによる静的レビューでブロッキングとなる問題は見つかっていません。
  • 互換性への影響（破壊的変更・非推奨化）に関する記載はありません。

#135777 [release/11.0] [EventPipe] Align EventPipeThreadSamplingRate parsing on CoreCLR and NativeAOT

概要

DOTNET_EventPipeThreadSamplingRate 環境変数のパース方法をCoreCLRとNativeAOTで揃えるための修正です。CoreCLRでは本変数が16進数として解釈されていましたが、意図されたものではなく、NativeAOTとの挙動差が生じていました。本PRでは整数（10進数）として解釈するよう変更します。#135683 の release/11.0 へのバックポートです。

変更内容

  • src/coreclr/inc/clrconfigvalues.h（+1/-1）: EventPipeThreadSamplingRate の設定定義を、16進数ではなく整数として解析されるよう変更

パフォーマンスへの影響

影響なし

作成者によるローカル検証（minimal CoreCLRビルド）では、EventPipeトレースヘッダに記録されるサンプリング間隔が、変更前は16進数解釈、変更後は10進数解釈になることを確認しています。例として、値 10 は変更前は16ms、変更後は10msの間隔になります。

関連Issue

なし（元PR: #135683 のバックポート）

その他

  • 互換性: DOTNET_EventPipeThreadSamplingRate に値を指定している環境では、解釈が16進数から10進数に変わるため、実際のサンプリング間隔が変わる点に注意が必要です。
  • 回帰（Regression）ではないと記載されています。
  • リスクは低いとされており、変更対象は単一のEventPipe環境変数のパース方法のみです。
  • 顧客報告および社内調査で発見された問題とされています。ドキュメント上の記載（10進数的な説明）と実挙動が一致していなかった点が発端です。

#135768 Absolute/global addressing changes for native AOT/WASM

概要

NativeAOT/WASI向けに、CoreCLRのイメージベース相対アドレッシングではなく、リンカーが再配置する絶対アドレスを使用するよう変更します。「Console.WriteLine の hello world を WASI/NativeAOT でコンパイル・リンク・実行する」ための一連のPRの一部です。

主な内容:

  • 絶対アドレス（符号付き）定数とJITデータアドレスを、イメージベースのグローバル加算なしで出力
  • スカラーのグローバル load/store を、アドレスオペランドをゼロとした絶対memarg再配置に畳み込み
  • 関数ポインタの実体化を維持するため、関数を対象とする WASM_MEMORY_ADDR_SLEB 再配置をテーブルインデックス再配置にマッピング

emitImageBase() はR2R専用のままで、CoreCLRのイメージ相対パスは変更されません。WASI SDK clangの非PICグローバルアクセスモデルに合わせた設計です。

変更内容

  • src/coreclr/jit/codegenwasm.cpp: ゼロベースでの畳み込み済みグローバルアクセスを出力
  • src/coreclr/jit/emitwasm.cpp: 絶対アドレスとイメージ相対アドレスの出力を選択
  • src/coreclr/jit/lowerwasm.cpp: NativeAOTでグローバルアドレスの畳み込みを有効化
  • src/coreclr/jit/lir.h: FoldedAddr の拡張された意味を文書化（PRのCopilot要約による。変更ファイル一覧には含まれていません）
  • src/coreclr/tools/Common/Compiler/ObjectWriter/WasmRelocatableObjectWriter.cs: 絶対関数再配置をテーブルインデックスにマッピング

パフォーマンスへの影響

パフォーマンスに関する数値やベンチマーク結果は提供されていません。グローバルアクセスでイメージベースの加算が不要になり、絶対memarg再配置に畳み込まれる点は、生成コードの簡素化につながる可能性がありますが、具体的な効果は記載されていません。

関連Issue

なし

その他

  • 検証（作成者報告）:
    • build-runtime.cmd -checked -x64 -component wasmjit は成功
    • ローカルの verify-global-codegen.ps1 で10/10メソッドがコンパイル・オブジェクト/実行ファイル検証・Wasmtime実行に成功し、整数・long・double・アドレス取得・非ゼロフィールドオフセットの30件の値比較が成功
    • インターフェースコード生成のコントロールは Wasm 6/6、Windows x64 コンパイル 6/6 で成功
    • 実CoreLibのHelloバリアント2種を再コンパイル・リンク・実行に成功
  • 注意点: これらの結果はNativeAOT/Wasm有効化の前提を含む統合ローカルツリーのもので、このPR単独ブランチのビルドではありません。プローブスクリプトはローカルのフィクスチャで、PRには追加されていません。
  • Copilotレビューでは、Wasm IsNativeAot の絶対再配置に対するチェックイン済み回帰テストの追加が中程度の指摘として挙がっています（レビューはビルド・テストを実行していません）。

#135749 Update MsQuic to version 2.5.12

  • 作成者: @rzikm
  • 作成日時: 2026年10月14日 07:19:59(UTC)
  • マージ日時: 2026年10月19日 11:33:21(UTC)
  • ラベル: area-System.Net.Security

概要

MsQuicのバージョンを2.5.12に更新するPull Requestです。あわせて System.Net.Security の TlsSession に変更が入り、TlsSessionTests.cs に107行のテストが追加されています。

提供された情報には、MsQuic更新の目的や TlsSession.cs の変更の詳細は含まれていないため、それらについての記述は控えます。

変更内容

  • eng/Versions.props (+1/-1): MsQuicのバージョン定義を2.5.12に更新したものと考えられます（差分が1行の置換であることに基づく）。
  • src/libraries/System.Net.Security/src/System/Net/Security/TlsSession.cs (+9/-1): TlsSession の実装を変更しています（具体的な内容は提供情報からは不明）。
  • src/libraries/System.Net.Security/tests/FunctionalTests/TlsSessionTests.cs (+107/-0): TlsSession 関連の機能テストを追加しています。

パフォーマンスへの影響

影響なし（提供情報にパフォーマンスに関する記述・ベンチマーク結果はありません）

関連Issue

なし

その他

  • 作成者による概要・Copilotによる概要はいずれも提供されていないため、公開API・互換性・セキュリティ修正への影響を判断する情報はありません。
  • TlsSession.cs の変更とMsQuic 2.5.12への更新との関連性は、提供情報からは確認できません。

#135748 Improve tar symlink validation during extraction

  • 作成者: @rzikm
  • 作成日時: 2026年10月14日 07:16:58(UTC)
  • マージ日時: 2026年10月19日 11:34:19(UTC)
  • ラベル: area-System.Formats.Tar

概要

System.Formats.Tar のアーカイブ展開時に行うシンボリックリンクの検証を改善するPRです。親ディレクトリ参照（..）を含むシンボリックリンクの追跡を、アーカイブ内で実際にそのようなシンボリックリンクに遭遇した場合のみに限定し、オーバーヘッドを削減します。あわせて、既存のシンボリックリンクを辿らなくなっていたリグレッションを修正します。

変更内容

  • TarEntry.cs: 展開処理の変更（+118/-29）
  • TarFile.cs: 展開処理の変更（+17/-12）
  • TarHelpers.cs: シンボリックリンク検証関連の処理を追加（+320）
  • TarHelpers.Unix.cs / TarHelpers.Windows.cs: プラットフォーム別の処理を追加（それぞれ +41 / +62）
  • Strings.resx: リソース文字列の変更（+4/-1）
  • System.Formats.Tar.csproj: プロジェクト設定の変更（+2）
  • TarFile.ExtractToDirectory.File.Tests.cs: ファイル展開テストを大幅に追加（+499/-7）

パフォーマンスへの影響

親 .. シンボリックリンクの追跡を、アーカイブ内でそのようなリンクに遭遇した場合のみに限定することで、通常ケースのオーバーヘッドを削減します。ベンチマーク結果は提供されていません。作成者によると、最適化のアイデアは他にもあり、#135128 の対応を継続する位置づけです。

関連Issue

その他

既存のシンボリックリンクを辿らなくなっていたリグレッションの修正を含みます。

#135734 Make TryGetSymbol cross-os

  • 作成者: @rcj1
  • 作成日時: 2026年10月14日 00:10:02(UTC)
  • マージ日時: 2026年10月19日 21:46:57(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

TryGetSymbol が、ホストのアーキテクチャ・OSに依存せず、すべてのアーキテクチャ/OS向けのモジュールに対して動作するようにするための変更です。作成者の説明によれば、これがこのPRの目的です。

主な変更は dbgutil 配下に集中しており、ELF/Mach-O のシンボル解決処理（elfreader、machoreader）の見直しと、新規ファイル symbol.cpp の追加が含まれます。

変更内容

  • src/coreclr/debug/dbgutil/elfreader.cpp (+253/-157): ELFリーダーの実装を大幅に変更
  • src/coreclr/debug/dbgutil/elfreader.h (+56/-21): ELFリーダーの宣言を更新
  • src/coreclr/debug/dbgutil/machoreader.cpp (+13/-23): Mach-Oリーダーの実装を変更
  • src/coreclr/debug/dbgutil/machoreader.h (+64/-0): 新規にヘッダーの内容を追加
  • src/coreclr/debug/dbgutil/symbol.cpp (+77/-0): 新規ファイル。シンボル取得関連の実装を追加
  • src/coreclr/debug/dbgutil/dbgutil.cpp (+3/-14): 既存実装の整理（削除中心）
  • src/coreclr/debug/dbgutil/CMakeLists.txt (+4/-17): ビルド定義を変更（削除が中心）
  • src/coreclr/debug/inc/dbgutil.h (+6/-0): 宣言を追加
  • src/coreclr/debug/createdump/crashinfo.h (+1/-1): 軽微な修正

影響範囲は、公開APIではなくランタイム内部のデバッグ/ダンプ関連ユーティリティ（dbgutil、createdump）です。

パフォーマンスへの影響

影響なし（提供された情報にはパフォーマンスに関する記載やベンチマーク結果はありません）

関連Issue

なし

その他

  • 提供情報からは、互換性への影響（破壊的変更・非推奨化）やセキュリティ修正に関する記載は確認できません。
  • 個々の変更の詳細（関数単位の挙動変更など）は、提供された情報からは判断できません。

#135733 Merging internal commits for release/8.0

概要

release/8.0 ブランチへ内部コミットをマージするPRです（作成者による説明はなく、変更ファイルから読み取れる範囲で整理しています）。変更は主に以下の領域に及びます。

  • CoreCLR PAL: 名前付きミューテックスと共有メモリ（sharedmemory）の実装の大規模な改修
  • System.Formats.Cbor: CborReader への追加のチェック（リソース文字列の追加など）
  • System.Formats.Tar: 展開処理（TarEntry / TarFile / TarHelpers）の変更とテスト追加
  • System.Net.Http: RedirectHandler.cs の変更とプロキシ関連テストの追加
  • System.Private.CoreLib: DateTimeParse.cs の変更
  • eng/Versions.props のバージョン変更（+1/-1）

サンプルコードは提供情報にありません。

変更内容

  • PAL（CoreCLR）
    • sharedmemory.cpp（+1107/-241）、sharedmemory.h、mutex.cpp（+225/-63）、mutex.hpp、pal.h（+19）を中心に変更
    • sharedmemory.inl を削除（-21）
    • qcallentrypoints.cpp に +2行
    • テスト NamedMutex/test1/namedmutex.cpp（+217/-12）を拡充し、nopal.cpp（+226）を新規追加
  • System.Formats.Cbor
    • CborReader.cs（+33）、CborReader.Array.cs / CborReader.Map.cs（各+1）、CborReader.String.cs（+4）を変更
    • Strings.resx（+3）と csproj を更新
    • CborReaderTests.cs（+92）と CborReaderTests.SkipValue.cs を更新
  • System.Formats.Tar
    • TarEntry.cs（+104/-107）、TarFile.cs（+10/-10）を変更
    • TarHelpers.cs（+329）、TarHelpers.Unix.cs（+41）、TarHelpers.Windows.cs（+63/-2）を拡張
    • Strings.resx（+9）と csproj を更新
    • TarFile.ExtractToDirectory.File.Tests.cs（+465/-3）にテストを追加
  • System.Net.Http
    • SocketsHttpHandler/RedirectHandler.cs（+2/-1）を変更
    • HttpClientHandlerTest.Proxy.cs（+106）にテストを追加し、LoopbackProxyServer.cs を調整
  • System.Private.CoreLib
    • DateTimeParse.cs（+19/-2）を変更
  • その他 47 ファイルも変更されていますが、提供情報からは内容を確認できません。

パフォーマンスへの影響

提供情報にはベンチマークや性能に関する記述がなく、影響は不明です。

関連Issue

なし

その他

  • 公開APIの追加・変更や互換性への影響、セキュリティ修正（CVE番号など）の有無は提供情報から判断できません。
  • 内部コミットのマージであり、修正の背景や詳細は提供された情報からは確認できません。

#135728 Merging internal commits for release/9.0

概要

release/9.0ブランチへ内部コミットをマージするPRです（作成者による説明はありません）。変更ファイルからは、(1) Unix PALの名前付きMutex/共有メモリ実装の大規模な書き換え、(2) System.Formats.Cbor のリーダー変更、(3) System.Formats.Tar の展開処理の変更、(4) System.Net.Http のリダイレクト/プロキシ関連の変更、が含まれていることが読み取れます。eng/Versions.props も更新されています。

変更内容

  • eng/Versions.props: 1行変更（バージョン関連の更新）。
  • CoreCLR PAL（Unix）の名前付きMutex/共有メモリ:
    • src/coreclr/pal/src/sharedmemory/sharedmemory.cpp（+1213/-415）、sharedmemory.h（+137/-40）、sharedmemory.inl（-21）を大幅に変更。
    • src/coreclr/pal/src/synchobj/mutex.cpp（+188/-57）、mutex.hpp、pal.h、pal_error.h、init/pal.cpp を変更。
    • src/coreclr/System.Private.CoreLib/.../Mutex.CoreCLR.Unix.cs（+30/-7）を変更。
    • src/coreclr/pal/tests/palsuite/threading/NamedMutex/test1/ の namedmutex.cpp（+151）、nopal.cpp（+35）にテストを追加。
  • System.Formats.Cbor:
    • CborReader.cs（+33）、CborReader.Array.cs、CborReader.Map.cs、CborReader.String.cs に変更を追加。
    • Strings.resx にリソース文字列を3行追加。
    • CborReaderTests.cs（+92）、CborReaderTests.SkipValue.cs にテストを追加・更新。
  • System.Formats.Tar:
    • TarEntry.cs（+94/-107）、TarFile.cs、TarHelpers.cs（+319）、TarHelpers.Unix.cs（+41）、TarHelpers.Windows.cs（+62/-1）を変更。
    • System.Formats.Tar.csproj と Strings.resx（+9）を更新。
    • TarFile.ExtractToDirectory.File.Tests.cs（+463/-3）にテストを追加。
  • System.Net.Http:
    • SocketsHttpHandler/RedirectHandler.cs（+2/-1）を変更。
    • HttpClientHandlerTest.Proxy.cs（+106）、LoopbackProxyServer.cs にテストを追加・更新。
  • その他42ファイルが変更されています（内容は提供情報からは不明）。

パフォーマンスへの影響

提供された情報からは判断できません（ベンチマーク結果の記載なし）。

関連Issue

なし

その他

  • PRタイトルからリリースブランチ向けの内部コミットのマージですが、各変更の目的（セキュリティ修正かどうか、CVE番号など）は提供情報に含まれていないため、本要約では断定していません。
  • 変更規模が最も大きいのはUnix PALの共有メモリ実装（sharedmemory.cpp）で、名前付きMutexの動作に影響する可能性があります。詳細はPR本文・個別コミットをご確認ください。

#135700 Fix TlsSession's ClientHello peek failure message

概要

Linux上でサーバー側の TlsSocketSession がソケットから ClientHello を読み取れなかった場合（クライアントが完全なTLSレコード到着前に切断/リセットした場合、またはレコードヘッダが読み取りバッファより大きいサイズを示した場合）に出る例外メッセージを修正します。

従来は SR.Format を通さず IOException(SR.net_ssl_read_bio_failed_error) を投げていたため、メッセージが SSL Read BIO failed with OpenSSL error - {0}. とプレースホルダーのまま表示されていました。また、CryptoNative_BioPeekTlsFrame は入口でOpenSSLのエラーキューをクリアし、-1 を返す経路でもエラーをプッシュしないため、フォーマットしても名前を示せるOpenSSLエラーが存在しません。そのためプレースホルダーを持たない新しいリソース文字列 net_ssl_read_client_hello_failed（"The TLS ClientHello could not be read from the socket."）を使い、同じ IOException を投げるように変更しました。

変更内容

  • src/libraries/System.Net.Security/src/Resources/Strings.resx: 新規リソース net_ssl_read_client_hello_failed を追加（+3）
  • src/libraries/System.Net.Security/src/System/Net/Security/TlsSession.OpenSsl.cs: ClientHello の peek 失敗時に新リソースを使った IOException を投げるよう変更（+3/-1）。Interop.OpenSsl.CreateSslException 経由の net_ssl_read_bio_failed_error の他の使用箇所は変更なし
  • src/libraries/System.Net.Security/tests/FunctionalTests/TlsSessionTests.cs: Linux向けの新規テスト SocketBoundServerSession_ClientHelloPeekFails_ThrowsIOExceptionWithMessage を追加（+67）
    • 3つのケース: クライアントが送信側をシャットダウン、クライアントが接続をリセット、クライアントが65535バイトのフラグメントを示すハンドシェイクレコードヘッダを送信
    • 各ケースでサーバーセッションの Handshake() を実行し、IOException が投げられ、そのメッセージに {0} も OpenSSL も含まれないことを検証
    • 旧コードでは全ケースが失敗し、修正後は成功

パフォーマンスへの影響

影響なし

関連Issue

#135694（Resolves）

その他

  • 報告されたテスト結果: Linux x64（Ubuntu 22.04.5 LTS、WSL2、OpenSSL 3.0.2）で System.Net.Security の機能テストが、変更ありで成功しています（OuterLoopテストは未実行）。ただし NegotiateAuthenticationKerberosTest は変更の有無にかかわらず同様に失敗します。
  • 例外の型（IOException）は変わらず、メッセージ内容のみが変更されます。

#135626 Fix GNU sparse 1.0 maps spanning multiple TAR records

  • 作成者: @rzikm
  • 作成日時: 2026年10月12日 15:20:04(UTC)
  • マージ日時: 2026年10月19日 11:43:33(UTC)
  • ラベル: area-System.Formats.Tar

概要

GNU sparse 1.0 形式のPAXエントリで、埋め込まれたスパースマップが約1 KiBを超えると、有効なデータにもかかわらず InvalidDataException がスローされる問題の修正です。リフィル（再読み込み）時の容量チェックが、次回のコンパクション時に破棄される「消費済みバイト」まで含めて計算していたことが原因です。修正後は未読バイトのみで容量を計算します。固定1 KiBバッファ、1,000,000セグメントの割り当て上限、数値行の境界チェック、レコード境界に揃ったパックデータの位置決めは維持されます。

変更内容

  • src/libraries/System.Formats.Tar/src/System/Formats/Tar/GnuSparseStream.cs (+2/-3): リフィル容量の判定を未読バイトのみで計算するよう修正
  • src/libraries/System.Formats.Tar/tests/TarReader/TarReader.SparseFile.Tests.cs (+216/-19): 回帰テストを追加
    • レコード境界ちょうどのケース、報告された1,006バイト・1,062バイトのマップ、8,193バイトのマップ
    • 同期/非同期の読み取りと展開、データのコピーあり/なし、シーク不可の入力、次エントリのアライメント、不正なマップ

パフォーマンスへの影響

影響なし（固定1 KiBバッファは維持）。ベンチマーク結果の記載もありません。

関連Issue

#134980（Fixes / Resolves）

その他

  • 検証内容（Windows x64）:
    • GnuSparseStream 関連のテストクラス（TarReader_SparseFileTests）159ケースのうち、修正前は有効なマップを扱う32ケースが失敗し、修正後は全て成功
    • System.Formats.Tar の標準テスト7,084件が全て成功（スキップなし）
    • 元のIssueで報告された2つのアーカイブは、同期/非同期の読み取りとディレクトリ展開に成功。展開後の長さとSHA-256ハッシュは Python の tarfile の結果と一致
  • 非Windows環境でのテスト実行と、数GB規模の手動ストレステストは未実施です。

#135449 Zero-initialize the return-value range in the Leave2 slow path

概要

プロファイラAPIの ProfileLeave における Leave2 スローパスで、COR_PRF_FUNCTION_ARGUMENT_RANGE argumentRange が未初期化のまま ProfilingGetFunctionLeave3Info に渡され、そのポインタがプロファイラの FunctionLeave2 フックに渡されていました。この変更でゼロ初期化し、フックには空のレンジが渡されるようにします。

問題の経緯（PR記述より）:

  • スローパスは COR_PRF_ENABLE_FRAME_INFO、COR_PRF_ENABLE_STACK_SNAPSHOT、COR_PRF_ENABLE_FUNCTION_RETVAL のいずれかで有効になる
  • しかしクエリがレンジを書き込むのは COR_PRF_ENABLE_FUNCTION_RETVAL が設定されている場合のみ
  • イテレータの割り当てに失敗した場合は、何も書き込まずに E_UNEXPECTED を返す
  • これらのケースでは、フックにスタック上の不定値が渡されていた

変更内容

  • src/coreclr/vm/proftoeeinterfaceimpl.cpp (+4/-1): Leave2 スローパスで argumentRange をゼロ初期化

パフォーマンスへの影響

影響なし（構造体のゼロ初期化のみ）。ただし、挙動の検証結果は以下のとおりです。

  • 検証条件: COR_PRF_ENABLE_FRAME_INFO を有効にし、COR_PRF_ENABLE_FUNCTION_RETVAL を有効にしない FunctionLeave2 フックで、レンジの2フィールドのみを読む（Release ビルド）
  • linux-x64
    • 変更前: Leave2 呼び出しの約85%で非空のレンジが渡された（ある実行では3226件中2730件）。長さは約2GB、開始アドレスはスタックアドレスだった
    • 変更後: 3回の実行それぞれ約3300件中0件
    • 変更を戻すと不定値が再現した
  • Windows x64
    • 変更前: 113,064件中109,031件が非空
    • 変更後: 113,072件中0件

関連Issue

  • #131985 の議論（サスペンション時の Leave に関する議論）で、このクエリが CORPROF_E_DATAINCOMPLETE を返す案が検討されている。その場合、レンジを書き込まない経路がさらに増える

その他

  • FunctionLeave2 のドキュメントでは戻り値情報の取得に COR_PRF_ENABLE_FUNCTION_RETVAL が必要とされているため、ドキュメントに従うプロファイラはこの構成でレンジを読まない。それでも、フックに不定な構造体へのポインタが渡されていた点が修正対象
  • テスト: 上記の実験に加え、linux-x64 Release で src/tests/profiler 配下が通ることを確認済み（無関係な AMD64 プロファイラ修正との併用、main の dca76ff 時点）。タイアードコンパイルが無効な場合のみ動作する4テストは DOTNET_TieredCompilation=0 で実行
  • 未検証・未対応: 割り当て失敗パスは実行されていない。Enter2 はクエリ自身の割り当てに失敗した場合、割り当て済みの引数バッファが未充填のまま残るが、この PR では変更・検証していない。Tailcall2 にはレンジがない

#135219 Filter leading GC polling frames from EventPipe stacks.

  • 作成者: @lateralusX
  • 作成日時: 2026年10月05日 14:51:07(UTC)
  • マージ日時: 2026年10月19日 08:11:09(UTC)
  • ラベル: area-VM-coreclr

概要

EventPipeのスタックウォークにおいて、スタック先頭に現れるGCポーリング用フレーム（PollGC / PollGCWorker）を除外する変更です。非インライン化された PollGCWorker ヘルパーをバインダから参照可能にし、マネージドコード実行前にバインドしておくことで、サスペンド中にメソッドをロードすることなくスタックウォーク側がポーリングヘルパーを認識できるようにします。除外対象は先頭の PollGC と PollGCWorker フレームのみで、呼び出し元フレーム、サンプル、分類は維持されます。

変更内容

  • src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.Multithreading.cs: PollGCWorker を非インライン化されたバインダ参照可能なヘルパーとして扱うための変更（+5/-3）
  • src/coreclr/vm/corelib.h: PollGCWorker に対応するエントリの追加（+3）
  • src/coreclr/vm/appdomain.cpp: マネージドコード実行前にヘルパーをバインドする処理の追加（+4）
  • src/coreclr/vm/eventing/eventpipe/ep-rt-coreclr.cpp: 共有EventPipeスタックウォーカーで、先頭の PollGC / PollGCWorker フレームのみを除外する処理を追加（+11/-1）
  • src/tests/tracing/eventpipe/eventsvalidation/SampleProfilerSampleType.cs: JITおよびrundownのメソッド範囲を用いた生スタックの回帰テストを追加（+210）。呼び出し元フレームの保持と通常のイベントスタックを検証し、セーフポイントの経路が異なるインタープリタ構成は対象外

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載はなし）

関連Issue

#135050（Fixes）

その他

なし

#135167 Enable Unix domain sockets on iOS and tvOS

概要

iOS/tvOSでUnixDomainSocketEndPointがPlatformNotSupportedExceptionをスローしていた問題を修正し、Unixドメインソケットを有効化します。SocketProtocolSupportPalがiOS/tvOSでAF_UNIXを無条件に未サポートとして扱っていた除外を削除し、既存のネイティブプローブを使用するようにしました。WASIの明示的な除外は維持されます。

変更内容

  • SocketProtocolSupportPal.Unix.cs: iOS/tvOSの除外を削除し、既存のネイティブプローブを使用
  • Socket.cs: Socket(SafeSocketHandle)でアドレスファミリを直接取得できない場合、getsocknameからアドレスファミリを復元するフォールバックを追加（Appleシミュレータの機能CIで、クローンされたUnixソケットのファミリ不明・エンドポイントnull・Connected == falseが発生したため）
  • PlatformDetection.Sockets.cs（新規）/TestUtilities.csproj: キャッシュされたPlatformDetection.SupportsUnixDomainSocketBinding条件を追加。iOS/tvOSでは共有ソケットディレクトリを1回プローブし、BindがAccessDeniedを返す場合のみバインド不可と判定（他のバインドエラーは隠さない）
  • UnixDomainSocketTest.cs: iOS/tvOS向けの回帰テスト（サポート有無、ソケット/エンドポイント構築、バインドなしでのSafeHandleからのアドレスファミリ再構築）を追加。既存の接続済みクローンテストにファミリとエンドポイントのアサーションを追加。Appleのアプリコンテナ向けに短い名前と短いUTF-8表現の一時ディレクトリを使用するよう調整。サーバーのnull許容クリーンアップを修正し、セットアップ失敗を隠さないようにした
  • SocketsHttpHandlerTest.cs: ConnectCallbackテストを同様に調整（ソケットテストと一時ディレクトリ選択を共有、HTTPクライアントとサーバーは同じディレクトリを使用、識別子は数値URIホスト正規化を避けるため英字で開始）

パフォーマンスへの影響

影響なし

関連Issue

#96143（Resolves）

その他

  • 互換性: iOS/tvOSでこれまでPlatformNotSupportedExceptionとなっていたUnixドメインソケットが利用可能になります。ただしAppleサンドボックスで許可されたパスに限られ、ファイルシステムへのバインドが拒否される環境ではBindがAccessDeniedとなり得ます。
  • 検証結果（作者報告）:
    • Linux arm64（Mono JIT/Interpreter）: UnixDomainSocketTest 21件成功、ConnectCallback_UseUnixDomainSocket_Success 各4件成功
    • AppleシミュレータのCoreCLR（コミット75f6cb8c）: iOS x64/arm64は21成功/1スキップ/0失敗、tvOSは7成功/15スキップ/0失敗（サンドボックスがBindを拒否するためバインド系はスキップ）
    • Apple向けのフルパイプラインにはOpenSSLネイティブライブラリ欠如、JIT/ランタイム失敗、タイムアウトなどの失敗が残っています。また、キャッシュ条件へのリファクタ（054c7c90a）後のApple検証は未実施です。
    • ローカルmacOS arm64ではXcode/Swiftライブラリ不足によりILCompilerの発行を完了できず、ローカルのデバイス/シミュレータテストは未実施です。

#134987 Check the RESOLVE_UPDATE_METADATA_1 result hr in CordbModule::RefreshMetaData

概要

CordbModule::RefreshMetaData（デバッガ側 DBI）が、ランタイムからの DB_IPCE_RESOLVE_UPDATE_METADATA_1 応答に含まれる失敗 hr を無視していた問題の修正です。メタデータのシリアライズに失敗してもバッファ無しのまま処理が続行され、ランタイムの本来のエラーが E_INVALIDARG やアドレス0の読み取り失敗といった二次的な失敗に隠れていました。本PRでは、応答のバッファ関連フィールドを使用する前に応答の hr を確認し、失敗時はそのエラーを返すようにします。

変更内容

  • src/coreclr/debug/di/module.cpp（+4/-0）
    • RefreshMetaData で、SendIPCEvent の結果に加えて応答ヘッダの hr を確認する処理を追加。バッファの使用やクリーンアップの設定よりも前に行われます。
    • 失敗時、ランタイム側はバッファを返さないため解放処理は不要です。

パフォーマンスへの影響

影響なし（エラー経路での hr チェック追加のみ）。

関連Issue

  • #134714（検証に使用したリプロ・関連の議論として言及）
  • #134717（本件の発見元レビュー対象。Linuxで該当経路を実行するにはその修正が必要）

その他

  • 自動テストは含まれていません。10.0.12 linux-x64 リリースビルドでのフォールトインジェクションにより手元で検証しています（障害なし時は score = 42 が取得でき、障害あり時は修正前が E_INVALIDARG、修正後がランタイムの E_ACCESSDENIED を返すことを確認）。ただしデバッガの表示上はどちらも「ローカル変数なし」で、差は返される hr にのみ現れます。
  • 検証の限界: シリアライズ前の失敗（既存のインポータあり）のみを対象としており、GetSaveSize 後の失敗は対象外です。
  • 潜在的な挙動変更: インポータが存在しない場合、GetMetaDataImporter は RefreshMetaData を ALLOW_DATATARGET_MISSING_MEMORY で囲み、メタデータロケータにフォールバックします。本変更により、シリアライズが後段で失敗した場合にランタイムの HRESULT（例: E_OUTOFMEMORY）がそのまま伝播し、このリカバリ経路を迂回する可能性があります。サポート対象の使用で到達可能かは未確認です。
  • スコープ: debug/di で応答ペイロードを使用する呼び出し元のうち、応答の hr を確認も伝播もしていないのは RefreshMetaData のみとのことです。逆の問題（SendIPCEvent の結果を確認せず応答の hr を返す）を持つ DisableOptimizations などは本PRでは変更しません。
  • AI（Anthropic Claude、OpenAI Codex）の支援を受けて作成されたと記載されています。

#125304 Use ICollection<T> check instead of IList<T> in TryCopyTo

概要

System.Collections.Immutable 内部の ImmutableExtensions.TryCopyTo において、型チェックを IList<T> から ICollection<T> に変更しました。これにより、IList<T> を実装せず ICollection<T> のみを実装するコレクション（例: Dictionary<K,V>.Keys / Values）でも ICollection<T>.CopyTo が呼び出されるようになり、要素ごとの列挙によるフォールバックを避けられます。

変更内容

  • ImmutableExtensions.Minimal.cs（+10/-28）
    • 型チェックを IList<T> から ICollection<T> に変更
    • List<T>、T[]、ImmutableArray<T> のいずれにも一致しない場合は ICollection<T>.CopyTo にフォールバック
    • .NET Framework での配列の共変性による問題を避けるため、#if NET による条件付きコンパイルを追加し、ICollection<T>.CopyTo にフォールバックする前にシーケンスが配列でないことを確認
  • CopyToTrackingCollection.cs（新規、+41）: CopyTo の呼び出しを追跡するテスト用コレクションを追加
  • ImmutableArrayBuilderTest.cs（+29）、ImmutableArrayTest.cs（+27）: テストを追加
  • System.Collections.Immutable.Tests.csproj（+1）: 新規テストファイルをプロジェクトに追加

パフォーマンスへの影響

ICollection<T> を実装するコレクションで、要素ごとの列挙の代わりに CopyTo による一括コピーが使われるため、改善が見込まれます。LINQ の ToArray が既に ICollection<T> パスを採用している点も背景として挙げられています。ベンチマーク結果はこちらのコメントに記載されています。

関連Issue

#88181

その他

  • Copilot のレビューでは、ICollection<T>.CopyTo フォールバックが不変性（immutability）に関するリスクを生む可能性がある点、およびテストが新しいパスの使用を検証できていない可能性がある点が指摘されています（「Changes recommended」）。
  • 内部実装の変更であり、公開 API の変更はありません。
目次