Pull Request on 2026年07月08日

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

注意点

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


目次

  1. #130352 JIT: fix GC holes in large stack-target struct block ops
  2. #130338 Parenthesize agentic-workflow fork guards to emit valid YAML
  3. #130337 Fix flaky StateMachineAsync_CallstackStressWithVaryingDepths test.
  4. #130329 [main] Source code updates from dotnet/dotnet
  5. #130326 Create ">=0" assertion for unpromoted Span.Length
  6. #130321 Fix exception native to managed transition frame
  7. #130320 Fix inaccurate LogLevel constraint in LoggerMessageAttribute remarks
  8. #130317 JIT: Make all static base helpers byref typed in async functions
  9. #130316 Migrate SafeComHolder and utilcode holders to LifetimeHolder
  10. #130315 Use HashHelpers prime sizing and FastMod for LINQ bucketing
  11. #130308 Revert "Work around CS9363 for nameof of pointer-typed fields"
  12. #130299 Async Profiler: Reuse V1 dispatcher across a method's suspensions.
  13. #130298 Re-enable CurrentCulture_Default_Is_Specific test on iOS CI
  14. #130297 Async Profiler: Instrument custom awaiters in V1 dispatcher.
  15. #130292 Fix NETSDK1242 build error on NativeAOT and the Mono smoke test
  16. #130274 Refactor the various System.Numerics Vector/Matrix/Quaternion/Plane types to require less inlining
  17. #130270 Ignore AssociatedSourceType on UnmanagedCallersOnly in CoreCLR
  18. #130267 [Wasm] handle non-catch try entries in SCC switch dispatch
  19. #130264 Migrate devdiv/dotnet-core-internal-tooling to WIF service connection
  20. #130262 [release/9.0] Update branding to 9.0.19
  21. #130259 [release/8.0] Update branding to 8.0.30
  22. #130257 [cdac] SystemV-AMD64 struct-in-register classifier: enable ARGITER + zero-known-issues on Linux x64
  23. #130236 [release/10.0] Update dependencies from dotnet/xharness
  24. #130235 [release/9.0-staging] Update dependencies from dotnet/xharness
  25. #130210 Add new NumberStyles option to stop parsing on invalid character
  26. #130196 Handle STATUS_OBJECT_NAME_NOT_FOUND in Windows directory enumeration
  27. #130194 [release/9.0-staging] Update dependencies from dotnet/icu
  28. #130193 [release/10.0] Update dependencies from dotnet/icu
  29. #130173 [QUIC] Update MsQuic to the latest 2.5 version
  30. #130161 Add base lightup support for most of the WASM intrinsics
  31. #130137 Add linux-musl to PR host test pipeline
  32. #130070 JIT: Disallow splitting prologs and epilogs across multiple fragments
  33. #130069 [clr-interp][debugger] Skip ResumeInUpdatedFunction for Interpreter
  34. #130063 [release/9.0-staging] Update dependencies from dotnet/runtime-assets
  35. #130011 Remove extra x86 unwind from DBI
  36. #129977 Rename compression WindowLog APIs to WindowLog2
  37. #129966 Arm64: don't fold ldr page offset (PAGEOFFSET_12L) for NativeAOT
  38. #129882 [r2r] Include generic type instantiations from GenericLookupSignature for discovery of virtual methods
  39. #129845 Implement DnsResolver for Windows
  40. #129840 Upgrade gh-aw to v0.81.6 and isolate agentic workflows into copilot-pat-pool environment
  41. #129357 [release/9.0] Update dependencies from dotnet/emsdk
  42. #129355 [release/8.0] Update dependencies from dotnet/emsdk
  43. #129224 Restore Bundled Arguments
  44. #127586 Distinguish CCA vs CLI baseline-build expectations
  45. #114017 Rename rapidjson helper functions; remove in situ parsing

#130352 JIT: fix GC holes in large stack-target struct block ops

  • 作成者: @EgorBo
  • 作成日時: 2026年07月08日 13:02:07(UTC)
  • マージ日時: 2026年07月08日 19:47:59(UTC)
  • ラベル: area-CodeGen-coreclr

概要

スタックに配置されたGCポインタを含む大きな構造体のコピー/ゼロ操作において、GC実行中に部分的に更新されたGCポインタが観察される問題(GC hole)を修正します。JITコンパイラのLowerCopyBlockStore/LowerInitBlockStoreが、管理ヘルパー関数(MEMCPY/MEMZERO)にフォールバックする際にGCセーフポイントを経由していたため、GCが不完全な状態のポインタを見てヒープを破損させる可能性がありました。修正により、アンロール可能なコピーの場合のみ最適化パスを使用し、それ以外ではGC対応のCpObjパスを使用します。また、ゼロ操作はポインタサイズのループを使用するよう変更されました。

変更内容

  • src/coreclr/jit/lower.cpp: LowerCopyBlockStoreでGCポインタ構造体のスタック対象コピーが実際にアンロールされる場合のみ最適化パスを使用するよう調整;LowerInitBlockStoreでGCポインタ構造体のゼロ操作がヘルパー関数の代わりにポインタサイズのループを使用するよう変更(スタック・ヒープ両対応)
  • src/tests/JIT/Regression/JitBlue/Runtime_130286/Runtime_130286.cs: GC hole シナリオを再現するJIT回帰テスト追加
  • src/tests/JIT/Regression/Regression_ro_2.csproj: 新しい回帰テストをプロジェクトに登録

パフォーマンスへの影響

大規模なGC構造体のコピー/ゼロ操作がヘルパーベースからバルク書き込みバリアまたはポインタサイズループへ変更されるため、SPMI benchmarks.runで回帰なし(clean)を確認済み;asmdiffは大規模なGC構造体の対象操作に限定される。

関連Issue

#130286、#128542

その他

  • 修正によりMEMCPY→BULK_WRITEBARRIER、MEMZERO→ポインタサイズループへの変更を確認済み
  • GCStress環境下での回帰テスト実行により検証完了

#130338 Parenthesize agentic-workflow fork guards to emit valid YAML

  • 作成者: @jeffhandley
  • 作成日時: 2026年07月08日 08:23:20(UTC)
  • マージ日時: 2026年07月08日 09:18:19(UTC)
  • ラベル: area-skills

概要

Agentic Workflow定義ファイルのfork guard条件式をパラレン化し、gh aw compileで生成されるYAMLの有効性を確保するもの。単一項の!で始まる条件式がYAMLタグインジケータと解釈されて無効なYAMLが生成される問題を修正。(!github.event.repository.fork)のように括弧で括ることで、有効なYAMLを生成しながら評価結果は同一となる。

変更内容

  • ワークフロー定義の修正(4ファイル):

    • ci-failure-fix.md、ci-failure-scan.md、ci-failure-scan-feedback.md、code-review.mdのfork guard条件をif: (!github.event.repository.fork)に変更
    • 各対応する.lock.ymlファイルをgh aw compile --schedule-seed dotnet/runtimeで再コンパイル
  • ドキュメント追加:

    • shared/pat_pool.README.md:Known Issues欄に「Fork guards must be wrapped in parentheses」エントリを追加

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • ci-failure-fix、ci-failure-scan、ci-failure-scan-feedbackワークフローは無効なlockファイルを生成していた
  • code-reviewワークフローはランタイムでは有効(pull_requestトリガーが複合式ガード生成)だが、一貫性のため修正
  • このバグはon.permissions: {}ワークアラウンドで作成されるpre_activationジョブでのみ発現
  • GitHubがワークフロー実行時に「could not determine a constructor for the tag '!github.event.repository.fork'」エラーで拒否していた

#130337 Fix flaky StateMachineAsync_CallstackStressWithVaryingDepths test.

概要

StateMachineAsync_CallstackStressWithVaryingDepthsテストの非決定的なバッファフラッシュカウント検証を削除し、テストの不安定性を修正しました。テストの本来の目的であるasync呼び出しスタックフレームデータの妥当性検証は保持されています。

変更内容

  • src/libraries/System.Runtime/tests/System.Threading.Tasks.Tests/System.Runtime.CompilerServices/AsyncProfilerV1Tests.cs: バッファフラッシュカウントが3以上であることを検証するアサーション(5行)を削除
  • 削除された検証は、スレッドプール スケジューリングに依存する非決定的なものでした
  • テストは引き続きマーカーcallstackが有効で解決可能なフレームデータを含むこと、および反復ごとに少なくとも1つのマーカーcallstackが発行されることを検証します

パフォーマンスへの影響

影響なし

関連Issue

#129938 #129871

その他

  • テストのみの変更で、プロダクトコードは修正されていません
  • 削除されたバッファオーバーフロー/レント処理の検証は、別のStateMachineAsync最大深度ストレステスト(Depth = byte.MaxValue、Iterations = 128)で決定的に実行されるため、カバレッジ低下なし

#130329 [main] Source code updates from dotnet/dotnet

概要

dotnet/dotnetリポジトリからのコードフロー更新です。ビルド20260707.9に基づいており、複数のコンパイラ、ビルドツール、ランタイムコンポーネント、およびNuGetツール関連の依存関係が更新されています。

変更内容

  • eng/Version.Details.props: 依存パッケージバージョン情報の更新(76行変更)
  • eng/Version.Details.xml: 詳細なバージョン追跡情報の更新(153行変更)
  • global.json: グローバル設定ファイルの更新(4行変更)

更新された主要依存関係:

  • Microsoft.CodeAnalysis関連: 5.10.0-1.26356.103 → 5.10.0-1.26357.109
  • Microsoft.DotNet.Arcade.Sdk他ビルドツール: 11.0.0-beta.26356.103 → 11.0.0-beta.26357.109
  • System.Text.Json、System.Reflection.Metadata: 11.0.0-preview.7.26356.103 → 11.0.0-preview.7.26357.109
  • NuGet.Frameworks、NuGet.Packaging等: 7.9.0-rc.35703 → 7.9.0-rc.35809
  • ランタイムコンポーネント(JIT Tools、LLVM、WebAssembly Node)の各プラットフォーム版(linux-arm64/x64、linux-musl、osx、win等)更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRは自動生成のコードフロー更新(dotnet-maestro[bot])です
  • aspnetcore、fsharp、nuget.client、runtime、sdk等、複数のリポジトリからの変更が同期されています
  • プレビュー版およびベータ版の依存パッケージが含まれています

#130326 Create ">=0" assertion for unpromoted Span.Length

  • 作成者: @EgorBo
  • 作成日時: 2026年07月08日 01:22:58(UTC)
  • マージ日時: 2026年07月08日 18:46:26(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT コンパイラの Assertion Propagation 機能を改善し、未昇格の Span.Length に対して ">= 0" アサーションを生成するようにしました。これにより win-x64 で約 30KB のコード削減を実現しています。

変更内容

  • src/coreclr/jit/assertionprop.cpp: Span.Length の値が常に 0 以上であることを認識するアサーション生成ロジックを追加(+12行)
  • src/coreclr/jit/rangecheck.cpp: 重複していたアサーション処理を削除し、上記の改善に統合(-6行)

パフォーマンスへの影響

  • win-x64 プラットフォームで約 30KB のコード削減(バイナリサイズ削減)
  • 不必要な境界チェックが削減される可能性により、実行時パフォーマンスも向上の見込み

関連Issue

なし

その他

なし


#130321 Fix exception native to managed transition frame

概要

例外がネイティブからマネージコードに遷移する際のフレーム処理を修正しました。ProcessCLRExceptionで使用していたResumableFrameをSoftwareExceptionFrameに置き換え、GCストレステスト中に管理参照がGCに誤ったコンテキストで報告される問題を解決します。

変更内容

  • src/coreclr/vm/exceptionhandling.cpp: SoftwareExceptionFrameの初期化処理を追加・修正
  • src/coreclr/vm/excep.cpp: ネイティブ・マネージ遷移時のフレーム初期化ロジックを追加
  • src/coreclr/vm/frames.h: フレーム定義を更新

パフォーマンスへの影響

影響なし

関連Issue

#129682

その他

この修正は内部実装(ランタイムのフレーム管理)に関するもので、公開APIへの影響はありません。ResumableFrameは実行再開を想定するフレーム型であり、アクティブメソッドのコンテキストが必要とされるため、例外遷移処理には不適切でした。SoftwareExceptionFrameはこの要件に適合し、アクティブなマネージフレームを参照しないため、GCの参照追跡が正確になります。


#130320 Fix inaccurate LogLevel constraint in LoggerMessageAttribute remarks

概要

LoggerMessageAttributeのXMLドキュメント remarks におけるLogLevelパラメータに関する不正確な説明を修正しました。メソッドはLogLevelパラメータを持つ必要がなく、代わりに属性のコンストラクタまたはLevelプロパティで指定できること、未指定時のデフォルト値がLogLevel.Noneであることを明記しました。

変更内容

  • src/libraries/Microsoft.Extensions.Logging.Abstractions/src/LoggerMessageAttribute.cs
    • LoggerMessageAttributeの remarks セクションを更新
    • LogLevelパラメータが「必須」ではなく、複数の指定方法(属性コンストラクタ、Levelプロパティ、メソッドパラメータ)から選択可能であることを明記
    • デフォルト値の説明を追加

パフォーマンスへの影響

影響なし(ドキュメント修正のみ)

関連Issue

#130319

その他

  • この変更は公開APIのドキュメント改善であり、ランタイム動作への影響はありません
  • ログレベルの指定方法に関する開発者の認識誤りを防ぐための修正です

#130317 JIT: Make all static base helpers byref typed in async functions

概要

非同期関数におけるスタティックベースヘルパーの型付けの問題を修正します。従来は TYP_I_IMPL として扱われていたスタティックベースヘルパーを、非同期関数では TYP_BYREF として型付けることで、共通部分式削除(CSE)が非同期サスペンション を超えて不正に適用されるのを防ぎます。これにより、標準的なbyref処理が自動的に正しい制御フロー解析を行うようになります。

変更内容

  • src/coreclr/jit/flowgraph.cpp: fgGetStaticsCCtorHelper内で、compIsAsync()がtrueの場合、ピン留めされたスタティックベースヘルパーの戻り値型をTYP_I_IMPLからTYP_BYREFに変更(+5/-1)

パフォーマンスへの影響

影響なし(正確性の修正であり、パフォーマンスターゲットの変更ではありません)

関連Issue

#130212

その他

この修正は、非同期関数内でのスタティックベースヘルパーの不変性の仮定を取り除き、CSEがサスペンションポイントを超えてヘルパーの結果を再利用することを防ぎます。初期段階ではVN(Value Numbering)の明示的なマーク付けで対応しようとしていましたが、VNPhiDefなどの複雑性のため、型情報で制御する設計に変更されました。


#130316 Migrate SafeComHolder and utilcode holders to LifetimeHolder

概要

CoreCLRのレガシーなRAII(Resource Acquisition Is Initialization)ホルダーを、トレイトベースのLifetimeHolder<Traits>パターンに段階的に移行するPRです。SafeComHolderファミリーとutilcodeローダーヒープホルダーを新しいパターンに統合し、COM解放のモード処理(プリエンプティブ/協調)を明示的に制御できるようにしています。

変更内容

  • COM ホルダーの統合: SafeComHolder → ComHolderAnyMode(モード非依存)および ComHolderPreemp(プリエンプティブモード専用)に移行。前者は内部でSafeReleaseを使用し協調↔プリエンプティブ遷移を自動処理し、後者はプリエンプティブ専用で遷移オーバーヘッドを削減
  • API の変更: SuppressRelease() → Detach()、GetValue() → Detach()、IsNull() → nullptr比較、Extract/Clear/Release → Detach/Freeに統一
  • utilcodeローダーヒープホルダー移行: ReservedMemoryHolder、ThunkMemoryHolderをLifetimeHolderトレイトに移行。所有権を明示的に分離(生ポインタと所有権ホルダーを分離)し、SuppressRelease()パターンを廃止
  • 呼び出しサイトの更新: 26ファイルで新しいホルダーAPI(Detach()、Free())とnullptr比較に統一、void**型キャストを明示的に追加

パフォーマンスへの影響

プリエンプティブスコープで破棄されるComHolderPreemp使用箇所において、協調モード↔プリエンプティブモード間の遷移オーバーヘッドを削減。その他の箇所はComHolderAnyModeで内部処理のみで、実測値は提供されていませんが構造的には同等またはわずかな改善が期待されます。

関連Issue

なし

その他

このPRは内部実装(ランタイムのメモリ管理とCOM相互運用)の変更であり、公開APIの変更は含まれません。ネイティブコードの互換性に関する破壊的変更もありません。マイグレーションはリソース管理の明確化とモード遷移の最適化を目指す内部リファクタリングです。


#130315 Use HashHelpers prime sizing and FastMod for LINQ bucketing

  • 作成者: @tannergooding
  • 作成日時: 2026年07月07日 17:49:24(UTC)
  • マージ日時: 2026年07月08日 03:24:30(UTC)
  • ラベル: area-System.Linq

概要

LINQ の Lookup/Grouping など複数のハッシュ構造が採用していた count * 2 + 1 の成長戦略と単純なモジュロ演算によるバケットインデックスを、Dictionary<TKey, TValue> と同じ方式に統一しました。HashHelpers.ExpandPrime(素数サイズの成長)と HashHelpers.FastMod(64ビット環境での高速モジュロ計算)を採用することで、バケット分布の改善を実現しています。

変更内容

  • System.Linq

    • Lookup.cs: バケット成長を count * 2 + 1 → HashHelpers.ExpandPrime に変更、FastMod用の乗数をキャッシュ
    • .csproj と Strings.resx: HashHelpers.cs のリンク追加と Arg_HTCapacityOverflow リソース文字列の追加
  • System.Linq.Parallel

    • HashLookup.cs: PLINQ 向け HashLookup<,> も同様に ExpandPrime + FastMod に統一(既存の未使用の乗数計算が実装される)
    • .csproj と Strings.resx: 同様のリソース追加
  • System.Linq.AsyncEnumerable

    • ToLookupAsync.cs: 非同期版 AsyncLookup<,> も同一の最適化を適用
    • .csproj と Strings.resx: 同様のリソース追加

全3つの LINQ ハッシュ構造が共通の悪いパターン(% (2n+1))を共有していたため、一貫性をもって修正されました。

パフォーマンスへの影響

  • バケット分布の改善: 素数サイズの採用により、従来の 2^n - 1 より均等な分布が期待される
  • 初期サイズ維持: 既定の初期サイズ 7 は素数であり変更なし(例:7 → 17 への成長は従来の 7 → 15 より適切)
  • 64ビット環境での高速化: FastMod は除算より高速なシフト・乗算を使用(IntPtr.Size == 8 の場合);32ビットはモジュロ演算にフォールバック
  • ベンチマーク数値は提供されていませんが、既存の全テスト(System.Linq.Tests 52,260件、System.Linq.Parallel.Tests 28,932件、System.Linq.AsyncEnumerable.Tests 547件)が全てパスしており、破壊的な振る舞い変化がないことが確認されています。

関連Issue

#128583(別アプローチへの方針転換として参照)

その他

  • 破壊的変更なし: 内部実装の変更であり、パブリック API は変更なし
  • 他の構造は対象外: Microsoft.CSharp NameTable など同様に見えるが、べき乗2サイズのテーブルに & マスク操作を用いる構造(標準的で有効)は意図的に除外
  • ComWrappers.RcwCache(CoreLib)も真の % (len*2+1) 悪パターンを共有するが、COM相互運用特有で正当化が別途必要なため除外
  • PR 作成は GitHub

#130308 Revert "Work around CS9363 for nameof of pointer-typed fields"

概要

Roslyn(C#コンパイラ)の上流でCS9363の修正がコンパイラに統合されたため、ポインタ型フィールドのnameofに関する回避策を元に戻すリバートです。System.Runtimeリフレクションテストで、ハードコードされた文字列リテラルの代わりにnameof(...)を再度使用するようになります。

変更内容

  • src/libraries/System.Runtime/tests/System.Reflection.Tests/FieldInfoTests.cs
    • ポインタ型およびfunction-pointer型フィールドに対して、ハードコードされた文字列リテラル("s_intPtr"、"intPtr"、"s_fcnPtr"など)をnameof(...)式に置き換え
    • GetValue/SetValueテストデータで8行削除、8行追加

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRはCS9363(ポインタ型フィールドに対するnameofの使用に関するコンパイラの警告/制限)の回避策を削除するもので、コンパイラ側の修正により当該回避策が不要になったことを示しています
  • テストコードの可読性・保守性が向上します(マジックストリングからnameofへの変更)

#130299 Async Profiler: Reuse V1 dispatcher across a method's suspensions.

概要

V1(StateMachine)非同期プロファイラーを最適化し、メソッドの各サスペンション時に新しいAsyncStateMachineDispatcherを割り当てるのではなく、単一のディスパッチャーを再利用するようにしました。これにより、N回サスペンドされるメソッドのディスパッチャー割り当てとCreateイベント数がN個からO(1)に削減されます。

変更内容

  • AsyncStateMachineDispatcher / CreateDispatcher: アクティブディスパッチャーの内部ボックスが参照等価である場合、新しいディスパッチャーを割り当てる代わりに既存のディスパッチャーを再利用するガード機構を追加
  • MoveNext呼び出し時の状態リセット: 再利用されるディスパッチャーが前のレジューム サイクルから古い呼び出しスタック情報を保持しないよう、LastContinuationとReachedLastContinuationをリセット
  • AsyncProfiler.CreateAsyncContext.Append: ディスパッチャー割り当てをスキップする再利用パスでも、遅延フレーム追記(CallstackWalk後に登録された親継続など)をフラッシュするヘルパーを追加
  • テストの更新: アサーション不変式を再利用モデルに対応(creates == completes、resumes == suspends + completes)

パフォーマンスへの影響

  • メモリ割り当て削減: メソッドがN回サスペンドされる場合、ディスパッチャー割り当てが減少(N個から1個へ)
  • GC圧力軽減: 不要なDispatcher オブジェクト生成が排除され、特に高頻度な非同期操作でGC圧力が低下
  • Createイベント削減: プロファイリングイベント数が削減されるため、プロファイリングオーバーヘッドが軽減

関連Issue

#130299

その他

  • この変更は asyncv2(v2ディスパッチャー)の既存の動作と合わせるものです
  • 内部実装の最適化であり、公開APIには影響なし
  • 非同期プロファイリングの精度や正確性には影響しません

#130298 Re-enable CurrentCulture_Default_Is_Specific test on iOS CI

概要

iOS/MacCatalyst/tvOS上で無効化されていたCurrentCulture_Default_Is_Specificテストを再度有効化するPRです。このテストは、CultureInfo.CurrentCultureがCI環境の シミュレータで中立的なカルチャ(en)ではなく、具体的なカルチャ(en-US)を返すことを検証します。テストは#111032で無効化されていましたが、本PRでこの問題が解決したかCI基盤を検証するため再度有効化しています。

変更内容

  • src/libraries/System.Runtime/tests/System.Globalization.Tests/CultureInfo/CultureInfoCurrentCulture.cs: iOS/MacCatalyst/tvOSプラットフォームのSkipOnPlatform属性を削除(1行削除)

パフォーマンスへの影響

影響なし

関連Issue

#111501

その他

このテスト再有効化により、iOS/MacCatalyst/tvOSのCI環境でグローバリゼーション動作の差異が継続しているかどうかを検証できます。テストが失敗した場合は、根本的な環境設定またはランタイムの問題の調査が必要になる可能性があります。


#130297 Async Profiler: Instrument custom awaiters in V1 dispatcher.

概要

Async Profiler(V1/StateMachine)を拡張し、カスタム awaiter を使用する continuations を AsyncStateMachineDispatcher でラップして、フレームワーク awaiter(Task/ValueTask など)と同様にインストルメンテーション対象にしました。これにより、カスタム awaiter を経由した再開時にも Create/Resume/Complete イベントが発行されるようになり、async causality chain の可視性が向上します。

変更内容

  • AsyncTaskMethodBuilderT.cs:generic AwaitOnCompleted メソッドで custom awaiter に対して AsyncStateMachineDispatcher を作成するロジックを追加
  • PoolingAsyncValueTaskMethodBuilderT.cs:同様に generic AwaitOnCompleted で dispatcher を作成するロジック追加
  • AsyncStateMachineDispatcher.cs:専用の _moveNextAction フィールドを削除し、Task.m_action スロットで MoveNextAction をバック(フレームワーク builder と同じ パターン)
  • AsyncProfilerV1Tests.cs:カスタム awaiter(ICriticalNotifyCompletion/INotifyCompletion × pooling/non-pooling)の全パターンで Create/Resume/Complete イベント発行を検証するテストケース(4つの InlineData)を追加

パフォーマンスへの影響

AsyncInstrumentation.IsActive + IsEnabled.AsyncProfiler でガードされているため、profiler が無効の場合(通常)は behavioral change および allocation change なし。

関連Issue

#130297

その他

  • NativeAOT への影響なし(V1 は引き続き AsyncStateMachineDispatcherInfo.IsSupported 経由で無効化)
  • 内部実装の変更により、public API への互換性への影響なし

#130292 Fix NETSDK1242 build error on NativeAOT and the Mono smoke test

概要

.NET 11 SDKの新しいエンフォースメントNETSDK1242により、モバイルプラットフォームをターゲットとするNativeAOTおよびMonoビルドが失敗していた問題を修正。NativeAOTでUseMonoRuntime=falseをデフォルト化し、Mono iOS シミュレータパイプラインでSDKチェックをオプトアウトすることで解決。

変更内容

  • Directory.Build.props: UseNativeAOTRuntime=trueの場合、UseMonoRuntime=falseをデフォルト化。マルチターゲットlibs.testsプロジェクトのリストア時に、モバイルターゲットフレームワークが暗黙的にMonoを選択することを防止
  • runtime-extra-platforms-ioslikesimulator.yml: Mono iOS シミュレータスモークテストビルドで_DisableCheckForUnsupportedMonoMobileRuntime=trueを追加し、SDKの非対応Mono モバイルランタイムチェックをオプトアウト

パフォーマンスへの影響

影響なし

関連Issue

#130292

その他

この変更は内部ビルド設定の修正であり、公開APIへの影響はありません。CoreCLRのモバイルレグは既に/p:UseMonoRuntime=falseを指定していたため影響を受けていませんでしたが、NativeAOTレグの補正が必要でした。


#130274 Refactor the various System.Numerics Vector/Matrix/Quaternion/Plane types to require less inlining

概要

System.Numerics(Vector2/3/4、Quaternion、Plane、Matrix3x2/4x4)の型を、複数層のインライン化への依存を減らすようにリファクタリングしました。Vector128<T>ヘルパーを直接呼び出すことで、インライナーへの負荷を軽減し、コンパイル後のコード生成を最適化します。Matrix3x2.Impl.csおよびMatrix4x4.Impl.csを廃止し、実装をメインソースファイルに統合しました。

変更内容

  • Vector128.Numerics.cs: Vector128<float>レベルの距離・長さ・正規化ヘルパーを追加
  • Vector2/3/4.cs: 操作をVector128<T>プラムビングに直接ルーティング、インライン属性の調整、ToString実装の更新
  • Vector2/3.Extensions.cs: ポインタストアおよび非アライメントストアパスの調整
  • Quaternion.cs: 操作をVector128<T>に移行、内部ヘルパー/オーバーロード追加(Quaternion.Slerpの符号判定ロジック変更あり)
  • Plane.cs: 操作をVector128<T>に移行、変換・正規化ロジック更新
  • Matrix3x2/4x4.cs: 別ファイルのImpl実装をメインソースに統合
  • System.Private.CoreLib.Shared.projitems: 廃止されたImpl ファイルのコンパイル対象から削除

パフォーマンスへの影響

インライン化層の削減により、JITコンパイルのコスト削減とメモリ効率の改善が期待できます。直接的なベンチマーク結果は提供されていません。

関連Issue

#130274

その他

注意点: Quaternion.Slerpにおいて、浮動小数点数の符号判定がcosOmega < 0.0fからfloat.IsNegative(cosOmega)に変更されました。この変更は-0.0や特定のNaN値の処理において動作が異なる可能性があります。意図的な変更の場合は、エッジケース(cosOmega == -0.0fなど)をカバーする回帰テストの追加が推奨されます。


#130270 Ignore AssociatedSourceType on UnmanagedCallersOnly in CoreCLR

  • 作成者: @Copilot
  • 作成日時: 2026年07月06日 23:24:27(UTC)
  • マージ日時: 2026年07月08日 15:48:41(UTC)
  • ラベル: area-VM-coreclr

概要

CoreCLRが[UnmanagedCallersOnly]属性の新しいAssociatedSourceType名前付き引数を拒否していた問題を修正します。NativeAOTで有効なアセンブリがCoreClRでMETA_E_CA_UNKNOWN_ARGUMENTエラーで失敗する互換性の問題を解決します。

[UnmanagedCallersOnly(AssociatedSourceType = typeof(UnmanagedCallersOnlyBasicTest))]
public static int ManagedToNativeCallbackTest(int a, int b)
{
    return a + b;
}

変更内容

  • CoreCLR(src/coreclr/vm/callconvbuilder.cpp): UnmanagedCallersOnlyAttributeパーサーでAssociatedSourceType名前付き引数を認識・解析対象に追加。値は解析されて無視されます(NativeAOTの仕様に合わせる)
  • Mono(src/mono/mono/metadata/marshal.c): 属性ブロブのデコード時に、corlibではなくメソッドを定義したイメージを使用するよう修正。これによりcorlib外の型を参照する名前付き引数のデコード失敗を防止
  • テスト(src/tests/Interop/UnmanagedCallersOnlyBasic/UnmanagedCallersOnlyBasicTest.cs): AssociatedSourceTypeを使用したリグレッションテストを追加

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

本修正により、NativeAOTコンパイラが生成したコード(AssociatedSourceTypeを含む)がCoreClRランタイムでも問題なく動作するようになります。属性解析は既存の互換性を損なわず、未知の名前付き引数の拒否から「解析して無視」へ変更されます。


#130267 [Wasm] handle non-catch try entries in SCC switch dispatch

概要

WebAssemblyランタイムにおけるJITコンパイラのSCC(強連結成分)スイッチ・ディスパッチ変換を改善し、try/catch以外のtry entryを正しく処理できるようにしました。SCCディスパッチャーはtry領域内に配置され、外部からのフロー制御は正しくtry entryを経由してディスパッチャーに到達します。これにより複数のネストされたtry headerを通過する制御フローにも対応し、非同期処理のフロー問題を修正しています。

変更内容

  • src/coreclr/jit/fgwasm.cpp: Wasm EH変換時のSCCディスパッチ処理を拡張
    • bbIsTryBegブロック(GT_WASM_JEXCEPT形式以外のtry entry)を単一のSCC entryとして追跡
    • try entryが存在する場合、try領域内にSCCディスパッチャーを生成
    • 外部の先行ブロックからのフローをtry entryを経由してルーティング
    • try headerが既存のWasm EH フロー分割形式でない場合、try headerを分割して tryEntry -> dispatcher -> splitTail の構成を実現
    • 複数のネストされたtry headerを通過するサイドエントリーの処理に対応

パフォーマンスへの影響

影響なし

関連Issue

#130267

その他

  • 制限事項:1つのSCC entryのみがtry entryとなることに変わりなし
  • ランタイムの非同期処理に関連するフロー問題を修正
  • 内部実装の変更(JITコンパイラの制御フロー変換ロジック)

#130264 Migrate devdiv/dotnet-core-internal-tooling to WIF service connection

  • 作成者: @missymessa
  • 作成日時: 2026年07月06日 21:23:56(UTC)
  • マージ日時: 2026年07月08日 10:20:53(UTC)
  • ラベル: area-Infrastructure

概要

内部ツール復元パイプラインの認証方式を、PAT(Personal Access Token)ベースのNuGetサービス接続からWorkload Identity Federation(WIF)ベースのAzure DevOpsサービス接続に移行しています。これはPAT無効化ポリシーへの対応です。

変更内容

  • eng/pipelines/common/restore-internal-tools.yml:
    • NuGetAuthenticate@1タスクの認証方式を変更
    • nuGetServiceConnections(PAT-based) → azureDevOpsServiceConnection + feedUrl(WIF-based)に切り替え
    • 新しいサービス接続:dnceng-devdiv-dotnet-core-internal-tooling-feed-rw-wif(workloadidentityuser型)
    • ターゲットフィード:https://pkgs.dev.azure.com/devdiv/_packaging/dotnet-core-internal-tooling/nuget/v3/index.json

パフォーマンスへの影響

影響なし

関連Issue

なし(ただし、dnceng WI 10124のPAT無効化ポリシー移行の一環)

その他

  • dotnet/roslyn#83918、dotnet/dotnet#6902の devdiv/engineering フィード移行と同じパターンを適用
  • Entraアプリによる認証のためセキュリティ向上が期待できます

#130262 [release/9.0] Update branding to 9.0.19

概要

.NET 9.0ブランチのバージョンブランディングを9.0.18から9.0.19に更新します。

変更内容

  • eng/Versions.props: PatchVersionを18から19に更新(2行追加、2行削除)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 自動化されたdotnet-botによるルーチン的なバージョン更新PR
  • release/9.0ブランチへのバージョン管理のみの変更

#130259 [release/8.0] Update branding to 8.0.30

概要

.NET 8.0 の パッチ バージョンを 29 から 30 に更新するブランディング変更です。release/8.0 ブランチのバージョン管理ファイルが更新されました。

変更内容

  • eng/Versions.props: PatchVersion を 29 から 30 に更新(+2 -2 行)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

なし


#130257 [cdac] SystemV-AMD64 struct-in-register classifier: enable ARGITER + zero-known-issues on Linux x64

概要

cDAC(Compact Data Access Component)の ArgIterator に SystemV-AMD64 構造体レジスタ内分類機能を実装し、Unix x64 での GCRefMap 生成がランタイムと一致するようにしました。これにより Linux x64 での ARGITER ストレステストと zero-known-issues GCREFS アサーションを有効化します。キャッシュされた EEClass::m_eightByteRegistersInfo を読み取り、実行時と同じ分類ロジックを提供することで、バイト単位での完全性を保証します。

変更内容

C++ ランタイム側(データディスクリプタ公開):

  • class.h: cdac_data<EEClass>::OptionalFields フィールド追加
  • methodtable.h: cdac_data<SystemVEightByteRegistersInfo> で NumEightBytes と eightbyte 分類テーブル公開
  • datadescriptor.inc: EEClass.OptionalFields、EEClassOptionalFields、SystemVEightByteRegistersInfo 型を UNIX_AMD64_ABI 条件下で追加

マネージド cDAC 側(分類実装):

  • CdacTypeHandle.cs: GetSystemVAmd64PassStructInRegisterDescriptor メソッド実装(約40行)で OptionalFields → EightByteRegistersInfo を読み取り、SYSTEMV_AMD64_CORINFO_STRUCT_REG_PASSING_DESCRIPTOR に射影
  • CallingConvention_1.cs: ARGITER プラットフォームゲートをホワイトリスト方式から逆方式(RiscV64/LoongArch64/Wasm のみスキップ)に変更
  • GcScanner.cs: deferred-frame ゲートを同様に簡略化
  • テスト用 CallSignatures debuggee:SysVCategory 追加で単一/複数 eightbyte 形状、nested value type、union、Int128Wrapper、スタック渡しケースをカバー

公開 API 変更:

  • IRuntimeTypeSystem.cs: IsIntrinsicType(TypeHandle) 新規追加(Vector128など組み込み型判定)

パフォーマンスへの影響

影響なし。既存キャッシュを読み取るため新規計算不要。Windows x64 ではディスクリプタが生成されないため既存プラットフォームへの回帰なし。

関連Issue

  • #130090(前提となる cDAC ArgIterator ポート作業)
  • #130008(プラットフォームマトリックス追跡)

その他

  • ローカル検証:Windows x64 stress テストで GCREFS/ARGITER とも全パス(既知問題なし)
  • macOS x64 も同じ SystemV パスで動作確認済みだが、Helix stress マトリックスには含めていない
  • ネイティブ P/Invoke レイアウトはキャッシュされないため cDAC は読み取らない(GC スキャン時は非遷移フレーム)
  • UNIX_AMD64_ABI ガード条件によりLinux/macOS x64 のみ有効化

#130236 [release/10.0] Update dependencies from dotnet/xharness

概要

dotnet/xharnessの依存関係を更新するAutomated Dependency Updateです。Microsoft.DotNet.XHarness関連のパッケージを11.0.0-prerelease.26319.2から11.0.0-prerelease.26353.1にアップグレードします。

変更内容

  • eng/Version.Details.props: xharnessパッケージのバージョン情報を更新(3行変更)
  • eng/Version.Details.xml: xharnessパッケージの詳細バージョン情報を更新(6行変更)
  • .config/dotnet-tools.json: dotnet tools設定を更新(1行変更)
  • 更新対象パッケージ:
    • Microsoft.DotNet.XHarness.CLI
    • Microsoft.DotNet.XHarness.TestRunners.Common
    • Microsoft.DotNet.XHarness.TestRunners.Xunit

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRはdotnet-maestro[bot]によるAutomated Dependency Updateです
  • release/10.0ブランチへの更新であり、プレリリース版の依存関係更新です
  • xharnessコミット: 4da0015e9dd1ed7d3992db7d1eb6878a5ee11ab2

#130235 [release/9.0-staging] Update dependencies from dotnet/xharness

概要

dotnet/xharnessの依存関係を更新するプルリクエストです。Microsoft.DotNet.XHarness関連の3つのNuGetパッケージを11.0.0-prerelease.26319.2から11.0.0-prerelease.26353.1にアップグレードしています。

変更内容

  • .config/dotnet-tools.json: dotnetツール設定の更新
  • eng/Version.Details.xml: xharnessのバージョン詳細情報を更新(コミット: 4da0015e9dd1ed7d3992db7d1eb6878a5ee11ab2)
  • eng/Versions.props: プロパティファイルのバージョン番号を更新

更新対象パッケージ:

  • Microsoft.DotNet.XHarness.CLI
  • Microsoft.DotNet.XHarness.TestRunners.Common
  • Microsoft.DotNet.XHarness.TestRunners.Xunit

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 自動更新(dotnet-maestroボットによる依存関係の自動アップデート)
  • release/9.0-stagingブランチへの更新
  • 2026年7月3日のxharnessビルド(Build ID: 321324)に基づいています

#130210 Add new NumberStyles option to stop parsing on invalid character

概要

NumberStylesに新しいAllowTrailingInvalidCharactersフラグを追加し、すべての数値型(整数、浮動小数点、Decimalなど)のTryParseメソッドに「消費した文字/バイト数」を報告する新しいオーバーロードを導入します。この変更により、数値文字列解析時に最初の無効文字で停止し、解析に使用された入力要素の数を取得できます。

// 新しい用法例
if (int.TryParse("123invalid456", NumberStyles.AllowTrailingInvalidCharacters, null, out int value, out int charsConsumed))
{
    // value = 123, charsConsumed = 3
}

// UTF-8オーバーロード
if (int.TryParse(utf8Bytes, NumberStyles.AllowTrailingInvalidCharacters, null, out int value, out int bytesConsumed))
{
    // 同様に消費されたバイト数が取得可能
}

変更内容

  • NumberStyles.cs: 新しいAllowTrailingInvalidCharactersフラグを追加
  • Number.Parsing.cs/Number.Parsing.Common.cs: コア解析ロジックを更新し、elementsConsumedパラメータを追通し、無効文字で解析を停止するロジックを実装
  • すべての数値型(Byte, SByte, Int16, Int32, Int64, Int128, UInt16, UInt32, UInt64, UInt128, Single, Double, Half, Decimal, Decimal32, Decimal64, Decimal128, NFloat): TryParse(..., out int consumed)オーバーロードを追加
  • BigInteger, Complex: 消費カウント対応のTryParseオーバーロードを追加
  • INumberBase<TSelf>: 新しいTryParse(..., out int consumed)のDIM(デフォルト実装メソッド)を追加
  • NumberFormatInfo.cs: AllowTrailingInvalidCharactersを16進数/バイナリスタイル組み合わせで有効にするように検証ロジックを更新
  • ref アセンブリ: 公開APIサーフェスを新しいシグネチャで更新
  • テスト: すべての数値型に対してAllowTrailingInvalidCharactersフラグと消費カウント検証の広範なテストを追加

パフォーマンスへの影響

影響なし(提供情報に記載なし)

関連Issue

#87171 #123944(前のPR)

その他

  • このPRは先行PR #123944の継続で、Copilotによるテスト拡充がメイン(製品コードは手作業で完成)
  • 整数型から浮動小数点数、特殊な数値型、汎用的なINumberBase<T>実装に至るまで、広範なカバレッジが提供されています
  • UTF-8入力に対応したオーバーロードも含まれており、Span<byte>ベースの解析がサポートされます
  • 破壊的変更なし(新しいオーバーロードの追加のみ)

#130196 Handle STATUS_OBJECT_NAME_NOT_FOUND in Windows directory enumeration

  • 作成者: @jeffhandley
  • 作成日時: 2026年07月04日 08:15:58(UTC)
  • マージ日時: 2026年07月08日 01:45:03(UTC)
  • ラベル: area-System.IO

概要

Windows上のディレクトリ列挙で、検索パターンがマッチしたファイルがゼロの場合、一部のファイルシステム(読み取り専用/仮想ファイルシステムなど)が STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034) を返す際に、正しく空の結果を返さず FileNotFoundException をスローしていた問題を修正します。.NET 10.0.9における #127974 の導入により発生した回帰で、Azure App Serviceの WEBSITE_RUN_FROM_PACKAGE デプロイメント環境での報告があります。

変更内容

  • src/libraries/System.Private.CoreLib/src/System/IO/Enumeration/FileSystemEnumerator.Windows.cs
    • FileSystemEnumerator<TResult>.GetData() の既存の STATUS_FILE_NOT_FOUND 処理(マッチなし扱い)に STATUS_OBJECT_NAME_NOT_FOUND のケースを追加
    • 両方のステータスをマッチなし(列挙終了)と同じ動作で処理

パフォーマンスへの影響

影響なし

関連Issue

#130134

その他

  • 標準的なファイルシステム(NTFS、ReFS、UDF、CDFS)では既に処理済みの STATUS_NO_SUCH_FILE (0xC000000F) が返されるため、再現には特定のドライバ(ゼロマッチ時に0xC0000034を返すもの)が必要です
  • 検証時に ntdll!NtQueryDirectoryFile をフック修正してステータスコードを書き換えることで、修正前後での動作を確認済み
  • System.IO.FileSystem.Tests で回帰なしを確認
  • Directory.GetFiles/Directory.EnumerateFiles 及びそのバリアント(DirectoryInfo/Directory.GetFileSystemEntries)が対象

#130194 [release/9.0-staging] Update dependencies from dotnet/icu

概要

dotnet/icu リポジトリからの依存関係を更新するPRです。Microsoft.NETCore.Runtime.ICU.Transport パッケージを 9.0.0-rtm.26313.3 から 9.0.0-rtm.26356.1 にアップデートしています。

変更内容

  • eng/Version.Details.xml: ICU Transport パッケージのバージョン情報を更新(+2/-2)
  • eng/Versions.props: バージョン定義を更新(+1/-1)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 自動依存関係更新PRです(dotnet-maestro[bot]により作成)
  • dotnet/icu の dotnet/release/9.0 ブランチからのビルド (#321642) に基づくアップデート
  • ビルド日時: 2026年7月7日 4:35:11 UTC

#130193 [release/10.0] Update dependencies from dotnet/icu

概要

dotnet/icu依存関係を更新するPull Requestです。Microsoft.NETCore.Runtime.ICU.Transportを10.0.0-rtm.26313.1から10.0.0-rtm.26357.3にアップデートしています。

変更内容

  • eng/Version.Details.props: バージョン情報を1行更新
  • eng/Version.Details.xml: ICU Transport依存関係のバージョン記述を2行更新(古いバージョン削除、新バージョン追加)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このPRはMaestro自動依存関係更新システムによって生成されました(dotnet-maestro[bot])。対象はrelease/10.0ブランチです。


#130173 [QUIC] Update MsQuic to the latest 2.5 version

  • 作成者: @ManickaP
  • 作成日時: 2026年07月03日 11:15:34(UTC)
  • マージ日時: 2026年07月08日 13:02:56(UTC)
  • ラベル: area-System.Net.Quic

概要

QUIC実装で使用されるMsQuic Schannel NuGetパッケージを2.5.7から2.5.9にバージョンアップします。これはランタイムのQUIC実装のビルド依存関係の更新です。

変更内容

  • eng/Versions.props: MicrosoftNativeQuicMsQuicSchannelVersionプロパティを2.5.7から2.5.9に更新(+1/-1行)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

なし


#130161 Add base lightup support for most of the WASM intrinsics

概要

WebAssembly SIMD(PackedSimd)の基本的なlightup対応を追加し、Vector/PackedSimdの多くのintrinsicsをJITコンパイラで処理できるようにします。Shuffle、GetElement、WithElementなど複雑なコード生成が必要なケースは対象外です。corelib crossgenのスループットが11.57%向上します。

変更内容

  • JIT Value Numbering・Assertion分析: PackedSimd.Bitmaskをx86のmovemaskと同様に扱い、最適化を強化
  • WASM下位互換性対応: Vector128のCreate/CreateScalar、equality/inequality演算のlowering実装;Vector128<ulong>の順序比較向けにworkaroundを追加
  • Intrinsic定義の拡張: WASM固有の処理フロー(hwintrinsicwasm.cpp)を更新し、より多くのPackedSimd intrinsicsを有効化;Vector intrinsicsのWASM等価物へのマッピングを拡張
  • コード生成: gentree.cpp でSIMD変換・minmax・拡張演算のWASM実装を追加(CreateScalar/CreateScalarUnsafeはTODO)

パフォーマンスへの影響

  • corelib crossgen のスループット: 11.57%向上
  • アセンブリ出力は回帰(より多くの処理がintrinsic化されると inlining budgetを消費しなくなったため、他のホットコードが効率的にinlineされるように変化)
  • 残りのintrinsicsがすべて対応されると、全体的にはパフォーマンスと品質が改善される見込み

関連Issue

なし

その他

  • Shuffleに依存する複雑なintrinsics(Shuffle、GetElement、WithElement)の対応は今後の課題
  • Azure Pipelinesのビルド結果に詳細な比較データあり
  • 内部実装(JIT コンパイラの最適化テーブル)の変更であり、公開APIへの直接的な影響なし

#130137 Add linux-musl to PR host test pipeline

  • 作成者: @Copilot
  • 作成日時: 2026年07月02日 17:35:21(UTC)
  • マージ日時: 2026年07月08日 20:51:28(UTC)
  • ラベル: area-Infrastructure

概要

Linux musl(Alpine)環境をインストーラー(ホスト)ビルド・テストパイプラインに追加し、musl環境対応を強化します。これにより、PR段階でのmusl環境下での検証カバレッジが拡大されます。

変更内容

  • eng/pipelines/runtime.yml: Installer_Build_And_Testプラットフォーム行列にlinux_musl_x64を追加
  • eng/pipelines/installer/helix.yml: musl実行時に__PortableTargetOS=linux-muslを渡すためのosSubgroup処理を追加
  • src/installer/tests/AppHost.Bundle.Tests/StaticHost.cs: StaticHost.ExpectedExportsを修正し、macOSではnmを使用、Linux(musl)ではnmを優先してllvm-nmにフォールバック(いずれも利用不可な場合はスキップ)する仕様に更新

パフォーマンスへの影響

影響なし

関連Issue

#77800

その他

  • このPRはテストパイプライン拡張とmusl環境対応の強化に焦点を当てており、実行時機能の変更ではなくCI/テストインフラストラクチャの改善です
  • musl環境下でのエクスポート検証ツール選択の柔軟性向上により、Alpine Linuxなどのmuslベース環境での互換性テストが可能になります

#130070 JIT: Disallow splitting prologs and epilogs across multiple fragments

概要

JITコンパイラの命令グループ(IG)分割機能が、アンワインド情報生成中にプロローグを複数フラグメントに分割してしまう問題を修正します。JITは内部的にすべてのフラグメントが全アンワインドコードを実行することでアンワインド可能であることを前提としているため、プロローグの分割はアンワインドメタデータを不正にする原因となっていました。ストレステスト環境での問題です。

変更内容

  • src/coreclr/jit/emit.cpp: STRESS_EMITTERによる強制的な新規命令グループ分割を、compGeneratingUnwindPrologがtrueの場合に禁止する条件を追加(+4/-2)
  • プロローグ分割が禁止される理由を説明するコメントを追加

パフォーマンスへの影響

影響なし。ストレステスト環境での未定義動作の修正であり、通常の実行性能に変更はありません。

関連Issue

#128590、#126552

その他

このプロローグ分割の問題は特にarm32のスレッドハイジャッキングシナリオに影響を及ぼしていました。変更はemitSplitのストレス分割ロジックにのみ影響し、通常のコンパイルには影響しません。


#130069 [clr-interp][debugger] Skip ResumeInUpdatedFunction for Interpreter

概要

CoreCLR インタープリタでのEdit-and-Continue (EnC) デバッグをサポートするために、インタープリタコード実行時の ResumeInUpdatedFunction 呼び出しをスキップするよう変更しました。これにより、インタープリタコードの変更は後続のメソッド実行時に反映されるようになります。

変更内容

  • src/coreclr/debug/ee/debugger.cpp: インタープリタコード実行を検出する処理を追加し、EECodeInfo(GetIP(pContext)).IsInterpretedCode() でインタープリタコードの場合は g_pEEInterface->ResumeInUpdatedFunction() をスキップするように実装

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • この変更はインタープリタコードに限定され、JIT/ネイティブコードの既存の remap 動作は変わりません(互換性への影響なし)
  • Copilot レビュー時に、スキップされた場合のログメッセージが ResumeInUpdatedFunction から戻った旨を述べており、実装と不一致の可能性が指摘されています

#130063 [release/9.0-staging] Update dependencies from dotnet/runtime-assets

概要

dotnet/runtime-assets リポジトリから依存関係を更新するPull Request。複数のテストデータおよびランタイムリソースパッケージを 9.0.0-beta.26309.6 から 9.0.0-beta.26330.2 にアップデートします。

変更内容

  • eng/Version.Details.xml: バージョン詳細情報を更新(+28/-28行)
  • eng/Versions.props: バージョン定義プロパティを更新(+14/-14行)

更新対象パッケージ(9.0.0-beta.26309.6 → 9.0.0-beta.26330.2):

  • Microsoft.DotNet.CilStrip.Sources
  • System.ComponentModel.TypeConverter.TestData
  • System.Data.Common.TestData
  • System.Drawing.Common.TestData
  • System.Formats.Tar.TestData
  • System.IO.Compression.TestData
  • System.IO.Packaging.TestData
  • System.Net.TestData
  • System.Private.Runtime.UnicodeData
  • System.Runtime.Numerics.TestData
  • System.Runtime.TimeZoneData
  • System.Security.Cryptography.X509Certificates.TestData
  • System.Text.RegularExpressions.TestData
  • System.Windows.Extensions.TestData

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 自動依存更新PR(dotnet-maestro[bot]による作成)
  • release/9.0ブランチの定期的なアップデート
  • ビルド日時: 2026年6月30日 10:41:44 UTC

#130011 Remove extra x86 unwind from DBI

  • 作成者: @rcj1
  • 作成日時: 2026年06月30日 01:04:12(UTC)
  • マージ日時: 2026年07月08日 20:35:00(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

DBI(デバッグ情報インターフェース)のx86スタック アンウインド処理を簡略化するPRです。x86フレームポインタの計算をDBI側から削除し、DAC(Data Access Component)のスタックウォーク処理に統合しました。これにより、プラットフォーム固有の詳細をDacDbi APIに隠蔽し、GetStackWalkCurrentFrameInfoへの統一化を実現しています。

変更内容

  • DacDbi COM/DDIインターフェース削除: GetFramePointerメソッドをネイティブ(dacdbi.idl)および管理コード(IDacDbiInterface.cs)から削除
  • スタックウォーク簡略化: CordbStackWalkの「一フレーム先読みキャッシング」メカニズムを削除し、関連する状態管理フィールド(rspriv.h)も削除
  • フレームポインタ計算の移行: x86フレームポインタ計算をdacdbiimplstackwalk.cpp内のGetFramePointerWorker/InitFrameDataに実装
  • コード削減: rsstackwalk.cpp で約112行削除(148行→36行)、整理されたエラーキャッシング処理

パフォーマンスへの影響

影響なし。本変更は構造的な整理で、機能的な最適化ではありません。ただし、キャッシング処理の削減により若干のメモリ使用量削減の可能性があります。

関連Issue

なし

その他

  • 互換性への影響: 公開COM/DDIインターフェースからGetFramePointerが削除されるため、外部デバッガツールがこのメソッドに依存している場合は対応が必要です
  • 動作変更: 呼び出し元が非管理コードの場合、計算ロジックが変更される可能性がありますが、フレーム境界がより正確で整序された順序で提供されることが期待されます
  • 目的: プラットフォーム固有の詳細を可能な限りDacDbiの後ろに隠蔽し、DBI側での個別調整を不要にする設計改善です

#129977 Rename compression WindowLog APIs to WindowLog2

概要

圧縮ライブラリのパブリックAPI命名を統一するため、WindowLog/MaxWindowLog を WindowLog2/MaxWindowLog2 に改称しました。これは base-2 対数値であることを明示的にし、Brotli、zlib、Zstandard 全体での一貫性を確保するものです。

サンプルコード:

var options = new ZstandardCompressionOptions
{
    Quality = 3,
    WindowLog2 = 20
};

var decompressionOptions = new ZstandardDecompressionOptions
{
    MaxWindowLog2 = 20
};

変更内容

公開API表面の変更(破壊的変更):

  • BrotliCompressionOptions.WindowLog → WindowLog2
  • ZLibCompressionOptions.WindowLog → WindowLog2
  • ZstandardCompressionOptions.WindowLog → WindowLog2
  • ZstandardDecompressionOptions.MaxWindowLog → MaxWindowLog2
  • 関連する定数を改称:DefaultWindowLog*、MinWindowLog*、MaxWindowLog* → *WindowLog2
  • エンコーダー/デコーダーのコンストラクタパラメータを改称:windowLog/maxWindowLog → windowLog2/maxWindowLog2

実装の更新:

  • System.IO.Compression、System.IO.Compression.Brotli の全呼び出し箇所を更新
  • ref アセンブリ、プラットフォームスタブ、XML ドキュメント、エラーメッセージを更新
  • ArgumentOutOfRangeException.ParamName の値を改称後の名前に統一

パフォーマンスへの影響

影響なし

関連Issue

#128456

その他

  • 互換性: この変更は意図的なパブリックAPI改称であり、互換性エイリアス/シムは追加されていません(破壊的変更)
  • テスト検証済み:System.IO.Compression.Tests および System.IO.Compression.Brotli.Tests で確認
  • 24ファイルの変更で、テストファイル、実装コード、ref アセンブリをカバー

#129966 Arm64: don't fold ldr page offset (PAGEOFFSET_12L) for NativeAOT

  • 作成者: @EgorBo
  • 作成日時: 2026年06月29日 06:02:03(UTC)
  • マージ日時: 2026年07月08日 00:28:01(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

Arm64 JITコンパイラのPAGEOFFSET_12Lリロケーション折り畳み最適化をNativeAOT向けに制限するもの。PR #129589で追加されたadrp+add+ldr→adrp+ldr[#:lo12:]への折り畳みは、R_AARCH64_LDST64_ABS_LO12_NCリロケーションを使用しており、これは8バイト境界でのアライメントを要求します。NativeAOTでは4バイト・アライメントのバイトパック冷凍データへの直接64ビットロードが可能なため、リンカーエラーが発生していました。この折り畳みをNativeAOT環境では無効化し、安全なadrp+add+ldrにフォールバックします。

変更内容

  • Arm64 JIT出力層 (emitarm64.cpp): TryFoldPageOffsetIntoLdrに環境チェックを追加し、NativeAOT環境では折り畳み最適化をスキップ
  • JIT/AOT間インターフェース定義: corinfo.h、ICorJitInfo_names_generated.h等にターゲット環境判定のための新規メソッドを追加
  • NativeAOT用ノード定義 (IObjectNodeWithAlignment.cs): オブジェクトノードのアライメント要件を明示的に表現するための新規インターフェース追加
  • R2R/NativeAOT依存関係分析: CopiedFieldRvaNode.cs、FieldRvaDataNode.cs、GCStaticsNode.cs、NonGCStaticsNode.csにアライメント情報の取得と伝播を実装
  • SuperPMI計測: MethodContext等の関連ツールが新規JIT呼び出しを記録・再生できるよう対応

パフォーマンスへの影響

改善なし(サイズ最適化の制限)。R2R向けではadrp+ldr[#:lo12:]への折り畳みにより約427Kコンテキストで0個のasm差分を確認し、既存の最適化効果は保持。NativeAOT向けでは18,891コンテキストでリプレイテスト合格。

  • 変更前の問題: NativeAOT時に4バイト・アライメントデータへのリロケーション発行により、ld.lldがエラーimproper alignment for relocation R_AARCH64_LDST64_ABS_LO12_NC: 0x74A52C is not aligned to 8 bytesを出力
  • 変更後: NativeAOT環境では安全な3命令シーケンス(adrp+add+ldr)を保持し、コード生成エラーを回避

関連Issue

#129936(このPRで修正) 関連: #129589(元々の最適化導入)

その他

  • 破壊的変更なし: 公開APIではなく、内部JIT最適化ロジックの条件付け化
  • ターゲットアーキテクチャ: Arm64(aarch64)固有
  • ABI別対応: R2R(ReadyToRun)はアライメント保証の領域構造を持つため最適化継続、NativeAOTはバイトパック冷凍データ

#129882 [r2r] Include generic type instantiations from GenericLookupSignature for discovery of virtual methods

  • 作成者: @BrzVlad
  • 作成日時: 2026年06月26日 05:51:22(UTC)
  • マージ日時: 2026年07月08日 05:31:27(UTC)
  • ラベル: area-ReadyToRun

概要

ReadyToRun (R2R) コンパイルの依存関係解析を改善し、GenericLookupSignatureを通じて型ハンドルを取得する際に、その型の継承された仮想メソッドの検出とコンパイルに必要な型使用情報を記録するようにしました。これにより、ジェネリック辞書ルックアップで得られた型インスタンスに対する仮想メソッドのディスパッチが正しく処理されます。LINQ ソート処理などで約20倍のパフォーマンス改善が見られます。

変更内容

  • GenericLookupSignature.cs: _fixupKind == ReadyToRunFixupKind.TypeHandleの場合、InheritedVirtualMethodsNodeを依存関係として追加。これにより、ジェネリック型インスタンスの仮想メソッド検出が有効になります(TypeFixupSignatureの既存動作をミラーします)
  • GenericLookup.cs: GenericLookupSignatureルートのみでジェネリック型インスタンスに到達するシナリオを実装したテストケース
  • R2RTestSuites.cs: コンパイル結果検証用のxUnitテストを追加し、期待される仮想メソッド(TestA<__Canon,int>.TestMethodなど)が実際にコンパイルされることを確認

パフォーマンスへの影響

改善: LinqBenchmarks.Order00LinqMethodXなどのLINQ ソート処理で約20倍のパフォーマンス改善を実現

関連Issue

なし

その他

内部実装の改善(ReadyToRun コンパイラの依存関係解析ロジック)であり、公開APIへの影響はありません。


#129845 Implement DnsResolver for Windows

  • 作成者: @rzikm
  • 作成日時: 2026年06月25日 11:31:23(UTC)
  • マージ日時: 2026年07月08日 13:54:01(UTC)
  • ラベル: area-System.Net

概要

System.Net.NameResolutionに新しいDNS照会API(Dns.Resolve*静的メソッド、DnsResolver/DnsResolverOptions、レコード型)を追加し、Windows上でDnsQueryExを使用して実装します。A/AAAA/SRV/MX/TXT/CNAME/PTR/NSレコード、DnsResponseCode列挙型、DnsResult<T>エンベロープをサポートします。非Windows プラットフォームは将来の実装までPlatformNotSupportedExceptionを返します。

// 静的メソッドの使用例
var result = await Dns.ResolveAsync("example.com", DnsRecordType.A);
var addresses = result.Records;

// インスタンスベースAPIの使用例
var options = new DnsResolverOptions { NameServers = new[] { IPAddress.Parse("8.8.8.8") } };
var resolver = new DnsResolver(options);
var mxRecords = await resolver.ResolveMXAsync("example.com");

変更内容

  • 公開API追加(ref assembly):
    • Dns.ResolveAsync/Dns.Resolve(A/AAAA/SRV/MX/TXT/CNAME/PTR/NSレコード対応)
    • DnsResolverクラス(インスタンスベース照会、カスタムネームサーバー対応)
    • DnsResolverOptionsクラス(オプション構成)
    • レコード型:AddressRecord、SrvRecord、MxRecord、TxtRecord、CNameRecord、PtrRecord、NsRecord
    • DnsResult<T>ジェネリック型(ResponseCode/Records/NegativeCacheTtl)
    • DnsResponseCode列挙型(DNS応答コード)
  • Windows実装(内部PAL):
    • DnsResolverPal.Windows.cs:DnsQueryExを使用したDNS照会・解析、キャンセレーション対応、TXT/SRV解析、SOAからの負キャッシュTTL抽出
    • Windows Interop P/Invoke定義(DnsQueryEx、DnsCancelQuery、DnsFree)
  • 非Windows実装(内部PAL):
    • DnsResolverPal.Unsupported.cs:PlatformNotSupportedException スタブ
  • テスト:
    • 引数検証・ネットワークシナリオテスト
    • ループバックDNSサーバーを用いた確定的なWindowsテスト
    • テレメトリ統合

パフォーマンスへの影響

影響なし(新機能追加、既存APIへの変更なし)

関連Issue

#19443

その他

  • このPRは#129302の置き換え
  • 非Windowsプラットフォーム対応は別PRとして段階的に実装予定
  • 新しい公開APIでpartial Dnsクラスに対応

#129840 Upgrade gh-aw to v0.81.6 and isolate agentic workflows into copilot-pat-pool environment

  • 作成者: @jeffhandley
  • 作成日時: 2026年06月25日 05:49:54(UTC)
  • マージ日時: 2026年07月08日 07:48:32(UTC)
  • ラベル: area-skills

概要

gh-aw (GitHub Agentic Workflows) をv0.81.6にアップグレードし、すべてのエージェンティックワークフローを copilot-pat-pool という独立した環境に隔離します。これにより、PAT(Personal Access Token)プール管理を環境ベースで制御し、セキュリティを強化します。また、不要になった copilot-echo ワークフローを削除し、PAT プールドキュメントを更新します。

変更内容

  • gh-aw アップグレード: v0.81.6への更新により、すべてのロックファイル(.lock.yml)が再コンパイルされ、アクションおよびコンテナピンが更新されました
  • 環境隔離の導入: agentic workflowsが copilot-pat-pool 環境で実行されるよう設定し、pat_pool.md インポートに環境入力を必須化
  • ワークフロー更新: code-review、ci-failure-scan、ci-failure-fix、breaking-change-doc などのワークフローが環境パラメータを明示的に渡すように更新
  • ドキュメント更新: PAT プール README とワークフロー README を更新し、新しい環境ベースのセットアップを反映
  • ワークフロー削除: copilot-echo.md と copilot-echo.lock.yml を削除(不要なエコーハーネスワークフロー)
  • 依存関係設定: dependabot.yml を調整し、gh-aw で管理される依存関係の無視ルールを更新
  • アクションロック更新: .github/aw/actions-lock.json を gh-aw v0.81.6用に更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPull Requestの説明の一部はGitHub Copilotの支援を受けて作成されました
  • Copilotは18ファイル中16ファイルをレビューし、8件のコメントを生成しました
  • 新しく agentics-maintenance.yml ワークフロー(614行)が追加されました

#129357 [release/9.0] Update dependencies from dotnet/emsdk

概要

release/9.0 ブランチの依存関係を更新するPRです。dotnet/emsdkリポジトリの更新に伴い、JIT Tools、Mono LLVM SDK/Toolsなどのランタイムコンポーネント複数版を新しいビルド(26329.2)に更新し、Emscripten Workloadマニフェストも9.0.19にアップデートしています。

変更内容

  • eng/Version.Details.xml: Microsoft.NET.Workload.Emscripten関連の依存パッケージを複数プラットフォーム(linux-arm64、linux-x64、linux-musl-arm64、linux-musl-x64、win-arm64、win-x64、osx-arm64、osx-x64)で一括更新
    • runtime.*.Microsoft.NETCore.Runtime.JIT.Tools: 19.1.0-alpha.1.26256.3 → 19.1.0-alpha.1.26329.2
    • runtime.*.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk: 19.1.0-alpha.1.26256.3 → 19.1.0-alpha.1.26329.2
    • runtime.*.Microsoft.NETCore.Runtime.Mono.LLVM.Tools: 19.1.0-alpha.1.26256.3 → 19.1.0-alpha.1.26329.2
    • Microsoft.SourceBuild.Intermediate.emsdk: 9.0.18-servicing.26310.2 → 9.0.19-servicing.26356.3
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100: 9.0.18 → 9.0.19
  • eng/Versions.props: 上記の依存バージョン定義を更新
  • NuGet.config: パッケージソース設定を軽微に調整

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このPRは自動依存関係更新ツール(dotnet-maestro[bot])によって作成されており、Coherency Update機構により親依存関係(Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport)の構築に含まれたコンポーネントのバージョン同期を保証しています。


#129355 [release/8.0] Update dependencies from dotnet/emsdk

概要

dotnet/emsdkリポジトリからの依存関係を更新します。Emscripten関連パッケージを8.0.29から8.0.30へアップデートし、WebAssembly開発ワークロードの最新版を取得します。

変更内容

  • NuGet.config: パッケージソース設定の更新(+1/-1)
  • eng/Version.Details.xml: 依存関係メタデータの更新
    • Microsoft.SourceBuild.Intermediate.emsdk: 8.0.29-servicing.26303.5 → 8.0.30-servicing.26356.2
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: 8.0.29 → 8.0.30
  • eng/Versions.props: バージョン参照の更新(+1/-1)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 自動依存関係更新(dotnet-maestro[bot]による)
  • release/8.0ブランチ向けの更新
  • 更新元: dotnet/emsdk commit 86f69e111f0c65545820c13c1008f63c3a673ea1(2026年7月7日)

#129224 Restore Bundled Arguments

概要

arm32環境向けの回避策を削除し、元の動作を復元するPR。PR #128728での例外処理改善により、以前必要だった回避策が不要になったため、bundled argumentsの機能を復元します。

変更内容

  • src/coreclr/vm/interpexec.cpp: bundled arguments関連のロジック復元(35行追加、50行削除)
  • src/coreclr/vm/interpexec.h: arm32環境向けの回避策コード削除(1行追加、42行削除)
  • src/coreclr/vm/prestub.cpp: 最小限の変更(2行追加、3行削除)
  • src/coreclr/vm/wasm/calldescrworkerwasm.cpp: WASM環境の修正(1行追加、2行削除)
  • src/coreclr/vm/wasm/helpers.cpp: WASM環境のヘルパー処理更新(13行追加、14行削除)

パフォーマンスへの影響

記載なし

関連Issue

#128728(ネイティブ例外処理改善により回避策の必要性が解消)

その他

  • ランタイム(coreclr)のVM層(実行エンジン)における内部実装の変更
  • arm32アーキテクチャとWebAssembly環境に影響
  • 公開APIレベルの変更なし
  • 破壊的変更なし

#127586 Distinguish CCA vs CLI baseline-build expectations

  • 作成者: @steveisok
  • 作成日時: 2026年04月29日 21:56:27(UTC)
  • マージ日時: 2026年07月08日 15:02:08(UTC)
  • ラベル: area-Infrastructure

概要

copilot-instructions.mdの「Baseline Build」セクションを、CCA(Copilot Code Analysis)とCLI(対話的使用)の2つのモードに分割し、各モードの実運用ニーズに合わせた異なるガイダンスを提供するように改善しました。CCAは変更なく厳密性を維持し、CLIは既存の成果物がある場合のスキップを許容しつつ、プローブ&フォールバック戦略で信頼性を確保しています。

変更内容

  • Baseline Build セクションの分割

    • 「When running under CCA — MANDATORY」:既存の厳密な言語を維持。MUST/BEFORE/例外なし/失敗で停止
    • 「When running under CLI (interactive) — flexible」:新規追加。以下の柔軟なルール
      1. artifacts/下のコンポーネント別Sentinel成果物をチェック(欠落時はbaseline実行)
      2. インクリメンタル作業を試み、baseline欠落エラーが発生したら1回のみbaseline実行して再試行
      3. ユーザーの明示的シグナル(「just built」/「fresh checkout」)を尊重
  • 各コンポーネント別ワークフローにSentinel パス明記:Libraries、CoreCLR、Mono、WASM Libraries、Host、Tools、Build Tasks、Runtime Testsの各セクションに、モデルが単一コマンドで確認可能なbaseline sentinel パスを追加

  • 「clean working tree」のガイダンス軟化:baseline先行の場合(clean HEAD必須)と baseline後行プローブの場合(作業内容の退避またはbaseline組み込み受容)の両方を承認

パフォーマンスへの影響

CLI利用時に既存の成果物がある場合、不要な40分のbaseline ビルドをスキップできるため、ターンアラウンド時間が大幅に短縮。CCA(無人実行環境)のパフォーマンスへの影響はなし。

関連Issue

なし

その他

  • タイムアウトやキャッシュの不一致による混乱を軽減する実用的なドキュメント改善
  • デフォルト安全側ルール:「実行モードが不確かな場合はCCAルールに従う」により、誤分類時の成果物欠落を防止
  • ドキュメント変更のみで、ランタイム/コンパイラ/ライブラリの実装は対象外

#114017 Rename rapidjson helper functions; remove in situ parsing

  • 作成者: @GrabYourPitchforks
  • 作成日時: 2025年03月28日 16:30:59(UTC)
  • マージ日時: 2026年07月08日 20:29:34(UTC)
  • ラベル: area-Host

概要

rapidjsonのヘルパー関数をセキュリティ指向でリネームし、インサイチュ解析を削除する変更です。Microsoft内でのセキュリティコンプライアンス要件に対応するため、関数名をparse_fully_trusted_raw_dataとparse_fully_trusted_fileに変更し、呼び出し時点で信頼できるデータのみを処理していることを明示します。同時に、不適切にフォーマットされたJSONをmmap対象のファイルから解析する際にAVが発生する問題を解決するため、インサイチュ解析を削除して通常の解析に統一します。

変更内容

  • json_parser.h: parse_fully_trusted_raw_dataとparse_fully_trusted_fileへの関数名変更(2箇所)
  • json_parser.cpp: インサイチュ解析ロジック削除、通常の解析への統一、エラー位置の行列情報計算の改善(19行追加/-25行削除)
  • 各呼び出し側ファイル: 6ファイル(clsidmap.cpp、sdk_resolver.cpp、deps_format.cpp、runtime_config.cpp)でリネーム後の関数名に対応(計8箇所更新)

パフォーマンスへの影響

インサイチュ解析の削除により、若干のメモリコピーオーバーヘッドが増加する可能性がありますが、具体的なベンチマーク結果の記載はありません。ただし、このトレードオフはセキュリティリスク(AVクラッシュ)を排除するための必要な変更です。

関連Issue

なし

その他

  • インサイチュ解析がrapidJSONのParseInsituAPIでは明示的な長さパラメータを受け取れないため、mmap対象ファイルで未ヌル終端文字が保証されない場合にAVが発生する問題に対応しています。
  • Copilot reviewerが7ファイルのC++言語サポート不足により完全なレビュー実施できていません。
  • 低信頼度のコメントとして、CRLF検出ロジックの境界条件確認に関する指摘がありますが、本変更の主目的外です。

目次