Pull Request on 2026年10月22日

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

注意点

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

目次

  1. #136301 Ignore empty Alt-Svc values instead of throwing NullReferenceException
  2. #136297 [RISC-V] Fix 64-bit constant truncation on LLP64 hosts
  3. #136290 [cDAC] Use hierarchical Directory.Build.props import
  4. #136276 Disable ilasm round-tripping for TLS test
  5. #136270 Define NativeAOT WebAssembly async continuation global
  6. #136269 Link wasi-emulated-getpid on native AOT
  7. #136265 Initialize NativeAOT library GS cookie before first managed call
  8. #136260 JIT: Clear GC poll flags when converting unreachable blocks to throws
  9. #136250 [wasi] Fix EINVAL from UDP Socket.ReceiveAsync
  10. #136249 Treat path-shaped assembly-name strings as unresolved in ILLink
  11. #136243 [wasi] Accept explicit return in WASI R2R host constant exports
  12. #136241 Replace CheapUnfairReaderWriterLock with ReaderWriterLockSlim
  13. #136238 Seed innerloop build caches from main
  14. #136230 [release/10.0] Source code updates from dotnet/dotnet
  15. #136229 [release/11.0] Source code updates from dotnet/dotnet
  16. #136221 Use extension-member polyfills across libraries
  17. #136209 Clear Zstandard prefixes and restore dictionaries on reset
  18. #136208 Fix NativeAOT WASM math helper calling conventions
  19. #136203 Fix virtual vtable call lowering without fixed registers
  20. #136185 OpenHarmony: NativeAOT and pack integration
  21. #136160 Root String constructor factories in ReadyToRun compilation
  22. #136136 Fix JsonArray lazy list initialization race
  23. #135970 JIT: treat throwing trees as GC safe points
  24. #135839 native: use the C90 qsort workaround for zstd on OpenHarmony
  25. #135342 Mitigate macOS FSEvents race in TokensFiredForNewDirectoryContentsOnRename
  26. #135312 Managed ilasm: record sequence points as instructions are emitted, on the lines of the .il source when no .line directive is in effect
  27. #135122 Optimize System.Numerics.Tensors dense and strided operations
  28. #134908 Update Fedora Helix coverage to 45
  29. #128981 System.Net.Mail Validation improvements

#136301 Ignore empty Alt-Svc values instead of throwing NullReferenceException

概要

Alt-Svc ヘッダーが空、または区切り文字のみ（Alt-Svc: や Alt-Svc: ,）の場合、AltSvcHeaderParser は null のパース結果を返します。#114528 以降、HandleAltSvc はその値が non-null であることを assert した上で参照するため、Release ビルドでは HTTP/3 サポートが有効（既定）な状態で、該当ヘッダーを持つ HTTPS レスポンスを受け取ると NullReferenceException が発生していました。これは HTTP/1.1 や HTTP/2 のリクエストでも発生します。

本PRでは AltSvcHeaderValue にパースされない値をスキップするようにし、.NET 9 の挙動を復元します。

変更内容

  • src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectionPool/HttpConnectionPool.Http3.cs（+3/-5）
    • AltSvcHeaderValue にパースされない値をスキップするよう変更
  • src/libraries/System.Net.Http/tests/FunctionalTests/SocketsHttpHandlerTest.cs（+26/-0）
    • 空の値および区切り文字のみの値を、HTTP/1.1 と HTTP/2 で検証する機能テストを追加

パフォーマンスへの影響

影響なし

関連Issue

#136291（本PRで修正） 関連: #114528（回帰の契機となった変更）

その他

  • 内部実装（SocketsHttpHandler の HTTP/3 の Alt-Svc 処理）の修正で、公開APIの変更はありません。
  • .NET 9 の挙動を復元するバグ修正です。

#136297 [RISC-V] Fix 64-bit constant truncation on LLP64 hosts

概要

RISC-V64向けJITの emitLoadImmediate において、64ビット定数をデータセクションから ld でロードするフォールバック経路で、スロットのサイズ算出に sizeof(long) を使用していたバグを修正します。LLP64ホスト（Windows）では long が4バイトのため、Windows上で動作するクロスJIT（riscv64ターゲット）が定数の下位4バイトしか出力していませんでした。サイズ算出を sizeof(originalImm) に変更し、定数全体（8バイト）が出力されるようになります。

PRの記載によると、Issueの再現例（ulong / 10）での __managedcode の ld ターゲットは以下のように変化します。

修正前:

0030 cdcccccc 00000000 00000000 00000000

修正後:

0030 cdcccccc cccccccc 00000000 00000000

変更内容

  • src/coreclr/jit/emitriscv64.cpp（+1/-1）
    • emitLoadImmediate 内の64ビット定数のデータセクション配置時のサイズ指定を sizeof(long) から sizeof(originalImm) に変更

パフォーマンスへの影響

影響なし（誤ったコード生成の修正であり、パフォーマンス改善を目的とした変更ではありません）

関連Issue

#136034（本PRで修正）

その他

  • ホストのデータモデル依存（LLP64とLP64の違い）に起因する問題で、Linuxなど long が8バイトの環境では顕在化しません。
  • 影響を受けるのは、Windowsホスト上のクロスJITによるriscv64向けコード生成です。

#136290 [cDAC] Use hierarchical Directory.Build.props import

概要

cDACサブツリー内の Directory.Build.props が、親ディレクトリの Directory.Build.props を取り込む方法を、標準の階層的な探索（hierarchical lookup）を使うように変更したPRです。これにより、プロダクションソースが別のリポジトリ構成にミラーされた場合でもサブツリーを再配置（relocatable）できます。ミラー先にアダプターをソースツリー内に用意する必要もなくなります。

変更内容

  • src/native/managed/cdac/Directory.Build.props（+1/-1）
    • 親の Directory.Build.props の取り込み方法を、標準的な階層的探索を使う形に変更。

パフォーマンスへの影響

影響なし（ビルド構成の変更のみ）。

関連Issue

なし

その他

  • 検証として、.\dotnet.cmd build src\native\managed\cdac\cdac.slnx -c Debug -p:RuntimeConfiguration=Debug -p:LibrariesConfiguration=Release が警告0・エラー0で成功したと記載されています。
  • 公開APIや実行時の挙動への変更、互換性への影響に関する記載はありません。

#136276 Disable ilasm round-tripping for TLS test

  • 作成者: @Copilot
  • 作成日時: 2026年10月22日 06:26:28(UTC)
  • マージ日時: 2026年10月22日 21:40:44(UTC)
  • ラベル: area-ILTools-coreclr

概要

TestTLSWithLoadedDlls テストを、ilasm ラウンドトリップ（IL の逆アセンブル→再アセンブル）の対象から除外する変更です。このテストが依存する IJW（C++/CLI）アセンブリにはネイティブコードが含まれており、ilasm によるラウンドトリップと互換性がないためです。

変更内容

  • src/tests/JIT/Directed/tls/TestTLSWithLoadedDlls.csproj（+2/-0）
    • ilasm ラウンドトリップ非対応であることを示す設定を追加（具体的な設定内容は提供情報に含まれていないため不明）

パフォーマンスへの影響

影響なし（テストプロジェクトの設定変更のみで、ランタイム/ライブラリの実装・公開APIへの変更はありません）

関連Issue

なし

その他

  • 変更対象はテストプロジェクトの設定のみで、互換性や破壊的変更への影響はありません。
  • 提供された情報には、diff の詳細や関連Issueの記載がないため、追加の背景は不明です。

#136270 Define NativeAOT WebAssembly async continuation global

概要

NativeAOT の WebAssembly 向けに、非同期継続（async continuation）用のミュータブルなグローバル変数を portable runtime 側で定義し、再配置可能な WASM オブジェクトでは正しいシンボル種別でインポートするようにする変更です。

変更内容

  • src/coreclr/nativeaot/Runtime/CMakeLists.txt（+1/-0）: wasm 向けのビルド設定を追加。詳細は提供情報からは不明です。
  • src/coreclr/nativeaot/Runtime/wasm/MiscStubs.cpp（+7/-0）: 非同期継続のミュータブルなグローバルを定義。
  • src/coreclr/tools/Common/Compiler/ObjectWriter/WasmRelocatableObjectWriter.cs（+1/-0）: 再配置可能な WASM オブジェクトでこのグローバルを正しいシンボル種別でインポートするよう修正。

影響範囲は NativeAOT のランタイム（wasm 部分）とコンパイラ側の ObjectWriter であり、公開 API の変更や互換性への影響についての記載はありません。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

なし

#136269 Link wasi-emulated-getpid on native AOT

概要

WASI向けNative AOTのビルドで、wasi-emulated-getpid をリンクするように変更するPRです。ランタイムのソースをビルドする際（src/coreclr/CMakeLists.txt）に既にこのエミュレーションが定義されており、リンク時にも同じライブラリを指定する形に揃える修正です。

作成者によると、Native AOTでこれを同梱し続けるかどうかは未確定で、今後サイズを検討する段階で見直す可能性があります。

変更内容

  • src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Wasm.targets（+1/-1）
    • Wasm向けのNative AOTビルド統合ターゲットで、wasi-emulated-getpid をリンク対象に追加（変更は1行のみ）

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）。ただしライブラリが追加でリンクされるため、バイナリサイズへの影響は今後の検討事項として作成者が言及しています。

関連Issue

なし

その他

  • 対象はWASI向けNative AOTのビルド統合（MSBuild targets）のみで、公開APIや互換性への影響に関する記載はありません。
  • 変更の背景は、ランタイムソースのビルド時に定義済みの wasi-emulated-getpid とリンク設定（eng/native/configureplatform.cmake）との整合性です。

#136265 Initialize NativeAOT library GS cookie before first managed call

概要

NativeAOTのUnix向け共有ライブラリで、最初のマネージドコード呼び出し（エクスポート関数の初回呼び出し）時にスタック保護用のGSクッキーが未初期化のまま使われ、abortする問題（#136201）を修正するPRです。遅延ランタイム初期化コールバックを登録する前にライブラリ用クッキーを初期化するようにし、ページサイズの取得もGC初期化から切り離しています。stackallocバッファを使う初回エクスポート呼び出しのテストも追加されています。

変更内容

  • src/coreclr/nativeaot/Runtime/thread.cpp: ランタイム初期化コールバックを公開する前にクッキーを初期化する処理を追加（+13）
  • src/coreclr/nativeaot/Runtime/startup.cpp: 実行可能ファイル向けのクッキー初期化はRhInitializeに残しつつ、ライブラリ起動時の処理と分離（+9/-10）
  • src/coreclr/nativeaot/Runtime/unix/PalUnix.cpp: メモリ保護のアライメント用ページサイズを minipal 経由で取得するよう変更（+4/-2）
  • src/coreclr/nativeaot/Bootstrap/main.cpp: 初期化関数の引数名をisLibraryに変更（+3/-3）
  • src/tests/nativeaot/SmokeTests/SharedLibrary/SharedLibrary.cs: stackallocを使うエクスポートと、インライン化されないバッファ読み取りメソッドを追加（+14）
  • src/tests/nativeaot/SmokeTests/SharedLibrary/SharedLibrary.cpp: 新しいエクスポートを解決し、最初に呼び出すテストを追加（+9）

パフォーマンスへの影響

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

関連Issue

#136201

その他

  • Copilotのレビューでは、Unixのライブラリロード時にセキュリティクッキー初期化を移す変更はメンテナーによる確認とプラットフォームでの検証が必要と指摘されています（ビルド・テストは未実施）。
  • 未解決の指摘が1件あり、重要度は低（初回呼び出し順序の要件に関する説明文のタイポ修正）です。

#136260 JIT: Clear GC poll flags when converting unreachable blocks to throws

  • 作成者: @EgorBo
  • 作成日時: 2026年10月22日 00:53:31(UTC)
  • マージ日時: 2026年10月22日 23:39:37(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITのfgRemoveUnreachableBlocksが、到達不能な BBF_DONT_REMOVE ブロックを空にして BBJ_THROW に変換する際、BBF_NEEDS_GCPOLL フラグが残ったままになる問題を修正します。

作成者の説明によると、このフラグはインライン化された Thread.FastPollGC() に由来し、クローンされた try エントリブロックに圧縮された後、RBO によって到達不能になったものです。空の throw ブロックに対して fgInsertGCPolls がインラインの GC ポールを挿入しようとし、fgCreateGCPoll が「最後のステートメント」を下位ブロックへ移動する際に null のステートメントを参照していました。修正として、ブロックのコードを削除する時点で GC ポール関連フラグをクリアします。

変更内容

  • src/coreclr/jit/fgopt.cpp（+2/-0）：到達不能ブロックのコード削除時に GC ポールのフラグをクリアする処理を追加

パフォーマンスへの影響

影響なし（作成者によれば No diffs、つまり生成コードの差分なし）

関連Issue

#136255（Fixes）

その他

  • 影響範囲は JIT コンパイラ内部の最適化フェーズ（ランタイム内部実装）で、公開APIの変更や互換性への影響は提供情報からは確認できません。
  • 修正前は、空の BBJ_THROW ブロックに GC ポール挿入が試みられ、fgCreateGCPoll で null 参照が発生していました。修正後はフラグがクリアされるため、この挿入処理が行われなくなります。

#136250 [wasi] Fix EINVAL from UDP Socket.ReceiveAsync

概要

WASIには recvmsg が存在しないため、SystemNative_ReceiveMessage は recvfrom にフォールバックします。このフォールバックでは、アドレスバッファが NULL の場合でも addrlen に非 NULL のポインタを渡しており、wasi-libc はこの組み合わせを EINVAL で拒否していました。その結果、アドレスなしで ReceiveMessage を経由する UDP の Socket.ReceiveAsync が常に "Invalid argument" で失敗していました。本PRはアドレスバッファが無い場合に addrlen を NULL にして渡すよう修正します。変更が影響するのは CMSG_SPACE を持たない唯一のターゲットである WASI のパスのみです。

変更内容

  • src/native/libs/System.Native/pal_networking.c (+4/-1): recvfrom フォールバックで、アドレスバッファが NULL の場合は addrlen も NULL を渡すように修正（アドレスが存在する場合の動作は維持）。
  • src/libraries/System.Net.Sockets/tests/FunctionalTests/SendReceive/SendReceive.cs (+25/-0): バインド済み UDP ソケットで、送信前後に受信を行う回帰テスト Receive_BoundUdpSocket_Success を追加。バイト数とペイロードを検証。

パフォーマンスへの影響

影響なし

関連Issue

#107981（Part of）

その他

  • 検証: CoreCLR WASI 上で System.Net.Sockets の全スイート（645テスト）を実行し、失敗は0件。新規テストは macOS 上のすべての SendReceive クラスで成功。
  • 公開APIの変更や互換性への影響（破壊的変更・非推奨化）に関する記載はありません。

#136249 Treat path-shaped assembly-name strings as unresolved in ILLink

概要

ILLink（trimmer）で、パス形式のアセンブリ名文字列（例: 親ディレクトリを指すパスなど）を、アセンブリ名参照の構築やロード済みキャッシュの参照より前に「未解決」として扱うようにする変更です。これにより、名前ベースの検索が親ディレクトリなどのパスを探索してしまうことを防ぎます。各呼び出し元の既存の未解決時の診断と、寛容なリフレクション探索の挙動は維持されます。明示的な参照ファイルパスや、作成済みのアセンブリ名参照の挙動は変更されません。

変更内容

  • LinkContext.cs: アセンブリ名の検証を共通化し、ガード付きのパース処理を追加
  • AssemblyResolver.cs: 明示的な参照の解決経路を維持しつつ、未解決の報告処理を調整
  • Driver.cs: コマンドラインのアセンブリ名に共通の検証を再利用
  • TypeMapHandler.cs / MarkStep.cs: 型マップ関連の文字列アセンブリ名を解決前に検証
  • LinkAttributesParser.cs: 属性内のアセンブリ名を解決前に検証
  • ProcessLinkerXmlBase.cs: XML内の拒否されたアセンブリ名を既存の警告経路で処理
  • ProcessReferencesStep.cs: 明示的な参照の解決経路を使用
  • AssemblyResolverTests.cs: パス拒否、診断、キャッシュ、有効な入力に関するリグレッションテストを追加（+358行）

パフォーマンスへの影響

影響なし（記載された情報の範囲では、パフォーマンスに関する言及はありません）。

関連Issue

なし

その他

  • 作成者によるLinuxでの検証結果: ILLinkテスト1,317件（リゾルバー関連の集中テスト175件を含む）、タスクテスト212件、キャッシュツールテスト33件、アナライザーテスト1,135件がパスし、既存のスキップ39件を除き失敗なし。ILTrimのビルドも成功。
  • Windows/macOS、およびILC/ILTrimのテストスイートは未実行。
  • Copilotのレビューでは「Changes recommended」と判定されており、新規に追加された絶対パスのリフレクションテストがWindows上ではアセンブリ解決に到達する前に失敗する（アセンブリ名のパース前にWindowsのテスト用パスを正規化すべき）という中程度の指摘が1件あります（ビルド・テストは未実行で、ソース検査に基づく指摘）。

#136243 [wasi] Accept explicit return in WASI R2R host constant exports

概要

WASIホストのDebugビルドでは wasi_r2r_* アクセサが i32.const N; return; end にコンパイルされます（Releaseは i32.const N; end）。WasmModuleInfoReader がこの形式を拒否していたため、Debug CoreCLRのWASI ReadyToRun publishが The host does not export constant i32 function 'wasi_r2r_image_base' で失敗していました。本PRでは end の前にオプションの return を許容するようにリーダーを修正しています。

変更内容

  • src/tasks/Microsoft.NET.WebAssembly.Webcil/WasmModuleInfoReader.cs (+10/-2): 定数i32エクスポート関数の解析時に、end の前に任意の return 命令を受け入れるよう変更

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 検証内容（作成者による、osx-arm64 / wasmtime 49.0.1）:
    • Debugランタイムをビルドし、src/mono/sample/wasi/console を -c Debug -p:RuntimeFlavor=CoreCLR -p:PublishReadyToRun=true でpublish: 修正前は上記エラーで失敗、修正後は成功（コンポジットの Wasi.Console.Sample.r2r.wasm が corerun に組み込まれ、アプリが引数を出力して実行できることを確認）
    • Releaseのランタイム・アプリでも同様にpublishと実行が成功することを確認
    • Debugの corerun を wasm-tools print で確認し、5つの wasi_r2r_* エクスポートすべてが i32.const; return の形になっていることを確認
  • WasmModuleInfoReader には既存のユニットテストがなく、本PRでもテストは追加されていません。
  • 本PRはGitHub Copilotを使って生成されたものです。

#136241 Replace CheapUnfairReaderWriterLock with ReaderWriterLockSlim

概要

System.Transactions.Local のトランザクションテーブルで使用していた独自実装の CheapUnfairReaderWriterLock を削除し、標準の ReaderWriterLockSlim に置き換える変更です。あわせて、トランザクションのハッシュ値の生成を、ロール管理とは独立したカウンターで行うようにしています。

変更内容

  • src/libraries/System.Transactions.Local/src/System/Transactions/TransactionTable.cs (+8/-118)
    • CheapUnfairReaderWriterLock を削除し、ReaderWriterLockSlim を使用
    • トランザクションのハッシュ値を、Interlocked でインクリメントする専用カウンターで生成

パフォーマンスへの影響

ベンチマーク結果の記載はなく、パフォーマンスへの影響は不明です。独自実装のロックを標準の ReaderWriterLockSlim に置き換えるため、ロックの挙動に差異が生じる可能性があります。

関連Issue

なし

その他

  • Copilotのレビューでは、「Changes recommended」と判定され、重要度High（高）の指摘が1件挙げられています。置き換え後のロックでは、同期的なタイマーリスナー内でのネストしたトランザクション作成（再帰的な読み取り）が拒否される点が問題視されており、タイマーイベントのコールバック中の再帰的な読み取りを許可すべきという内容です。
  • 並行処理（コンカレンシー）に関する検証は未完了です。
  • 検証はソースコードの確認のみで、ビルドやテストは実行されていません。

#136238 Seed innerloop build caches from main

  • 作成者: @sbomer
  • 作成日時: 2026年10月21日 19:11:11(UTC)
  • マージ日時: 2026年10月22日 19:02:36(UTC)
  • ラベル: area-Infrastructure

概要

main ブランチへのバッチ化された push ビルドで、既存のキャッシュ付き Release の analyzers / linker ジョブを Linux x64、Windows x64、macOS arm64 で実行するようにしました。これにより、新規 PR はコールドな初回実行で自前のキャッシュを作る必要がなく、ILLink とコンパイラのキャッシュスナップショットを共有ベースラインとして復元できます。

push による自動実行では、キャッシュ生成と無関係な developer-workflow 系ジョブをスキップします。PR 実行・手動実行の既存動作は維持され、キャッシュ対象ジョブとキャッシュキーは変更されていません。

変更内容

  • eng/pipelines/global-build.yml（+30/-9）
    • main への push トリガーを追加（ドキュメントやメタデータ関連のパスは除外）
    • 無関係な developer-workflow ジョブを、push 以外（PR・手動実行）の場合のみ実行するよう条件を変更

パフォーマンスへの影響

ランタイムや実行時性能への影響はなく、CI パイプラインのみの変更です。新規 PR の初回ビルドでキャッシュを復元できるため、初回のビルド時間短縮が期待されます（ただしベンチマークや具体的な数値は示されていません）。

関連Issue

なし

その他

  • パイプラインの実行確認は行われていません（Copilot の要約による）。
  • Copilot のレビューでは未解決の指摘はなく、承認推奨とされています。
  • 作成者によると、この内容は GitHub Copilot の支援を受けて作成されています。

#136230 [release/10.0] Source code updates from dotnet/dotnet

概要

dotnet/dotnet VMR（release/10.0.1xx ブランチ）からの自動コードフロー更新PRです（Build 20261013.24 / Commit d7437ff）。ソースコード変更と依存関係の更新が含まれます。コードサンプルはありません。

変更内容

  • 依存関係の更新（eng/Version.Details.xml / Version.Details.props / Versions.props / global.json）
    • Roslyn系（Microsoft.CodeAnalysis 等）: 5.0.0-2.26461.103 → 5.0.0-2.26513.124
    • Microsoft.CodeAnalysis.NetAnalyzers、Microsoft.DotNet.ApiCompat.Task: 10.0.113 → 10.0.114
    • Arcade 関連（Microsoft.DotNet.Arcade.Sdk、Build.Tasks.*、Helix.Sdk、RemoteExecutor、XliffTasks 等）: 10.0.0-beta.26461.103 → 10.0.0-beta.26513.124
    • Wasm Node Transport（各RID）: 10.0.0-alpha.1.26457.2 → 10.0.0-alpha.1.26505.3
    • Microsoft.DotNet.Cecil: 0.11.5-alpha.26461.103 → 0.11.5-alpha.26513.124
    • XUnitAssert / XUnitConsoleRunner: 2.9.3-beta.26461.103 → 2.9.3-beta.26513.124
    • Microsoft.NETCore.App.Ref、ILAsm、System.Text.Json、System.Reflection.Metadata 等: 10.0.13 → 10.0.14
    • Emscripten Manifest: 10.0.113-servicing → 10.0.114-servicing
    • NuGet.*: 7.0.3-rc.46203 → 7.0.3-rc.1424
    • System.CommandLine: 2.0.13 → 2.0.14
    • 新規追加: Microsoft.DotNet.Build.Tasks.FileCatalog（10.0.0-beta.26513.124）
  • ビルド/署名関連
    • eng/Signing.props、eng/packaging.targets、.config/dotnet-tools.json、NuGet.config の更新
    • src/libraries/Directory.Build.targets の軽微な変更
  • eng/common（Arcade共通スクリプト）の更新
    • Get-GitHubAppToken.ps1、get-github-app-token.yml、send-to-helix.yml、helix-job-monitor.yml、job.yml、onelocbuild.yml の更新
    • run-helix-job-monitor.sh を新規追加
    • sdl/extract-artifact-packages.ps1 を削除
  • 共有フレームワーク（Microsoft.NETCore.App）関連
    • Directory.Build.props / Directory.Build.targets の更新
    • Microsoft.NETCore.App.Host.sfxproj を新規追加（+34行）

パフォーマンスへの影響

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

関連Issue

なし

その他

  • 本PRはMaestroによる自動生成のコードフロー更新で、追加ファイルが多数あるため、すべてのファイルが表示されているわけではありません。
  • 参考リンク: Commit Diff (fa5198e...d7437ff)

#136229 [release/11.0] Source code updates from dotnet/dotnet

概要

dotnet/dotnet（VMR）からdotnet/runtimeのrelease/11.0ブランチへのコードフロー更新です（VMRビルド 20261021.5、コミット 6fa58a2、ブランチ release/11.0.1xx）。VMR側のソース変更の取り込みと、依存パッケージのバージョン更新が含まれます。コード変更の個別の意図は提供情報からは確認できません。

変更内容

  • 依存バージョン更新（eng/Version.Details.props/.xml、eng/Versions.props、global.json、.config/dotnet-tools.json）
    • Roslyn系（Microsoft.CodeAnalysis 等）: 5.12.0-1.26465.108 → 5.12.0-1.26521.105
    • Arcade/Helix/各種ビルドタスク: 11.0.0-beta.26465.108 → 11.0.0-beta.26521.105
    • Microsoft.NETCore.App.Ref、Microsoft.NETCore.ILAsm、System.Text.Json、System.Reflection.Metadata 等: 11.0.0-rc.2.26465.108 → 11.0.0（RTM版）
    • Microsoft.CodeAnalysis.NetAnalyzers、Microsoft.DotNet.ApiCompat.Task: 11.0.100-rc.2 → 11.0.100
    • NuGet.*: 7.12.0-rc.46608 → 8.0.0-rc.52305
    • System.CommandLine: 3.0.0-rc.2 → 3.0.0
    • llvm-project: 23.1.0-alpha.1.26457.1 → 23.1.0-alpha.1.26505.4
    • node: 11.0.0-alpha.1.26459.1 → 11.0.0-alpha.1.26517.3
  • eng/common（Arcade由来）
    • Get-GitHubAppToken.ps1、get-github-app-token.yml の更新
    • helix-job-monitor.yml の大幅な書き換え
    • run-helix-job-monitor.sh の新規追加
    • send-to-helix.yml、onelocbuild.yml の更新
  • ネイティブビルド: eng/native/Info.plist.in（新規）、eng/native/functions.cmake、createdump/ilasm/ildasm の CMakeLists.txt の変更
  • AOTツール: eng/toolAot.targets（新規）、ILCompiler_publish.csproj、crossgen2_publish.csproj の変更
  • Interop（System.Native）: Interop.MkDirAt.cs、Interop.OpenAt.cs、Interop.UnlinkAt.cs（新規）、Interop.OpenFlags.cs（+1行）
  • その他: NuGet.config（+5）、eng/Signing.props、eng/packaging.targets、Directory.Build.targets、src/coreclr/README.md など。他76ファイルは一覧に含まれず内容不明

パフォーマンスへの影響

影響なし（提供情報にベンチマーク等の記載なし）

関連Issue

なし

その他

  • 本PRはdotnet-maestro[bot]による自動コードフローPRで、依存バージョンがRTM版（11.0.0 / 11.0.100）へ移行している点が特徴です。
  • 変更ファイル一覧のうち76ファイルは省略されており、本要約には含まれていません。
  • 取り込み元VMRのソース変更の詳細は、VMR側の比較リンク（e5abd3f...6fa58a2）で確認できます。

#136221 Use extension-member polyfills across libraries

概要

src/libraries 全体に散在していたフレームワーク互換コード（ダウンレベル向けの条件分岐やローカルヘルパー）を、C# の extension-member polyfill（拡張メンバー）に集約するリファクタリングです（#136156 の続き）。呼び出し側はフレームワーク標準のAPI名で記述し、ダウンレベル実装は内部の polyfill コンテナに置かれます。対象ターゲットが元からそのメンバーを持つ場合は、引き続きフレームワーク実装にバインドされます。公開APIの変更と新規テストの追加はありません。

変更内容

  • 共有 polyfill の追加・拡張（src/libraries/Common/src/Polyfills/）
    • 静的メンバー／プロパティ系: TypePolyfills、EnumPolyfills（型・enum の検査）、BinaryPrimitivesPolyfills（ReverseEndianness 含む）、BitConverterPolyfills、MathPolyfills（乗算）、ArrayPolyfills（配列上限）、UInt64Polyfills、StringPolyfills、OperatingSystemPolyfills（プラットフォーム判定）、DateTimeOffsetPolyfills（Unix epoch ほか）、MemoryExtensionsPolyfills、ReadOnlySequencePolyfills、RuntimeHelpersPolyfills
  • 適用範囲: System.Text.Json とそのソースジェネレーターに加え、CBOR、Metadata/NRBF、xxHash、Packaging、Dataflow、MEF2、DiagnosticSource、Server-Sent Events、および複数の Microsoft.Extensions ライブラリ（Configuration、DependencyInjection、DependencyModel、Diagnostics など）
  • 既存 polyfill の再利用: span、コレクション、スタック、文字列、decimal、未初期化オブジェクト関連の既存 polyfill を使い、ローカルの互換ヘルパーや条件分岐を削除
  • 引数ガードの標準化: 手書きの同等チェックを標準の引数ガードに置換（検証順序とパラメーター名は維持）
  • ソースジェネレーター: IsClosed ヘルパーを拡張プロパティ化（既存の Roslyn light-up と構文フォールバックの挙動は維持）
  • テスト: 既存の CBOR テストと共有アサーションユーティリティ（AssertExtensions.cs、TestUtilities.csproj）に同様の集約を適用し、対になっていた CBOR テストヘルパーファイルを削除（テストカバレッジの追加なし）
  • 付随して ParameterDefaultValue.cs、ArrayBuffer.cs、ValueStringBuilder.cs、SpanAction.cs、各 csproj などの互換コードを整理

パフォーマンスへの影響

影響なし（挙動を変えないリファクタリングで、ベンチマーク結果の記載もなし）。

関連Issue

  • 先行PR: #136156（Issueではなくフォロー元のPR）

その他

  • 検証: .\build.cmd libs -rc Release -lc Release /p:RunAnalyzersInBuild=true /p:RunILLinkInBuild=true が成功。その後、CoreCLR と .NET Framework で対象を絞った互換ビルドと既存テストスイートを実行。レビュー後の調整も対象を絞った再ビルドとテストで確認済み。
  • 公開APIの変更・破壊的変更の記載なし。
  • GitHub Copilot により生成されたPRです。

#136209 Clear Zstandard prefixes and restore dictionaries on reset

概要

Zstandardのセッション単位のリセット（session-only reset）では、未使用のプレフィックスが保持されます。一方、マネージド側のエンコーダー／デコーダーはリセット時にピン留めしたメモリを解放するため、ネイティブコンテキストが「もうピン留めされていないメモリ」を参照し続ける問題がありました。また、プレフィックスを設定するとコンストラクターで渡した辞書が置き換えられますが、リセットしても辞書が復元されませんでした。

このPRでは、エンコーダー／デコーダー双方のリセット処理を修正しています。ピン留めメモリを解放する前に、元の辞書を復元するか、辞書が指定されていない場合はネイティブ側のプレフィックスを明示的にクリアします。あわせて、プレフィックスによる辞書の上書きと、リセット時の辞書復元の挙動をドキュメント化しています。

変更内容

  • SafeZstdHandle.cs（+10/-2）: ネイティブハンドルまわりの変更（具体的な内容は提供情報からは不明）
  • ZstandardDecoder.cs（+6/-1）: リセット時に元の辞書を復元、または辞書未指定ならプレフィックスをクリアする処理を追加
  • ZstandardEncoder.cs（+4/-1）: 同上（エンコーダー側）
  • ZstandardEncoderDecoderTests.cs（+57/-13）: 既存のリセットテストを拡張
    • 辞書あり／なし、プレフィックス空／非空の組み合わせを網羅
    • プレフィックス使用前のリセットと、フレーム完了後のリセットの両方をカバー
    • リセット後のエンコーダー出力を新規エンコーダーの出力と比較
    • デコーダーの辞書復元を独立して検証

検証結果（PR記載）:

  • build および System.IO.Compression.Tests が成功（2,655テスト、失敗0、outer-loopテストは除外）
  • SetPrefix_AfterReset_SetsSuccessfully の4ケースがすべて成功
  • 拡張テストは、エンコーダーの辞書復元がない場合に失敗することを確認済み。エンコーダーのみ修正した状態では、デコーダーのプレフィックスクリアと辞書復元の不具合を検出できることも確認済み

パフォーマンスへの影響

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

関連Issue

なし

その他

  • 公開APIの変更や破壊的変更に関する記載はありません。ドキュメントの更新は含まれます。
  • 内容はリセット後の正当性に関するバグ修正（ピン留め解除後のネイティブ参照、辞書の復元漏れ）です。

#136208 Fix NativeAOT WASM math helper calling conventions

概要

NativeAOT の WASM ビルドで発生していた、数学関数（sin など）のシグネチャ不一致によるリンカ警告（wasm-ld: function signature mismatch: sin）を修正する PR です。x86 と WASM では数学関数呼び出しを専用のランタイムラッパー（浮動小数点の剰余ヘルパーを含む）経由にし、それ以外のアーキテクチャでは従来どおり libc を直接インポートします。

作成者によると、x86 では /alternatename によるリンカの仕組みで C ライブラリの関数名を維持していましたが、WASM は x86 Windows のシンボル名装飾を行わず sin がそのまま sin になるため、同じ方法は使えないとのことです。

変更内容

  • src/coreclr/nativeaot/Runtime/MathHelpers.cpp
    • 数学ラッパー関数に Rhp プレフィックスを付与するようリネーム
    • WASM でもラッパーが有効になるよう変更
  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Runtime/RuntimeImports.cs
    • アーキテクチャに応じて数学関数のインポートを切り替え（x86/WASM はラッパー、その他は libc 直接）
  • src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/DependencyAnalysis/KnownExternFunctions.cs
    • x86/WASM の剰余ヘルパーのマッピングをラッパー経由に更新

パフォーマンスへの影響

影響なし（提供された情報にベンチマーク等の記載はありません）。x86/WASM ではラッパー経由の呼び出しになりますが、その影響についての言及はありません。

関連Issue

なし

その他

  • 公開 API の変更ではなく、NativeAOT ランタイム/ILCompiler 内部の呼び出し規約・リンク周りの修正です。
  • Copilot のレビュー概要によると、アーキテクチャをまたぐ呼び出し規約の変更のため、x86 と WASM でのリンクおよび実行の検証が必要とされていますが、このレビュー中には実施されていません。

#136203 Fix virtual vtable call lowering without fixed registers

概要

JITの仮想vtable呼び出しのlowering処理を修正し、固定レジスタを持たないターゲットでも正しく動作するようにしました。作成者によると、StackTraces+TestLineNumbers:MethodWithMetadata のMinOptsコンパイル中に Assertion failed 'thisArgNode->OperIs(GT_PUTARG_REG)' が発生していたとのことです。作成者は、ReadyToRunではこのような仮想呼び出しを行わないのではないかと推測しており、Native AOTでもMinOptsでのみこの問題に遭遇するとしています。

変更内容

  • src/coreclr/jit/lower.cpp (+10/-4)
    • CallArg を保持して引数ノードに直接アクセスできるようにしました。
    • 一時ローカル変数への置き換えの際に、this ポインタの使用箇所を適切に選択するようにしました。固定レジスタがある場合の既存パスは維持されます。

影響範囲はJIT内部（lowering）の実装であり、公開APIの変更や互換性への影響に関する記載はありません。

パフォーマンスへの影響

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

関連Issue

なし

その他

  • Copilotの概要では、影響を受けるWebAssembly向けNativeAOTのMinOptsパスについて、ビルドおよびランタイムでの検証が必要（「Needs a closer look」）とされています。この検証は実施されていません。

#136185 OpenHarmony: NativeAOT and pack integration

概要

OpenHarmony（openharmony-* RID）をNativeAOT、crossgen2、パック生成、ILLinkのビルド経路に組み込むPRです。共有のターゲットOSパーサーでopenharmonyをLinuxにマップし、NDKのlldとohos ABIを使用します。CoreLibとランタイムパックは他のUnixターゲットと同様にReadyToRunのままとし、NTLMはマネージド実装を選択します。

変更内容

  • src/coreclr/tools/Common/CommandLineHelpers.cs: openharmonyを受け付け、androidと同様にTargetOS.Linuxへマップ
  • src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets: openharmonyでlldを選択、CrossCompileAbiをohos（aarch64-linux-ohos）に設定、System.Net.Security.Nativeをスキップ（sysrootにgssapi/krb5がないため）
  • .../Microsoft.DotNet.ILCompiler.SingleEntry.targets: openharmonyでmusl libcフレーバーを維持
  • eng/targetingpacks.targets: openharmony-arm64/openharmony-x64をローカルのランタイム・NativeAOT・apphost RIDリストに追加。SDK提供のapphostパックエントリをローカルのものに置換。OpenHarmonyではResolvedRuntimePackのローカルパック上書きをターゲットRIDに限定
  • src/native/eventpipe/ds-portable-rid.c: PORTABLE_RID_OSとしてopenharmonyを報告
  • src/tools/illink/src/ILLink.Tasks/build/Microsoft.NET.ILLink.targets: OpenHarmonyでマネージドNTLM実装を使用（linux-bionicと同様）
  • 合計6ファイル（+25/-6）

パフォーマンスへの影響

影響なし（作成者の説明によると、新しい条件はOpenHarmony以外のターゲットでは無効で、既存のlinux、android/bionic、Apple、BSDの経路は変更なし）

関連Issue

なし

その他

  • openharmony RIDはCoreCLRおよびNativeAOTのパックにのみ追加され、Mono用パックには追加されません（CoreCLR+NativeAOTのポートであるため）。
  • このPRからパックは出荷されず、ローカルビルドグラフにRIDを認識させるのみです。
  • 作成者によるテスト観点: openharmony-arm64でのクロスビルド（crossgen2が--targetos openharmonyを受け付けReadyToRunとなる）、NativeAOT publish（NDKのclangを--target=aarch64-linux-ohosで呼び出しlldでリンク、musl libcフレーバー使用）、ローカルパックビルド、ILLinkでのマネージドNTLM選択。
  • 本PRはAIの支援を受けて作成されたと明記されています。

#136160 Root String constructor factories in ReadyToRun compilation

  • 作成者: @radekdoulik
  • 作成日時: 2026年10月20日 15:59:06(UTC)
  • マージ日時: 2026年10月22日 10:40:29(UTC)
  • ラベル: area-ReadyToRun

概要

ReadyToRun（R2R）のビジビリティベースのコンパイルにおいて、System.String.Ctor という private static のファクトリメソッドをルートとして扱うように変更しました。

string の public コンストラクタは InternalCall であり、ネイティブの FCall マッピングを介してこれらのマネージドファクトリにつながっています。このマッピングは通常の IL 上の呼び出しエッジではないため、他のルートプロバイダーが供給しない限り、ビジビリティベースのルート化では private な実装がスキップされていました。この変更により、これらのファクトリのコンパイルが埋め込み記述子（embedded descriptor）の処理に依存しなくなります。

変更は static な System.String.Ctor メソッドに限定されています。既存のコンパイル可否チェックは維持され、ネイティブのディスパッチ方法や他の private メソッドのルート化には影響しません。

変更内容

  • src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunVisibilityRootProvider.cs (+4/-0)
    • System.String.Ctor の static ファクトリをビジビリティルートとして扱う処理を追加
  • src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/ReadyToRunVisibilityRootProviderTests.cs (+112/-0)
    • 回帰テストを追加。InternalCall の string コンストラクタ（span・ポインタ版を含む現行9オーバーロード）をすべて列挙し、シグネチャで対応する static ファクトリを解決して、ビジビリティプロバイダーがルート化していることを検証
    • 通常の private ヘルパーがルート化されないことを確認するネガティブコントロールも含む
    • WASM 固有のテストではなく、crossgen2 と同じターゲットトークンのエイリアス・既定値で構成されたコンパイラコンテキストを使用し、埋め込み記述子処理とは独立にビジビリティプロバイダー単体を呼び出す

パフォーマンスへの影響

  • 以前の調査（ソース 7f139f63c51de2f237ad732dc5bacbe98f25850d）では、Havit のホーム画面読み込みあたり、修正前は span ファクトリ呼び出しが 2,272 回インタープリタ実行されていたのに対し、修正後は 2,272 件がコンパイル済みエントリとなり、コンストラクタのリバースフォールバックエントリは 0 件でした。
  • ただしこの結果は今回のリビジョンでは再実行されておらず、コンパイル済みディスパッチの検証にとどまります。起動時間や全体の高速化は主張されていません。

検証結果（回帰テスト）:

ターゲット構成 修正なし 修正あり
macOS/arm64 期待どおり失敗（string.Ctor(char[]) のルート欠落）、1 failed 1 passed, 0 failed
browser/wasm 期待どおり失敗（同上）、1 failed 1 passed, 0 failed

これらのマネージドコンパイラテストは macOS/arm64 ホスト上で実行され、各ターゲットのステージ済み CoreLib を読み込むものです。browser ターゲットの結果はブラウザランタイム上での実行結果ではありません。

関連Issue

その他

  • 作成者によると、このパッチと PR 説明は GitHub Copilot を用いて作成されたとのことです。
  • 前提となるビルド（clr.jit+clr.corelib+libs.sfx、および browser/wasm 向けの clr.corelib+libs.sfx+clr.crossarchtools）は警告・エラーなしで成功したと記載されています。

#136136 Fix JsonArray lazy list initialization race

概要

JsonArray の内部リスト（List<JsonNode?>）の遅延初期化における競合状態（race condition）を修正するPRです。JsonObject で適用済みの修正方法と同じアプローチをコピーしており、あわせて競合を検出するテストも追加されています。Issue #136117 を解決します。

変更内容

  • src/libraries/System.Text.Json/src/System/Text/Json/Nodes/JsonArray.cs（+13/-4）
    • 遅延初期化されるリストの生成処理を修正し、競合状態を解消（JsonObject の修正と同様の手法）
  • src/libraries/System.Text.Json/tests/System.Text.Json.Tests/JsonNode/JsonNodeTests.cs（+78/-0）
    • 遅延初期化の競合を検出するテストを追加

パフォーマンスへの影響

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

関連Issue

#136117

関連参照: #77567（JsonObject での同種の修正の議論）

その他

  • 公開APIの変更はなく、内部実装の修正です。互換性への影響に関する記載もありません。
  • 具体的な実装内容や競合の再現条件の詳細は、提供された情報からは確認できません。

#135970 JIT: treat throwing trees as GC safe points

  • 作成者: @lewing
  • 作成日時: 2026年10月16日 19:04:59(UTC)
  • マージ日時: 2026年10月22日 01:16:07(UTC)
  • ラベル: area-CodeGen-coreclr

概要

optRemoveRedundantZeroInits は、最初のストアより前にGCセーフポイントがないGCローカルについて、プロローグでのゼロ初期化を省略します。しかし IsPotentialGCSafePoint は例外をスローしうるツリー（GTF_EXCEPT）を無視していました。これらはthrowヘルパーを呼び出す可能性があり、throwヘルパーはGCセーフポイントです。その結果、未初期化のGCスロットがGCに報告されることがありました。

  • Wasm: フレーム上の全GCローカルが untracked として報告されます。Object.GetType では、GC一時変数への格納前に this のnullチェックが ThrowNullReferenceException を呼び、そこで発生したGCが古いスタック内容を報告し、TypeIntrinsics_r が pMT->Validate() でアサート失敗していました。
  • 他ターゲット: 境界チェックの後にストアされる untracked（例: アドレス公開された）GCローカルで同様の問題が発生していました。

本PRは、全ターゲットで GTF_EXCEPT を持つツリーに対して IsPotentialGCSafePoint が true を返すようにします。

変更内容

  • src/coreclr/jit/compiler.hpp: IsPotentialGCSafePoint が GTF_EXCEPT ツリーに対して true を返すよう変更（+6行）
  • src/tests/JIT/Regression_ro_2/Runtime_135966.cs: 回帰テストを追加（+107行）

パフォーマンスへの影響

実行時性能に関する記載はありませんが、プロローグのゼロ初期化が省略されにくくなるため、コードサイズが増加します。

SuperPMI（benchmarks, realworld, aspire）の結果:

Target Contexts with diffs Bytes
osx-arm64 70 +204 / -24
windows-x64 99 +697 / -20
linux-x64 97 +553 / -58

System.Private.CoreLib.wasm は +6,944 バイト（0.02%）増加しています。

関連Issue

その他

  • この解析はヘルパー展開とLowering の前に実行されるため、すべてのセーフポイントを把握できるわけではありません。コード生成に近い段階で行う対応は別作業とされています。
  • 検証結果:
    • Runtime_135966（osx-arm64 Checked, GCStress=0/1/4）: main ではsegfault、本PRではpass
    • JIT_r（browser-wasm R2R Checked, GCStress=1）: main では pMT->Validate() アサート（3/3）、本PRではpass（3/3）
    • Runtime_135966（browser-wasm R2R, GCStress=0/1）: main ではアサート、本PRではpass

#135839 native: use the C90 qsort workaround for zstd on OpenHarmony

概要

OpenHarmony のsysrootには qsort_r が存在せず、zstd の自動検出もこれを扱えないため、Android 向けに使われている ZSTD_USE_C90_QSORT の回避策を OpenHarmony でも再利用する変更です。作成者によると、openharmony-arm64 向けにネイティブライブラリをクロスビルドして確認したとのことです。

変更内容

  • src/native/external/zstd.cmake (+2/-2): zstd のビルド設定で、Android に適用している ZSTD_USE_C90_QSORT の回避策を OpenHarmony にも適用するよう変更

※ 提供された情報には diff の詳細が含まれていないため、具体的な条件式の書き換え内容までは確認できません。

パフォーマンスへの影響

影響なし（記載された情報の範囲では、ベンチマーク結果や性能に関する言及はありません。なお、C90 版 qsort を使うことによる実行時の影響については情報がありません）

関連Issue

なし

その他

  • 影響範囲はネイティブ側（zstd のビルド設定）に限られ、公開APIやマネージドコードへの変更、破壊的変更に関する記載はありません。
  • 対象は OpenHarmony 向けビルドです。

#135342 Mitigate macOS FSEvents race in TokensFiredForNewDirectoryContentsOnRename

概要

macOSで不安定だった PhysicalFileProviderTests.TokensFiredForNewDirectoryContentsOnRename テストの修正です。macOSの fseventsd はウォッチャー開始前の操作に由来する古いイベントを配信することがあり、「まだ発火していないはず」というアサーションが散発的に失敗していました。本PRはテスト側のみを修正しており、FileSystemWatcher / PhysicalFilesWatcher の実装は変更しません。

テストで fileSystemWatcher.Filter に、ランダム生成（GUID名）のテスト用エントリには一致しないパターンを設定してからウォッチを開始します。これにより、実際のネイティブイベント（fseventsd による事前作成イベントの遅延再送を含む）は抑制されます。一方、テストが明示的に注入する fileSystemWatcher.CallOnRenamed(...) は Filter によるマッチングを行わないため影響を受けません。この方式により、人工的な遅延や動的スキップを使わずに、リネーム前のアサーションをすべてのプラットフォームで決定的に有効なまま維持できます。

（PR本文では Filter を設定するコードの具体例は示されていないため、サンプルコードは省略します。）

変更内容

  • src/libraries/Microsoft.Extensions.FileProviders.Physical/tests/PhysicalFileProviderTests.cs（+7/-0）
    • ウォッチ開始前に fileSystemWatcher.Filter を、テストのエントリに一致しないパターンへ設定する処理を追加

パフォーマンスへの影響

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

関連Issue

#135283（Fixes）。背景として参照されている #30415 のコメントもあります。

その他

  • 本番コード（FileSystemWatcher / PhysicalFilesWatcher）側での修正は見送られています。macOSバックエンドは公開FSEvents APIで最も応答性の高いオプション（kFSEventStreamEventIdSinceNow、遅延 0.0f、NoDefer）をすでに使用しており、これ以上の余地がないためです。また、ウォッチ登録時点の状態スナップショットで先行イベントを抑制する方式は決定的ですが、より侵襲的です。本番で起こり得る影響は余分な変更通知にとどまり、通知の取りこぼしや正しさの問題ではないため、費用対効果が見合わないと判断されています。
  • この問題はmacOS固有です。WindowsのReadDirectoryChangesWとLinuxのinotifyはハンドル/ディスクリプタベースで、過去のイベントを再送する別デーモンが存在しません。
  • 初期のレビューでは、遅延の挿入や SkipTestException による動的スキップ案が指摘されていました。最終的な差分は上記のFilter方式で、最終レビューは「承認推奨」で未解決の指摘は0件です。
  • PR本文によると、説明と変更はAI（GitHub Copilot）の支援で作成されています。

#135312 Managed ilasm: record sequence points as instructions are emitted, on the lines of the .il source when no .line directive is in effect

概要

マネージド版 ilasm（src/tools/ilasm）が、.line ディレクティブのない .il ファイルに対してシーケンスポイントを一切出力せず、ステップ実行できない問題を修正します。ネイティブ ilasm と同様に、命令を emit する時点でその命令の .il ソース上の行（列 1〜2）にシーケンスポイントを記録し、.line / #include の扱いもネイティブに近づけます。

  • -DEBUG または -PDB 指定時、.line の対象外の命令ごとに、その .il 上の行へ暗黙のポイントを記録（同一行の命令は 1 つのポイントを共有。.line 直後の最初の命令は常にポイントを持つ）
  • メソッド末尾の命令の後の .line は、そのメソッドにはポイントを作らず次の命令に適用
  • クラス／トップレベルの .line は、次のメソッドの最初の命令に適用
  • #include されたファイルは独自の行・ドキュメント（フルパス）を持ち、.line 状態はインクルードをまたいで漏れない
  • 不正なオペランドの命令はポイントを記録しない。同一オフセットのポイントは置換され、ポイント blob に同一オフセットが 2 つ入らない

変更内容

  • GrammarActions.Debug.cs: ソースごとの .line 状態管理と、命令 emit 時のポイント記録を実装（主要な変更）
  • GrammarActions.Instructions.cs / Instructions.References.cs: 命令開始時にポイントを記録。不正オペランドは記録前に拒否
  • GrammarActions.Conversions.cs / GrammarActions.cs / GrammarActions.BuildImage.cs: ソース状態と最後に記録したスパンの保持、入力ファイル間の状態クリア、コメント更新
  • EntityRegistry.cs / Location.cs: hidden ポイントのファクトリ削除、トークンのソース名参照の切り出し
  • src/ilasm/Program.cs: インクルードファイルのパスをフルパスに正規化
  • MANAGED-ILASM-FIXES.md: ネイティブとの意図的な差異 5 点を記載
  • テスト: SequencePointTests（新規 39 行）、CommandLineSequencePointTests、生成ケース（200 プログラム、1,200 行の比較）、CompilerOptionsTests、PdbDocumentTests を追加・更新

ネイティブとの意図的な差異:

  • ドキュメントが前のポイントと異なる場合も、行・列が同じでもポイントを付与
  • #include 後、インクルード元は自身の .line とそのファイルを保持
  • インクルードファイルは、ポイントを持つ命令があって初めてドキュメント化
  • インクルードファイルのドキュメントは、最初のポイント時点の言語を持つ
  • #define マクロ由来の命令はマクロの使用行にマップ

パフォーマンスへの影響

実行時パフォーマンスへの影響はありません。ただし PDB サイズが増加します（例: TestLocalScopes4.il の PDB は 548 → 732 バイト、ネイティブは 736 バイト）。また --deterministic 時、PDB（およびその ID を通じてイメージ）が .il ファイルの行レイアウトにも依存するようになります。

関連Issue

  • #135212（マネージド ilasm をネイティブのドロップイン置換にする議論）
  • #135311、#135297、#135289（マージ済みの先行 PR）
  • #135314（本 PR で未対応のネイティブとの差異の追跡）
  • #46328（部分指定 .line の終了列のデフォルト、対象外）

その他

  • 動作変更: .line はネイティブ同様、ファイル末尾まで有効でメソッドをまたぎます。そのため、.line を持つメソッドの後の .line なしメソッドは、そのディレクティブの座標にマップされ、ポイントが付かない場合があります。ポイントを持たないメソッドの Document は nil のままです。
  • 著者からの確認事項: (1) .line をメソッドごとにリセットして各メソッドの最初の命令に必ずポイントを付けるか、(2) PDB サイズ増加をデフォルトとして許容するか。
  • 本 PR の対象外: #line の行自動インクリメント、部分指定 .line の終了列デフォルト、シーケンスポイントの検証（0xFEEFEE 開始行を hidden 扱いにする点はネイティブと異なる）。
  • AI 支援（Anthropic Claude と OpenAI Codex）で作成され、著者がレビュー済みです。

#135122 Optimize System.Numerics.Tensors dense and strided operations

概要

System.Numerics.Tensors の dense（連続レイアウト）および strided（ストライド付き）テンソル操作に対する高速パスを拡張するPRです。テンソルの形状・オーバーラップ・走査順序・論理要素のセマンティクスは維持されます。dotnet/runtime#134914 と #135060 の修正・連続操作の最適化を土台にしています。公開APIシグネチャの変更はありません。

主な内容:

  • strided なソースを dense な宛先へ ResizeTo する場合はスパンのクリアを使用（非 dense な宛先では論理クリアを維持）
  • 大きな dense テンソルを int サイズのチャンク単位で処理し、連続ランやスライスを再利用（コピー、反転、リダクション、述語、等価比較、乱数フィル、連結、スタック）
  • rank 1 向けのリニアオフセット高速パスを追加
  • 数GB規模のテストに利用可能メモリの事前チェックと余裕を追加し、リモートプロセスでアロケーションを隔離、想定内のOOMはスキップ

変更内容

  • Tensor.cs（+378/-67）: 変更の中心となる高速パス・チャンク処理関連の実装
  • TensorOperation.cs（+626/-4）: 連続ラン/スライスを再利用する各種操作の最適化
  • TensorShape.cs（+5/-0）: 小規模な追加
  • System.Numerics.Tensors.Tests.csproj（+2/-0）: テストプロジェクト設定の更新
  • TensorTests.cs（+2263/-95）: strided、ブロードキャスト、singleton、空、オーバーラップ、順序の各ケースのテストと、大容量メモリテストのガードを追加

パフォーマンスへの影響

BenchmarkDotNet（Windows x64 / Ryzen 9 7950X、parent と updated を比較した21ケース）での主な結果:

  • AllDense: 約8.8倍高速化（256列で 66.98us → 7.62us）
  • ReverseBetweenRuns 256列: 20.14倍高速化
  • StackInterleaved: rank 2 で約27〜30倍、rank 6 で約64〜70倍高速化し、アロケーションが 100% 削減（例: 4,457,624 B → 0 B）
  • ConcatenateInner: rank 6 で最大約45倍高速化し、アロケーションも 15,360 B → 0 B
  • EnumerateStrided: 約17〜19% 高速化
  • Resize（strided→dense）: ほぼ中立（ゼロテールの値型で 3.1% 増加だが信頼区間が重複しておりノイズ扱い）
  • 2GB超の dense 要素演算: int.MaxValue + 65 要素の OnesComplement が 13,719ms → 83ms（約166倍）、tensor/tensor Add が約453倍など
  • 述語（EqualsAll 等）は約9〜36倍、リダクション（Sum/Max/Dot）は約2〜4倍の改善
  • 一部の小さな制御ケース（1,024要素の CopyTo で約4ns、極小サイズの反転など）はほぼ中立、またはノイズ範囲

ベンチ結果は環境・ビルド構成に依存し、カテゴリごとに比較対象が異なります。

関連Issue

#125663（本PRで解決）。関連PR: #134914、#135060

その他

  • テスト結果: net11.0 の非 outer-loop テスト 6,505件 + 大容量メモリクラス 41件がパス、net481 は 200件パス、ビルドは警告・エラーなし
  • net11.0 テストは、ローカルビルドの .NET 12 ランタイムで通常のテストターゲットが xUnit のディスカバリ中にクラッシュしたため、インストール済み .NET 11.0.0-rc.1 上で runtimeconfig を一時的に調整して直接実行されており、通常のテストターゲット経由では検証されていません
  • 作成者によれば、PR説明は GitHub Copilot の支援で作成されています

#134908 Update Fedora Helix coverage to 45

  • 作成者: @richlander
  • 作成日時: 2026年09月30日 00:44:03(UTC)
  • マージ日時: 2026年10月22日 18:06:09(UTC)
  • ラベル: area-Infrastructure

概要

Linux x64 の Helix カバレッジのうち、Fedora のバージョンを 44 から 45 に更新するPRです。Fedora 44 は 2027年6月2日までサポートされます。Fedora 45 の固定 EOL 日は未公開で、2027年11月頃になる見込みと記載されています。fedora-45-helix-amd64 コンテナタグは MCR レジストリで確認済みで、sha256:256fcd76faa9078632f0b8c68374f2e9ee45242b9ee7f68bda5f0a51fc28bc90 に固定されています。

対象 スロット 変更前 変更後
Linux x64 Helix Latest Fedora 44 Fedora 45

変更内容

  • eng/pipelines/helix-platforms.yml (+31/-29): Helix プラットフォーム定義を Fedora 44 から 45 に更新
  • eng/pipelines/libraries/helix-queues-setup.yml (+1/-1): Helix キュー定義の Fedora バージョン参照を更新

なお、現行の Azure Linux 3 コンテナホストはそのまま維持されています。

パフォーマンスへの影響

影響なし

関連Issue

  • #134819: ホスト更新を別途行う PR/Issue。マージ順によってはコンフリクトする可能性があります。
  • dotnet/core#9638: .NET OS サポート追跡

その他

  • 検証として、git diff --check、変更した2つの YAML ファイルの Python yaml.safe_load によるパース、Helix キュー定義に Fedora 44 の参照が残っていないことの確認、Fedora 45 コンテナタグとピン留めダイジェストの MCR との照合が行われ、いずれも成功しています。
  • Fedora x64 のカバレッジは runtime-extra-platforms が担うため、このパイプラインの実行が要求されています。

#128981 System.Net.Mail Validation improvements

  • 作成者: @Copilot
  • 作成日時: 2026年06月04日 11:51:29(UTC)
  • マージ日時: 2026年10月22日 11:28:31(UTC)
  • ラベル: area-System.Net

概要

ContentType.Name / ContentDisposition.FileName のシリアライズ時に、値が RFC 2047 のエンコード済みワードで始まるだけで「エンコード済み」と見なされ、引用符内にそのまま追記されていたため、" を含む値で MIME パラメータ（例: filename）をヘッダーに注入できる問題への対策です。エンコード済みワード判定の厳格化と、非該当値を GetTokenOrQuotedString（引用符のエスケープ処理あり）へ回す方針が中心です。

var ct = new ContentType("application/octet-stream");
ct.Name = "=?utf-8?Q?foo?=?evil\"; filename=\"foo.txt";
// 修正前: application/octet-stream; name="=?utf-8?Q?foo?=?evil"; filename="foo.txt"
// （攻撃者が制御する filename パラメータが注入される）

変更内容

  • MimeBasePart.DecodeEncoding（ファイルは変更一覧に含まれず、PR説明・レビュー記載による）: 値全体が、折り返し空白のみで区切られた1つ以上の RFC 2047 エンコード済みワードである場合にのみ非 null を返すよう厳格化。SearchValues<char> を用いた文字検証へリファクタリング。
  • ContentType.cs（+1/-1）、ContentDisposition.cs（+7/-0）: EncodeToBuffer の「手動エンコード済みとしてそのまま通す」分岐を、有効なエンコード済みワードの場合のみ到達するよう調整。
  • Attachment.cs（+15/-2）、Strings.resx（+7/-1）: 変更あり（詳細は提供情報からは不明）。
  • テスト: ContentTypeTest、ContentDispositionTest、AttachmentTest、AlternateViewTest、QuotedPrintableStreamTest に、注入ペイロードおよび正当なエンコード済みワードのラウンドトリップを検証するテストを追加。

パフォーマンスへの影響

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

関連Issue

なし

その他

  • 本PRは System.Net.Mail のヘッダーパラメータ注入に対するセキュリティ強化です（CVE番号の記載なし）。
  • Copilotレビューでは、整形式のエンコード済みワードでも encoded-text に " や \ が含まれ得るため、パススルー分岐が依然として引用符を抜け出して注入を許す可能性があると、複数回指摘されています（例: 空白なしの =?utf-8?Q?foo";filename="x?=）。対策として、パススルー前のエスケープ、またはこれらの文字を含む値をパススルー対象外にする案が挙がっています。
  • 最新のレビューでは、ContentType のエスケープ関連テストが、デコードを行うゲッターに対して生のエンコード済みテキストを期待している点も指摘されています。
  • レビュー指摘は未解決の可能性があり、マージ前に追加修正とテストが必要な状態です（Copilotの判定は「Changes recommended」）。
目次