Pull Request on 2026年02月02日

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

注意点

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

目次

  1. #123908 [Wasm Ryujit] Flow cannot fall through into a throw helper
  2. #123902 Revert TargetFramework to net10.0 in BlazorWebWasm test assets for backport branch
  3. #123899 Fix ListDictionaryInternal.Count to not be O(n)
  4. #123893 Avoid unnecessary DirectoryInfo allocation in FileInfo.MoveTo
  5. #123886 Lazy-initialize DateTimeFormatInfoScanner.m_dateWords
  6. #123881 Fix ElidedBoundsChecks test failure under jitstress_isas_nohwintrinsic
  7. #123862 Replace outdated Array.Empty comments with correct reason
  8. #123849 Cleanup dead code in object manipulation
  9. #123845 Introduce factory methods to create assertions
  10. #123832 Replace some uses of MethodDescCallSite with UnmanagedCallersOnly methods
  11. #123826 Add null check for ThreadLocalStoragePointer in COMUnhandledExceptionFilter to prevent crash on Windows
  12. #123818 Fix HFA tests with interpreter
  13. #123817 Fix reachable Debug.Assert in InterleavedZipPackagePartStream.Length
  14. #123811 ignore async thunks when iterating the async continuation chain
  15. #123795 Add JIT regression test extraction skill
  16. #123787 Fixed LoggerMessageGenerator message escaping.
  17. #123777 Fix XUnitWrapperGenerator handling of SkipOnCoreClrAttribute with no runtime test modes
  18. #123768 [release/8.0-staging] Bump iOS & tvOS queues
  19. #123766 [release/9.0] Bump macos helix queues
  20. #123762 [release/10.0] __ComObject doesn't support dynamic interface map (redux)
  21. #123656 Polyfill span.Contains(T)
  22. #123649 [release/10.0] Source code updates from dotnet/dotnet
  23. #123629 [browser][coreCLR] finalizer on a browser event loop
  24. #123615 [release/10.0] Update dependencies from dnceng/internal/dotnet-optimization
  25. #123531 Add DecompressionMethods.Zstandard for HTTP automatic decompression
  26. #123471 [release/9.0-staging] Update dependencies from dotnet/icu
  27. #123386 [main] Source code updates from dotnet/dotnet
  28. #123342 ServiceProviderEngineScope should aggregate exceptions in Dispose rather than throwing on the first
  29. #123115 Fix vectorization of Ascii.Equals for lengths 8..15
  30. #123022 Arm64: Fix for 96441
  31. #117571 JIT: Move remaining xarch floating->integral cast implementation to lowering

#123908 [Wasm Ryujit] Flow cannot fall through into a throw helper

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年02月02日 19:13:30(UTC)
  • マージ日時: 2026年02月02日 23:45:56(UTC)
  • ラベル: area-CodeGen-coreclr

概要

Wasm RyuJIT におけるコントロールフロー制御の不正な落下(fall-through)を修正するPR です。throw helper ブロックに対して新しい BBF_THROW_HELPER フラグを導入し、複雑なヒューリスティック検出ロジック（約60行）をシンプルなフラグチェックに置き換えました。これにより、ブロック途中からの分岐時に throw helper への不正な落下を防止します。

変更内容

  • src/coreclr/jit/block.h: BBF_THROW_HELPER フラグを追加し、throw helper ブロックの分割を防止するため BBF_SPLIT_NONEXIST に含める
  • src/coreclr/jit/flowgraph.cpp: throw helper ブロック作成時に BBF_THROW_HELPER フラグを設定し、フラグ整合性を検証するアサーション追加
  • src/coreclr/jit/compiler.hpp: 複雑な約60行のヒューリスティック検出ロジックを単純なフラグチェックに置き換え
  • src/coreclr/jit/fgwasm.cpp: throw helper ブロックへの落下防止ロジックを追加

パフォーマンスへの影響

影響なし。本変更はコントロールフロー制御の正確性を向上させ、Wasm コンパイル時の複雑なヒューリスティック検出ロジックを廃止することで、むしろコンパイル効率がわずかに向上する可能性があります。

関連Issue

Issue #123908

その他

  • この修正は Wasm バックエンド固有の問題で、他のプラットフォームには影響しません
  • フラグベースのアプローチにより、throw helper の検出がより明示的で保守しやすくなります
  • 変更は内部実装に限定され、公開API には影響しません

#123902 Revert TargetFramework to net10.0 in BlazorWebWasm test assets for backport branch

  • 作成者: @Copilot
  • 作成日時: 2026年02月02日 18:14:50(UTC)
  • マージ日時: 2026年02月02日 18:33:54(UTC)
  • ラベル: 指定なし

概要

BlazorWebWasm テスト アセットのターゲットフレームワークを net11.0 から net10.0 に修正するバックポートブランチ向けの変更です。release/10.0 ブランチに対応させるため、テストプロジェクトの設定を正しいフレームワークバージョンに戻しています。顧客コードには影響なく、テスト インフラストラクチャのみの修正です。

変更内容

  • BlazorWebWasm.csproj: TargetFramework を net11.0 → net10.0 に変更
  • BlazorWebWasm.Client.csproj: TargetFramework を net11.0 → net10.0 に変更

両ファイルともテストアセットの設定変更のみで、各ファイル1行の変更（+1/-1）です。

パフォーマンスへの影響

影響なし。テストプロジェクト設定の修正であり、ランタイムやコンパイラ動作に影響を与えません。

関連Issue

main PR #123883

その他

  • 対象ブランチ: release/10.0 バックポート用
  • 影響範囲: Wasm.Build.Tests.Blazor.AssetCachingTests のテスト資産のターゲット設定
  • リスク評価: 最小限（テストプロジェクト設定のみ、出荷コードへの影響なし）
  • テスト対象: テストアセットが正しいフレームワークバージョンをターゲットしていることを確認

#123899 Fix ListDictionaryInternal.Count to not be O(n)

  • 作成者: @stephentoub
  • 作成日時: 2026年02月02日 17:41:49(UTC)
  • マージ日時: 2026年02月02日 23:39:18(UTC)
  • ラベル: area-System.Collections

概要

ListDictionaryInternal内のNodeKeyValueCollectionクラスのCountプロパティをO(n)からO(1)に最適化しました。従来の実装では全ノードをトラバースして件数をカウントしていましたが、親リストが既に管理しているcountフィールドを直接参照するよう改善されています。

// 改善前: O(n)トラバース
public int Count
{
    get
    {
        int count = 0;
        for (DictionaryNode node = list.head; node != null; node = node.next)
            count++;
        return count;
    }
}

// 改善後: O(1)直接参照
public int Count => list.Count;

変更内容

  • src/libraries/System.Private.CoreLib/src/System/Collections/ListDictionaryInternal.cs
    • NodeKeyValueCollection.ICollection.Countプロパティの実装を変更
    • リンクリスト全体のトラバース処理を削除（-12行）
    • 親のListDictionaryInternalが管理するcountフィールドへの直接参照に変更（+1行）

パフォーマンスへの影響

改善内容: ビッグオー記法でO(n)→O(1)に改善

  • 小規模な辞書では差は微少ですが、大規模な辞書でのカウント取得時に顕著な改善が期待できます
  • 不要なノードトラバースが完全に排除されるため、メモリアクセスも削減

懸念点: 特に懸念なし（ListDictionaryInternalは既にcountフィールドを正確に管理している）

関連Issue

#123899

その他

ListDictionaryInternalは比較的使用頻度の低いコレクション型ですが、この最適化により不必要なパフォーマンス低下は除去されました。公開API仕様に変更はなく、互換性への影響はありません。

#123893 Avoid unnecessary DirectoryInfo allocation in FileInfo.MoveTo

  • 作成者: @stephentoub
  • 作成日時: 2026年02月02日 16:00:58(UTC)
  • マージ日時: 2026年02月02日 21:14:38(UTC)
  • ラベル: area-System.IO

概要

FileInfo.MoveTo メソッドにおいて、不要な DirectoryInfo オブジェクトの割り当てを削除する最適化です。new DirectoryInfo(Path.GetDirectoryName(FullName)!).Exists を Directory.Exists(Path.GetDirectoryName(FullName)) に置き換え、同等の機能を保ちながらメモリ割り当てを削減します。

変更内容

ファイル 変更内容
src/libraries/System.Private.CoreLib/src/System/IO/FileInfo.cs DirectoryInfo インスタンスの不要な生成を排除。Directory.Exists() の直接呼び出しに置き換え、null チェックロジックを簡潔化

パフォーマンスへの影響

改善点：

  • DirectoryInfo オブジェクト割り当て時のヒープメモリ使用量を削減
  • FileInfo.MoveTo 呼び出し時のガベージコレクション圧力を軽減
  • 公開 API の外部向け呼び出しパスでの高頻度使用を想定した軽微な改善

互換性：

  • 機能的には完全に互換性あり（ディレクトリ存在判定の結果は同一）
  • 公開 API の動作変更なし（内部実装最適化）

関連Issue

なし

その他

  • 変更は System.Private.CoreLib（ランタイム基本ライブラリ）の内部実装に限定
  • null 安全性を維持しつつコード行数を削減（! null-forgiving operator を不要化）
  • I/O パス最適化の一環としてシンプルで効果的な改善

#123886 Lazy-initialize DateTimeFormatInfoScanner.m_dateWords

  • 作成者: @stephentoub
  • 作成日時: 2026年02月02日 14:59:29(UTC)
  • マージ日時: 2026年02月02日 19:44:08(UTC)
  • ラベル: area-System.Globalization

概要

DateTimeFormatInfoScannerの内部フィールドm_dateWordsをレイジー初期化に変更するPRです。日付単語を持たないカルチャが多くある中で、不要なメモリ割り当てを避けることができます。既に初期化チェックは実装されていたため、変更は限定的です。

// 変更前：常に初期化
private List<string> m_dateWords = new();

// 変更後：遅延初期化
private List<string>? m_dateWords;

// 使用箇所で初期化
m_dateWords ??= [];

変更内容

  • ファイル: src/libraries/System.Private.CoreLib/src/System/Globalization/DateTimeFormatInfoScanner.cs
    • m_dateWordsフィールドの型をList<string>からList<string>?に変更（レイジー初期化対応）
    • レガシーコメントをXML <summary>コメントに置き換え
    • GetDateWordsOfDTFIメソッドをパターンマッチングとList.ToArray()を使用して簡略化
    • コメントの誤字修正（"Enumarate" → "Enumerate"）

パフォーマンスへの影響

改善: メモリ使用量の削減

  • 日付単語を持たないカルチャ（大多数）では、不要なList<string>インスタンスの割り当てが発生しなくなります
  • 初期化コストの削減により、DateTime.Parse操作の起動時間が微小に改善される可能性があります

関連Issue

#123886

その他

  • 破壊的変更なし（内部実装の変更のみ）
  • 既に初期化チェックが実装されていたため、ロジック変更は最小限

#123881 Fix ElidedBoundsChecks test failure under jitstress_isas_nohwintrinsic

  • 作成者: @Copilot
  • 作成日時: 2026年02月02日 11:48:11(UTC)
  • マージ日時: 2026年02月02日 19:06:31(UTC)
  • ラベル: 指定なし

概要

ElidedBoundsChecksテストの失敗を修正するPRです。CountDigitsメソッドがulong.Log2()を使用しており、このメソッドがハードウェア命令（x64のLzcnt、ARM64のArmBase）に依存しているため、jitstress_isas_nohwintrinsic実行時に境界チェック除外が機能せず、テストアサーションが失敗していました。対象のメソッド呼び出しをハードウェア命令の利用可能性で条件付けることで解決しています。

変更内容

  • ファイル: src/tests/JIT/opt/RangeChecks/ElidedBoundsChecks.cs
    • CountDigitsテスト実行時に、Lzcnt.X64.IsSupported || ArmBase.Arm64.IsSupportedの実行時ガード追加
    • 名前空間インポート追加: System.Runtime.Intrinsics.X86、System.Runtime.Intrinsics.Arm
// Requires HWIntrinsics to expand Log2.
if (Lzcnt.X64.IsSupported || ArmBase.Arm64.IsSupported)
{
    if (CountDigits(1) != 1)
        return 0;

    if (CountDigits(10000000000000000000UL) != 20)
        return 0;
}

パフォーマンスへの影響

影響なし。テストの条件分岐追加のみで、実装時のパフォーマンス最適化には関連しません。ハードウェア命令が利用不可の環境では、CountDigits検証がスキップされます。

関連Issue

dotnet/runtime#123868

その他

このテストはX64-NOT: CORINFO_HELP_RNGCHKFAILアサーションで境界チェック除外が機能していることを検証するため、ハードウェア命令に依存しています。修正により、利用不可環境ではテスト対象を限定しつつ、利用可能環境では最適化検証を継続します。

#123862 Replace outdated Array.Empty comments with correct reason

  • 作成者: @Copilot
  • 作成日時: 2026年02月01日 22:12:34(UTC)
  • マージ日時: 2026年02月02日 00:59:13(UTC)
  • ラベル: 指定なし

概要

このPRは、CA1825ルール抑制コメントの誤った説明を修正するものです。3つのライブラリファイルで「Array.Empty() doesn't exist in all configurations」という古い理由から、正確な理由である「avoid the extra generic instantiation for Array.Empty()」に更新しました。これは、汎用インスタンス化のオーバーヘッドを回避する実装上の最適化が理由であることを明確にしています。

変更内容

  • System.Collections.Immutable/ImmutableArray_1.Minimal.cs: 2行コメントから1行コメントに変更し、理由を明確化（+1/-2）
  • System.Diagnostics.DiagnosticSource/Activity.cs: pragma警告コメント内容を更新（+1/-1）
  • System.Threading.Tasks.Dataflow/Internal/ImmutableArray.cs: pragma警告コメント内容を更新（+1/-1）

変更前後の比較:

// 変更前
#pragma warning disable CA1825 // Array.Empty<T>() doesn't exist in all configurations

// 変更後
#pragma warning disable CA1825 // avoid the extra generic instantiation for Array.Empty<T>()

パフォーマンスへの影響

影響なし。本PRはコメントの説明を修正するもので、実装コードには変更がありません。ただし、コメント内容が正確になることで、new T[0]を使用している理由（汎用インスタンス化によるオーバーヘッド回避）が開発者に対して適切に伝わるようになります。

関連Issue

PR #123854の指摘を受けた修正

その他

なし

#123849 Cleanup dead code in object manipulation

  • 作成者: @huoyaoyuan
  • 作成日時: 2026年02月01日 04:06:38(UTC)
  • マージ日時: 2026年02月02日 00:51:43(UTC)
  • ラベル: area-VM-coreclr community-contribution

概要

オブジェクト操作関連の未使用コードを削除するクリーンアップPRです。CoreCLRのVM層における使用されていない関数、マクロ定義、ヘッダー宣言を削除し、コードベースの保守性を向上させています。合計9ファイルで326行のコードが削除されました。

変更内容

  • src/coreclr/inc/cor.h: 未使用マクロ定義を削除（-10行）
  • src/coreclr/tools/metainfo/mdinfo.cpp/h: メタデータ情報ツールの未使用関数を削除（-50行）
  • src/coreclr/vm/callhelpers.h: 未使用の呼び出しヘルパー関数を削除（-2行）
  • src/coreclr/vm/corelib.h: CoreLIBの未使用宣言を削除（-31行）
  • src/coreclr/vm/dwreport.cpp/h: Debugger Write Report機能の未使用コード全体を削除（-105行）
  • src/coreclr/vm/object.cpp/h: オブジェクト操作の未使用関数・マクロを削除（-104行）

パフォーマンスへの影響

影響なし。本変更は不要なコード行の削除のため、バイナリサイズがわずかに削減される可能性がありますが、実行時パフォーマンスへの影響はありません。

関連Issue

なし

その他

  • 本変更は破壊的変更ではなく、内部実装の整理です
  • 削除されたコードが外部ライブラリやパブリックAPIとして使用されていないことが前提となっています
  • CoreCLRのVM層における技術負債削減を目的とした保守性向上の取り組みです

#123845 Introduce factory methods to create assertions

  • 作成者: @EgorBo
  • 作成日時: 2026年01月31日 20:03:50(UTC)
  • マージ日時: 2026年02月02日 18:05:41(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT コンパイラのアサーション処理をリファクタリングするゼロ差分のクリーンアップ変更です。AssertionDsc オブジェクトの生成に専用のファクトリメソッド（AssertionDsc::Create*）を導入し、AssertionDsc* ポインタを const AssertionDsc& 参照に置き換えることで、メモリセーフ性を向上させ、TP（スループット）パフォーマンスも向上させます。

// ファクトリメソッドの導入例
// 従来: 直接構築 -> optCreateAssertion() で処理
// 新規: AssertionDsc::CreateBinaryOp(...) で生成
// const参照化: AssertionDsc* param -> const AssertionDsc& param

変更内容

  • assertionprop.cpp (+472/-643)：アサーション作成ロジックをファクトリメソッドに統合、AssertionDsc* を const AssertionDsc& に変換
  • compiler.h (+282/-61)：ファクトリメソッド群（Create*）を追加、関数を const 修飾化
  • compiler.hpp (+14/-88)：不要な関数削除、const 化対応
  • morph.cpp (+13/-17)：アサーション生成呼び出し先の更新
  • rangecheck.cpp (+22/-22)：参照型への変更対応

パフォーマンスへの影響

改善あり：スループット（TP）性能が向上（具体的な改善率は未記載）。メモリセーフ化による予期しない変更の防止で、コンパイラの安定性が向上。ポインタから参照への変換でメモリアクセスパターンが最適化される可能性。

関連Issue

なし

その他

  • ゼロ差分確認：実行ファイル差分なしで動作保証済み（Azure Pipeline ビルド検証済み）
  • 将来の改善案：①op1/op2 フィールドをゲッターで保護し追加の debug assert を実装、②AssertionDsc::Equals で memcmp 導入検討
  • 不要関数削除：使用されない関数を複数削除
  • Debug Assert 拡充：仮定検証用の debug assert を多数追加して信頼性向上

#123832 Replace some uses of MethodDescCallSite with UnmanagedCallersOnly methods

  • 作成者: @AaronRobinsonMSFT
  • 作成日時: 2026年01月31日 04:36:55(UTC)
  • マージ日時: 2026年02月02日 16:08:38(UTC)
  • ラベル: NO-MERGE area-VM-coreclr

概要

このPRは、MethodDescCallSite機構を使用した呼び出しを、UnmanagedCallersOnly属性が指定されたメソッドへの直接ポインタ呼び出しに置き換えるリファクタリングです。逆P/Invoke呼び出しを簡潔に実装し、ランタイムのアンマネージド間境界処理を最適化します。

// UnmanagedCallersOnly を使用した呼び出しの例
[UnmanagedCallersOnly]
public static void MyNativeCallback() { }
// 従来の MethodDescCallSite 経由ではなく、
// 関数ポインタで直接呼び出し可能に

変更内容

  • callhelpers.h: UnmanagedCallersOnly メソッド向けの呼び出しヘルパーマクロを新規追加（80行）
  • method.cpp/method.hpp: メソッド定義に UnmanagedCallersOnly 対応機構を追加（+32行）
  • dispparammarshaler.cpp: パラメータマーシャリング処理を MethodDescCallSite から直接ポインタ呼び出しに変更
  • StubHelpers.cs: マネージド側のスタブヘルパーを更新（+54行）
  • corelib.h: シグネチャ定義を拡張（+5行）
  • AppContext.cs、QCallHandles.cs: QCall対応コードを調整
  • corhost.cpp、precode_portable.cpp: 関連する呼び出し機構を簡略化

パフォーマンスへの影響

改善: MethodDescCallSiteの機構を迂回し、関数ポインタ呼び出しに統一することで、アンマネージド境界におけるオーバーヘッドが削減されます。特に頻繁に呼ばれるランタイムヘルパー（StubHelpers、RuntimeHandles周辺）での呼び出しコストが低減される見込みです。ただし、具体的なベンチマーク結果は提供されていません。

関連Issue

なし

その他

  • 16ファイルの変更で、ランタイムとマネージドライブラリの両側を調整
  • C++/CLIのアンマネージド間境界処理の標準化に向けた段階的なリファクタリングの一環と推定
  • 複数レビュアー（特にjkotas）による詳細なレビューが実施されており、広範囲な影響評価がなされている

#123826 Add null check for ThreadLocalStoragePointer in COMUnhandledExceptionFilter to prevent crash on Windows

  • 作成者: @Copilot
  • 作成日時: 2026年01月31日 00:19:58(UTC)
  • マージ日時: 2026年02月02日 15:37:21(UTC)
  • ラベル: area-ExceptionHandling-coreclr

概要

Windows環境において、スレッド初期化の非常に早い段階で未処理例外が発生した場合にCOMUnhandledExceptionFilter内でTLS（スレッドローカルストレージ）ポインタがまだ初期化されていないことに起因するクラッシュを防ぐため、Null チェックを追加しました。他のグローバル例外ハンドラーに同様のチェックが既に存在します。

変更内容

  • src/coreclr/vm/excep.cpp: COMUnhandledExceptionFilter関数の開始時に、Windows限定でNtCurrentTeb()->ThreadLocalStoragePointerがNULLであるかのチェックを追加（+8行）。TLSがまだ初期化されていない場合、早期にリターンしてCLRのTLS依存状態への不正アクセスを防止。

パフォーマンスへの影響

影響なし。Null チェックは追加されますが、正常系ではこの条件は満たされず、チェック自体のオーバーヘッドは無視できます。

関連Issue

#115476

その他

  • スレッド初期化の早期段階での未処理例外という非常にエッジケースな状況を対象とした防御的修正
  • Windows限定の変更で、他のプラットフォーム（Linux/macOS）への影響はなし

#123818 Fix HFA tests with interpreter

  • 作成者: @janvorli
  • 作成日時: 2026年01月30日 22:24:35(UTC)
  • マージ日時: 2026年02月02日 22:26:57(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

ARM64プラットフォームでHFA（Homogeneous Floating-Point Aggregate）引数がスタック上で渡される場合、インタープリタのスタックスロットサイズに整列していないときにテストが失敗していた問題を修正しました。コールスタブジェネレーターが隣接する2つのスタック範囲をマージする際に、前の引数がインタープリタスタックスロットの途中で終了することを考慮していなかったのが原因です。

// スタック範囲をマージする前にインタープリタスロットサイズでの整列チェックを追加
// 例: HFA引数がスタックスロット境界を跨ぐ場合の不正なマージを防止

変更内容

  • src/coreclr/vm/callstubgenerator.cpp: スタック引数のコピー範囲をマージする処理に、インタープリタスロットサイズ（通常8バイト）での整列ガード条件を追加。隣接するスタック範囲が安全にマージできるか確認してからマージするように修正。

パフォーマンスへの影響

影響なし。テスト失敗の修正であり、実行時パフォーマンスへの影響はありません。ただし、ARM64でのHFA引数の正確なスタック配置により、呼び出し慣例の準拠性が向上します。

関連Issue

Issue情報は提供されていません。

その他

  • ARM64のHFA引数伝達メカニズムに関連する低レベルな修正
  • インタープリタと通常の呼び出し間でのメモリレイアウトの一貫性を改善

#123817 Fix reachable Debug.Assert in InterleavedZipPackagePartStream.Length

  • 作成者: @Copilot
  • 作成日時: 2026年01月30日 21:45:20(UTC)
  • マージ日時: 2026年02月02日 14:47:52(UTC)
  • ラベル: area-System.IO.Compression

概要

System.IO.PackagingのInterleavedZipPackagePartStream.Lengthプロパティに不正なDebug.Assert(CanSeek)が存在し、デバッグビルドでCanSeekがfalseの場合に失敗していた問題を修正。基盤となるZipArchiveEntry.Lengthはシークを必要としないため、このアサーションは不要でした。

// 修正内容: Debug.Assert(CanSeek) を削除
// 修正前は、CanSeekがfalseの場合にDebug.Assertが失敗していた
// 修正後は、シーク不可のストリームでもLengthプロパティが正しく動作
using (Stream stream = partEntry.GetStream(FileMode.Open))
{
    long length = stream.Length; // CanSeekがfalseでも動作
}

変更内容

  • InterleavedZipPackagePartStream.cs: Lengthプロパティゲッターから不正なDebug.Assert(CanSeek)を削除（1行削除）
  • PartPieceTests.cs: InterleavedZipPackagePartStream_Length_ReturnsCorrectValueWhenCanSeekIsFalseテストを追加。読み取り専用で開かれたパッケージパートストリームのLengthが正しい値を返すことを検証（16行追加）

パフォーマンスへの影響

影響なし

関連Issue

#123816

その他

  • このバグは公開APIから到達可能なDebug.Assertであり、デバッグビルドのみで発生
  • リリースビルドではZipWrappingStream.LengthがZipArchiveEntry.Lengthから直接値を取得するため、問題は顕在化していなかった
  • 修正により、シークできないストリーム（読み取り専用アクセス）でもLengthプロパティが確実に機能するようになった

#123811 ignore async thunks when iterating the async continuation chain

  • 作成者: @max-charlamb
  • 作成日時: 2026年01月30日 19:38:46(UTC)
  • マージ日時: 2026年02月02日 17:10:22(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

このPRは、非同期スタックウォーキング機能を強化し、デバッグ情報を持たないAsync v2 → Async v1 thunk メソッド等の診断非表示メソッドをスキップするようにしました。これにより、スタック反復時の例外発生を回避し、デバッガに不要なフレームが露出しないようになります。

変更内容

  • dacdbiimpl.cpp/h: IsILStubOrLCGMethod を IsDiagnosticsHiddenOrLCGMethod にリネーム。診断非表示メソッドの検出ロジックを正確に反映
  • rsstackwalk.cpp: CordbAsyncStackWalk::PopulateFrame に診断非表示フレームをスキップするループを追加。Async v2 → v1 thunk の処理を改善
  • rsthread.cpp: 新しいメソッド名と列挙値を参照する全コールサイトを更新
  • dacdbiinterface.h: 列挙値 kILStub を kDiagnosticHidden にリネーム。インターフェースメソッドと関連コメント更新
  • ホワイトスペース修正: 複数ファイルの末尾の余分なホワイトスペース削除

パフォーマンスへの影響

診断非表示メソッドを明示的にスキップすることで、不要なフレーム処理が削減されます。ただし既提供情報ではベンチマーク数値の記載がないため、具体的なパフォーマンス改善率は不明。スタックウォーク反復の早期終了により、デバッグセッション時に微小な効率化が期待できます。

関連Issue

#123811

その他

  • この変更は破壊的変更ではなく、デバッガの内部実装（DAC/デバッグインターフェース層）に限定されます
  • 非同期デバッグのユーザビリティ向上により、スタックトレースの可読性が改善されます

#123795 Add JIT regression test extraction skill

  • 作成者: @Copilot
  • 作成日時: 2026年01月30日 12:04:09(UTC)
  • マージ日時: 2026年02月02日 13:23:01(UTC)
  • ラベル: 指定なし

概要

dotnet/runtimeリポジトリにJIT回帰テスト抽出用のCopilotスキルを追加するPRです。このスキルは、GitHubのIssueから単独のJIT回帰テストケースを抽出して、src/tests/JIT/Regression/JitBlue/Runtime_<issue_number>/ディレクトリに保存するプロセスを自動化します。ステップバイステップのガイダンスと実際のテスト例（Runtime_99391、Runtime_97625、Runtime_95315など）に基づいたコード規約を提供します。

変更内容

  • .github/skills/jit-regression-test/SKILL.md (+118行)
    • JIT回帰テスト抽出の段階的プロセス説明
    • ライセンスヘッダー、ファイルスコープ名前空間、[Fact]属性などのコード規約
    • .csprojファイル作成の条件（環境変数、unsafe修飾子、特殊設定）
    • CLRTestEnvironmentVariableパターンの説明（DOTNET_TieredCompilation、DOTNET_TieredPGOなど）
    • 既存のテスト例に基づいた実装ガイダンス

パフォーマンスへの影響

影響なし

このPRは開発支援ドキュメントとCopilotスキルの追加であり、ランタイムやコンパイラのパフォーマンスに直接的な影響はありません。

関連Issue

Skill作成の詳細は GitHub公式ドキュメント（https://docs.github.com/en/copilot/concepts/agents/about-agent-skills#creating-and-adding-skills）に従っています。

その他

  • 既存のperformance-benchmarkスキルと同じフォーマットに従い、リポジトリの一貫性を保持
  • Copilot coding agentの最適化推奨：リポジトリへのセットアップ手順を実施することで、今後のエージェント作業の品質と速度が向上

#123787 Fixed LoggerMessageGenerator message escaping.

  • 作成者: @John-Leitch
  • 作成日時: 2026年01月30日 05:08:18(UTC)
  • マージ日時: 2026年02月02日 00:57:07(UTC)
  • ラベル: area-Extensions-Logging community-contribution

概要

LoggerMessageGeneratorが生成するC#ソースコード内のメッセージ文字列をエスケープする処理を修正しました。バックスラッシュと0x20未満の全制御文字をエスケープして、生成される文字列リテラルが正当なC#コードになるようになりました。\rと\nは名前付きエスケープシーケンスとして、その他の制御文字は\xNN形式の16進エスケープシーケンスとして出力されます。

変更内容

  • LoggerMessageGenerator.Emitter.cs: メッセージエスケープ処理を改善。バックスラッシュ(\)と全制御文字(< 0x20)をエスケープするロジックを追加。コード行数は大幅に削減(-52行)
  • LoggerMessageGeneratorEmitterTests.cs: 新たな理論テスト(Theory Test)を追加し、バックスラッシュ、クォート、CR/LF、16進エスケープなどのシナリオをカバー
  • 複数の基準テストファイル(.generated.txt): エスケープ処理修正による出力の更新

パフォーマンスへの影響

影響なし。このPRはコード生成時のメッセージ文字列処理の正確性向上を目的としており、ランタイムパフォーマンスには影響しません。

関連Issue

#123786（LoggerMessageGeneratorが不正なC#文字列リテラルを生成していた問題）

その他

  • 破壊的変更なし。これはバグ修正であり、生成されるコードが正当なC#構文になることで後方互換性を向上させます
  • 複数の基準テストファイルの軽微な更新は、新しいエスケープロジックによる出力の正規化を反映しています

#123777 Fix XUnitWrapperGenerator handling of SkipOnCoreClrAttribute with no runtime test modes

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年01月29日 21:58:31(UTC)
  • マージ日時: 2026年02月02日 19:42:32(UTC)
  • ラベル: area-Infrastructure

概要

XUnitWrapperGeneratorでSkipOnCoreClrAttributeを使用する際に、すべてのRuntimeTestModesがスキップされる場合のテスト処理を修正しました。対象となるすべてのランタイムテストモードが除外されている場合、テスト実行をスキップするロジックが追加されています。

変更内容

  • ITestInfo.cs (+16/-1)

    • テスト情報インターフェースに、RuntimeTestModeがすべてスキップされているかを判定する機能を追加

  • XUnitWrapperGenerator.cs (+32/-33)

    • RuntimeTestModesのスキップ判定ロジックを修正
    • すべてのテストモードがスキップされた場合の処理を改善
    • コード行数の最適化（33行削除、32行追加）

パフォーマンスへの影響

影響なし

関連Issue

Issue #105964

その他

  • XUnitWrapperGeneratorはテストフレームワークの生成ツール用の修正であり、本体ランタイムの実行パフォーマンスには直接影響しません
  • テスト環境での属性ハンドリングの正確性向上に寄与します

#123768 [release/8.0-staging] Bump iOS & tvOS queues

  • 作成者: @steveisok
  • 作成日時: 2026年01月29日 18:25:45(UTC)
  • マージ日時: 2026年02月02日 13:59:27(UTC)
  • ラベル: Servicing-approved needs-area-label

概要

macOS 13のキューが廃止されたため、iOS及びtvOSのデバイステスト用Helixキュー設定をmacOS 13からmacOS 15に更新するインフラストラクチャ変更です。これはCI/CDパイプラインの定義ファイルの更新であり、機能コードの変更はありません。

変更内容

  • eng/pipelines/libraries/helix-queues-setup.yml: iOS/tvOSキュー設定を更新

    • OSX.13.Amd64.Iphone.Open → OSX.15.Amd64.Iphone.Open
    • OSX.13.Amd64.AppleTV.Open → OSX.15.Amd64.AppleTV.Open

  • eng/pipelines/coreclr/templates/helix-queues-setup.yml: CoreCLRテスト用キュー設定を更新

    • 同様にmacOS 13からmacOS 15へのキュー名変更

パフォーマンスへの影響

影響なし。このPRはCI/CDインフラストラクチャの更新であり、ランタイムやコンパイル出力には直接的なパフォーマンス影響はありません。ただし、macOS 15環境でのテスト実行が可能になることで、プラットフォーム互換性の検証が継続されます。

関連Issue

なし

その他

このPRはリリース/8.0-stagingブランチを対象としており、レガシー環境の廃止に伴う必須更新です。macOS 13キューの廃止により、このパイプライン更新がなければiOS/tvOSデバイステストが実行できなくなる状況での重要な変更となります。

#123766 [release/9.0] Bump macos helix queues

  • 作成者: @steveisok
  • 作成日時: 2026年01月29日 18:20:04(UTC)
  • マージ日時: 2026年02月02日 00:02:05(UTC)
  • ラベル: Servicing-approved needs-area-label

概要

macOS Helix キューの参照を OSX.13 から OSX.15 に更新するメンテナンスPRです。OSX.13 キューは廃止され、既に存在しなくなったため、CI/CD パイプラインとビルドスクリプト内の古いキュー参照をすべて OSX.15 に置き換えています。

変更内容

  • eng/pipelines/coreclr/templates/helix-queues-setup.yml: CoreCLR パイプラインテンプレートの OSX.13 キュー参照を OSX.15 に更新（ARM64、Amd64、デバイスキュー対応）
  • eng/pipelines/libraries/helix-queues-setup.yml: ライブラリパイプラインの macOS、iOS、tvOS プラットフォーム向けキュー設定を OSX.15 に更新
  • src/coreclr/scripts/superpmi_collect_setup.py: SuperPMI 収集スクリプトの ARM64、Amd64 アーキテクチャ用キュー参照を OSX.15 に更新

パフォーマンスへの影響

影響なし。このPRは CI/CD インフラストラクチャの設定変更のみであり、ランタイムやコンパイラのコード変更は含まれません。

関連Issue

なし

その他

このPRは release/9.0 ブランチを対象としています。OSX.13 キューの廃止に伴う必須の更新であり、パイプライン実行の継続性を確保するための重要なメンテナンス作業です。公開・内部の両キュー設定が更新されています。

#123762 [release/10.0] __ComObject doesn't support dynamic interface map (redux)

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年01月29日 17:45:42(UTC)
  • マージ日時: 2026年02月02日 00:49:26(UTC)
  • ラベル: Servicing-approved area-Interop-coreclr

概要

.NET 10のリリースブランチに対するバックポート修正です。PR #112375で導入された不十分な検証が原因で、COM相互運用オブジェクトの動的インターフェースマップに関する回帰が発生していました。本修正は、__ComObjectがマネージドインターフェースへのキャストに失敗する問題を解決し、欠落していたテストケースを追加します。

変更内容

ファイル 主な変更内容
src/coreclr/vm/methodtable.h 動的インターフェースマップの処理ロジック修正（9行追加/6行削除）
テストファイル群 COM相互運用のテストケース追加・修正（複数ファイルでテスト検証強化）

技術的影響：

  • COM相互運用の内部実装修正（__ComObjectの動的インターフェースマップ機構）
  • 公開APIへの破壊的変更なし（内部実装のみ）
  • 回帰修正により、異なる方法でランタイムに入るCOMオブジェクトから、マネージドインターフェース（COM/非COM混在）への正常なキャストが復旧

パフォーマンスへの影響

影響なし

関連Issue

  • 修正対象：Issue #112371
  • 元の原因：PR #105965（インターフェースマップの導入）
  • 不十分な検証の基因：PR #112375

その他

リスク評価： Low to Medium

  • 回帰による実装の不安定化ではなく、ニッチシナリオへの対応
  • PR #105965との比較で、より限定的で標的を絞った修正
  • オフラインで報告されたお客様問題を検証済み
  • 既存の回避策では影響が大きい重要シナリオに対応

#123656 Polyfill span.Contains(T)

  • 作成者: @MihaZupan
  • 作成日時: 2026年01月27日 03:02:51(UTC)
  • マージ日時: 2026年02月02日 02:35:23(UTC)
  • ラベル: area-Meta

概要

このPull Requestは、Span<T>.Contains(T) メソッドをポリフィル実装として追加するもので、古い.NETバージョンでの互換性を提供します。変更ファイルは75個にわたり、主にポリフィル実装の追加とプロジェクトファイルの構成管理が行われています。

// 新しいポリフィル実装の例
public static bool Contains<T>(this Span<T> span, T value) 
    where T : IEquatable<T>
{
    for (int i = 0; i < span.Length; i++)
    {
        if (span[i].Equals(value))
            return true;
    }
    return false;
}

変更内容

  • src/libraries/Common/src/System/MemoryExtensionsPolyfills.cs: Span<T>.Contains() ポリフィル実装を追加（+6行）
  • src/libraries/Common/src/System/StringPolyfills.cs: 文字列関連ポリフィル実装を追加（+22行）
  • 複数のプロジェクトファイル: ポリフィル参照の追加・削除による構成管理
    • Microsoft.Extensions.Configuration.CommandLine.csproj
    • System.Configuration.ConfigurationManager.Tests.csproj
  • 複数のソースファイル: Contains() の呼び出し箇所を更新（古い実装から新しいポリフィルへの移行）

パフォーマンスへの影響

影響なし。このポリフィルは古い.NETバージョン向けの互換性レイヤーであり、最新のランタイムでは最適化されたネイティブ実装が使用されるため、パフォーマンス低下はありません。

関連Issue

なし

その他

このPRは互換性向上を目的とした変更で、75ファイルもの修正が必要でした。プロジェクト間でのポリフィル参照の一貫性を保つため、プロジェクトファイルの整理が行われています。Copilotレビューではコメントが生成されず、変更内容が標準的であることを示唆しています。

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月27日 00:16:12(UTC)
  • マージ日時: 2026年02月02日 13:52:19(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPull Requestは、dotnet/dotnetリポジトリからのコードフロー更新です。release/10.0ブランチに対して、2026年1月27日付の複数のアセンブリ依存関係を更新しています。主な更新対象は、Roslyn（Microsoft.CodeAnalysis）、.NETビルドツール、およびWebAssembly Node.js実行時パッケージです。

変更内容

  • eng/Version.Details.xml: 依存関係の詳細定義を更新（85行の差分）
  • eng/Version.Details.props: バージョン情報を更新（37行の差分）
  • global.json: プロジェクト全体のグローバル設定を更新（3行の差分）
  • NuGet.config: NuGetパッケージ構成を更新（1行の差分）
  • eng/common/core-templates/job/source-build.yml: ソースビルドジョブテンプレートを更新（1行の差分）

更新されたパッケージ（主要なもの）:

  • Microsoft.CodeAnalysis関連: 5.0.0-2.26073.110 → 5.0.0-2.26077.101
  • Microsoft.DotNet.Arcade.Sdk他ビルドツール: 10.0.0-beta.26073.110 → 10.0.0-beta.26077.101
  • NuGet.Frameworks/Packaging/ProjectModel/Versioning: 7.0.2-rc.7410 → 7.0.2-rc.7801
  • WebAssembly Node.js実行時パッケージ: 10.0.0-alpha.1.26071.2 → 10.0.0-alpha.1.26076.1

パフォーマンスへの影響

影響なし。本更新は依存関係の定義ファイルと設定ファイルの変更であり、ランタイムパフォーマンスへの直接的な影響はありません。Roslynコンパイラの更新に伴うコンパイル時のパフォーマンス変化については、当該パッケージの詳細情報が必要です。

関連Issue

なし。本PR自体がコードフロー自動更新です。

その他

  • 本PRは自動生成されたコードフロー更新（dotnet-maestro[bot]による作成）
  • 7つのソースリポジトリからの変更を統合（arcade、aspnetcore、efcore、runtime、sdk、source-build-reference-packages、winforms）
  • WebAssemblyおよびマルチプラットフォーム対応（Linux/macOS/Windows、arm64/x64）の実行時パッケージが更新されています

#123629 [browser][coreCLR] finalizer on a browser event loop

  • 作成者: @pavelsavara
  • 作成日時: 2026年01月26日 16:08:19(UTC)
  • マージ日時: 2026年02月02日 19:53:07(UTC)
  • ラベル: arch-wasm area-GC-coreclr os-browser

概要

Webアセンブリ（WebAssembly）ブラウザ環境でのファイナライザー実行を改善するPRです。ブラウザのイベントループ上で安全にファイナライザーを実行できるようにスケジューリング機構を再構築しました。ファイナライザースレッドの動作をブラウザのシングルスレッド環境に適応させています。

変更内容

  • finalizerthread.cpp/h: ファイナライザースレッドの実装を158行追加・84行削除。ブラウザ環境用の新しいスケジューリング機構を実装
  • scheduling.ts: ブラウザのイベントループ統合を強化（30行追加・4行削除）。ファイナライザー処理のスケジューリングを改善
  • host.ts: ホスト環境の初期化・管理ロジックを拡張（12行追加・2行削除）
  • テストファイル複数: ブラウザ環境での実行コンテキスト、スレッドローカル、HTTPレスポンスストリームのテストにスキップ条件を追加
  • ceemain.cpp: 3行削除（初期化ロジック統合と思われる）

パフォーマンスへの影響

ブラウザ環境でのメモリリーク削減が期待されます。従来はファイナライザーがブロック可能性があり、イベントループをハングさせるリスクがありましたが、改善後はノンブロッキング化により、UI応答性が向上します。具体的なベンチマーク数値は提供されていません。

関連Issue

#114096 に貢献するPR

その他

  • 広範なレビュー（複数のコアメンテナーによる承認）を経ており、技術的な妥当性が検証済み
  • WebAssembly/ブラウザ環境は.NETランタイムの特殊なプラットフォーム実装のため、通常のデスクトップ環境には影響なし
  • ファイナライザーの実行タイミングはブラウザのマイクロタスクキューと統合される設計と推測される

#123615 [release/10.0] Update dependencies from dnceng/internal/dotnet-optimization

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月26日 05:03:36(UTC)
  • マージ日時: 2026年02月02日 13:50:42(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet-optimization内部リポジトリから依存関係を更新するPull Requestです。MIBC（Managed IL Binary Code）ランタイムとPGO（Profile Guided Optimization）CoreCLRの最適化パッケージを複数のプラットフォーム向けに更新しています。バージョンは1.0.0-prerelease.25502.1から1.0.0-prerelease.26080.1に更新されています。

変更内容

  • eng/Version.Details.props: 6行追加、6行削除（計12行変更）
  • eng/Version.Details.xml: 12行追加、12行削除（計24行変更）

更新された依存パッケージ：

  • optimization.linux-arm64.MIBC.Runtime
  • optimization.linux-x64.MIBC.Runtime
  • optimization.windows_nt-arm64.MIBC.Runtime
  • optimization.windows_nt-x64.MIBC.Runtime
  • optimization.windows_nt-x86.MIBC.Runtime
  • optimization.PGO.CoreCLR

パフォーマンスへの影響

MIBC（Managed IL Binary Code）ランタイムとPGO（Profile Guided Optimization）CoreCLRの更新を含んでいるため、ランタイムのパフォーマンス改善が期待されます。複数プラットフォーム（Linux ARM64/x64、Windows NT ARM64/x64/x86）向けの最適化パッケージが更新されており、各プラットフォームのコード生成最適化が改善される可能性があります。具体的なベンチマーク数値は提供されていません。

関連Issue

なし

その他

このPull Requestはdotnet-maestro[bot]による自動依存関係更新です。更新対象となるパッケージはすべて内部の最適化リポジトリ（dotnet-optimization）からのものであり、2026年1月30日時点のビルド（20260130.1）に基づいています。

#123531 Add DecompressionMethods.Zstandard for HTTP automatic decompression

  • 作成者: @Copilot
  • 作成日時: 2026年01月23日 08:57:50(UTC)
  • マージ日時: 2026年02月02日 09:20:50(UTC)
  • ラベル: area-System.Net.Http

概要

HTTP自動レスポンス展開機能に Zstandard（zstd）圧縮サポートを追加します。DecompressionMethods 列挙型に Zstandard = 0x8 を追加し、HttpClientHandler および SocketsHttpHandler が zstd エンコードされたレスポンスを自動的に展開できるようになります。既存の Brotli サポートと同じパターンに従っています。

var handler = new HttpClientHandler
{
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Zstandard
};
using var client = new HttpClient(handler);
var response = await client.GetAsync("https://example.com");

変更内容

  • DecompressionMethods.cs: Zstandard = 0x8 を列挙型に追加
  • System.Net.Primitives.cs（ref）: パブリック API リファレンスを更新
  • DecompressionHandler.cs: "zstd" エンコーディング対応を実装、ZstandardStream を用いた展開処理を追加。Accept-Encoding ヘッダー構築を List<string?> から Span<string?> に最適化
  • SocketsHttpHandler.cs: SupportedDecompressionMethods に Zstandard を追加
  • System.Net.Http.csproj: System.IO.Compression.Zstandard への依存参照を追加
  • HttpClientHandlerTest.Decompression.cs: Zstandard の展開テスト、空ボディ、Accept-Encoding ヘッダー、品質重み付けをカバーするテストを追加

パフォーマンスへの影響

改善：Accept-Encoding ヘッダー構築が List<string?> から Span<string?> に変更され、ヒープアロケーションが削減されます。これにより HTTP リクエストヘッダー構築時のメモリ効率が向上します。

関連Issue

  • #112075（本PRで修正）
  • #59591（Zstandard ライブラリの同梱が前提条件）

その他

  • WinHttpHandler では Zstandard がサポートされません（Brotli と同じ扱い）
  • Accept-Encoding ヘッダーに "zstd" が含められます
  • System.IO.Compression.Zstandard は既に利用可能なため追加の外部依存はありません
  • API 設計は既定のパターン（Brotli など）に準拠し、ヘッダー値は "zstd" ですが API は Zstandard と命名されています

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月22日 02:02:54(UTC)
  • マージ日時: 2026年02月02日 13:55:22(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet/icu リポジトリからの依存関係を更新するプルリクエストです。Microsoft.NETCore.Runtime.ICU.Transport パッケージを 9.0.0-rtm.25627.1 から 9.0.0-rtm.26078.1 に更新しています。これは .NET 9.0 リリースブランチの定期的な依存関係更新です。

変更内容

  • eng/Version.Details.xml: ICU パッケージのバージョンメタデータを更新（2行追加、2行削除）
  • eng/Versions.props: バージョン定義ファイルを更新（1行追加、1行削除）
  • NuGet.config: NuGet 構成ファイルの調整（1行削除）

パフォーマンスへの影響

影響なし。このプルリクエストはビルド依存関係の更新であり、ランタイム実装の変更ではありません。

関連Issue

なし。これは Maestro の自動依存関係更新です。

その他

  • 自動更新: dotnet-maestro[bot] による自動生成されたプルリクエスト
  • ビルド情報: Azure DevOps ビルド 20260128.1 から生成
  • ブランチ: release/9.0-staging ブランチへのアップストリーム依存関係の同期
  • 対象コミット: 53915f585ca3dc5deff5c09c9492f7c5b7d925ca (2026年1月28日)

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月20日 16:38:13(UTC)
  • マージ日時: 2026年02月02日 23:26:07(UTC)
  • ラベル: area-codeflow

概要

これはVMR（Virtual Monorepo）からのコードフロー更新です。dotnet/runtimeリポジトリに対して、dotnet/dotnetのメインブランチから2026年1月19日時点のソースコード変更と依存関係の更新が反映されています。主にバージョン設定ファイル、ビルド設定、テンプレート関連ファイルが更新されています。

変更内容

  • バージョン管理ファイル: Directory.Build.props、eng/Version.Details.props、eng/Version.Details.xml、eng/Versions.props、global.jsonが更新
  • ビルドプロジェクト: crossgen-corelib.proj、crossgen2_publish.csproj、ILCompiler_publish.csprojのツールセット参照が更新
  • ネイティブビルド設定: Microsoft.NETCore.Native.Unix.targets、CMakeLists.txtが更新
  • テンプレートテスト: WasmTemplateTests.cs、LazyLibrary.csprojが更新
  • テストユーティリティ: Microsoft.NET.CrossGen.targets、XUnitLogChecker.csprojが更新

依存関係の更新

以下の主要コンポーネントが更新されました：

  • Roslyn/Analyzers: Microsoft.CodeAnalysis系パッケージ（5.4.0-2.26065.101 → 5.4.0-2.26069.103）
  • .NET SDK: Microsoft.DotNet.*系ツール（11.0.0-beta.26065.101 → 11.0.0-beta.26069.103）
  • NuGet: NuGet.Frameworks等（7.3.0-preview.1.6601 → 7.3.0-preview.1.7003）
  • System.Text.Json: 11.0.0-alpha.1.26065.101 → 11.0.0-preview.1.26069.103
  • Wasm Runtime: 複数プラットフォーム向けランタイム（linux-arm64、linux-x64、osx等）が更新

パフォーマンスへの影響

影響なし。これは自動化されたコードフロー更新であり、パフォーマンス関連の変更は含まれていません。

関連Issue

なし。このPRはダイレクトな問題対応ではなく、定期的なコードベース同期です。

その他

  • 関連リポジトリ更新: aspnetcore、efcore、razor、roslyn、sdk、sourcelink、templatingの各リポジトリからの変更も含まれています
  • 自動生成: このPRはdotnet-maestro[bot]による自動化されたコードフロー更新です
  • 検証方法: darc vmr diffコマンドで詳細な差分を確認可能です

#123342 ServiceProviderEngineScope should aggregate exceptions in Dispose rather than throwing on the first

  • 作成者: @rosebyte
  • 作成日時: 2026年01月19日 11:22:35(UTC)
  • マージ日時: 2026年02月02日 15:13:01(UTC)
  • ラベル: area-Extensions-DependencyInjection

概要

DI（依存性注入）スコープ破棄時の例外処理を改善するPRです。従来は最初の例外で即座に破棄が中断されていましたが、本変更によりスコープ内のすべての一次消費可能オブジェクトを破棄した後に、複数の例外がある場合は集約例外として伝播させるようになります。これは.NET設計ガイドラインに準拠し、リソースリークを防ぎます。

// 変更前：最初の例外で破棄が停止
try { disposable1.Dispose(); } catch { throw; } // 後続の破棄が実行されない
// disposable2, disposable3...は破棄されない

// 変更後：すべて破棄してから例外を集約
try { disposable1.Dispose(); } catch(e) { exceptions.Add(e); }
try { disposable2.Dispose(); } catch(e) { exceptions.Add(e); }
// 最終的にexceptionsが複数あればAggregateExceptionを伝播

変更内容

  • ServiceProviderEngineScope.cs（+92/-28）

    • Dispose/DisposeAsyncメソッドの例外処理ロジックを改善
    • 各disposableの破棄をtry/catchで個別に囲み、すべての破棄を完遂させる
    • 複数例外発生時はAggregateExceptionで集約して伝播

  • ServiceProviderEngineScopeTests.cs（+134/-2）

    • 複数例外発生時の集約動作を検証するテストを追加
    • 例外発生時もすべてのdisposableが破棄されることを確認

パフォーマンスへの影響

懸念点あり：try/catchブロックを各disposableごとに配置することで、複数disposables存在時にException Handling Table（EHT）への書き込みが増加し、CPU オーバーヘッドが増える可能性があります。特にASP.NETのようにリクエスト後にスコープを破棄する高スループット環境での影響が懸念されます。

ただし、DI スコープ破棄は一般的にホットパスではないため、実務的な影響は限定的と判断されています。

関連Issue

#86426

その他

  • 破壊的変更：例外伝播の動作が変更されるため、既存コードが特定の例外型に依存している場合は影響を受ける可能性があります。ただし作成者は、DI スコープ破棄の例外処理に依存するユースケースは稀と評価しています。
  • 実装最適化の提案：複数例外発生時のみリスト割り当てを行う最適化案も提示されており、必要に応じて実装可能です。

#123115 Fix vectorization of Ascii.Equals for lengths 8..15

  • 作成者: @pentp
  • 作成日時: 2026年01月13日 01:50:54(UTC)
  • マージ日時: 2026年02月02日 20:18:56(UTC)
  • ラベル: area-System.Runtime community-contribution

概要

Ascii.Equalsのベクトル化において、WideningLoaderを使用する場合の最小長チェックが誤っていた問題を修正しました。従来はVector128<TLeft>.Count（16）を使用していましたが、実際の最小値はVector128<TRight>.Count（8）であるため、長さ8～15のバイト列比較がベクトル化されず、スカラー処理へ不必要にフォールバックしていました。

// 修正前: byte(Count=16)を基準に、8-15の範囲で効率化できていない
if (length < Vector128<TLeft>.Count) { /* scalar path */ }

// 修正後: ushort(Count=8)を基準に、8-15の範囲も効率的にベクトル化
if (length < Vector128<TRight>.Count) { /* vectorized path */ }

変更内容

  • System.Private.CoreLib/System/Text/Ascii.Equality.cs
    • WideningLoaderの最小長チェックをVector128<TRight>.Countに修正
    • TLoader.Count128/256/512プロパティへの参照をすべてVector<TRight>.Countに置き換え
    • ILoaderインターフェースから未使用のCount128、Count256、Count512プロパティを削除
    • スペルミス修正：「loose」→「lose」

パフォーマンスへの影響

改善あり

  • 長さ8～15バイト/文字のASCII比較がスカラー処理からベクトル化処理へ移行
  • 該当範囲の処理性能が向上（具体的なベンチマーク値は記載なし）
  • 左右の検索空間が同じ量だけ進むことを保証し、ベクトル処理の正確性を向上

関連Issue

#123115

その他

  • 内部実装の修正であり、公開APIへの影響なし
  • 破壊的変更はなし

#123022 Arm64: Fix for 96441

  • 作成者: @dhartglassMSFT
  • 作成日時: 2026年01月09日 01:04:58(UTC)
  • マージ日時: 2026年02月02日 05:57:16(UTC)
  • ラベル: area-CodeGen-coreclr

概要

ARM64アーキテクチャにおいて、条件付きインクリメント命令（cinc/csinc）への変換が最適化されました。特に、ローカル変数と定数を比較するSELECTCCパターン（例：if (lzcnt==0) lzcnt=1;）が正しく条件付きインクリメント命令に変換されるようになりました。

public static int RuneLength(in byte value)
{
    var lzcnt = (uint)BitOperations.LeadingZeroCount(~((uint)value << 24));
    if (lzcnt is 0) lzcnt++;  // この条件付きインクリメントがcinc命令に最適化される
    return (int)lzcnt;
}

変更内容

  • src/coreclr/jit/lowerarmarch.cpp (+110/-37): TryLowerCnsIntCselToCincメソッドを拡張し、定数比較に基づくSELECTCCパターンを認識し、GT_SELECT_INCCCノードに変換。ローカル変数の読み取りを定数値+1の代わりに使用
  • src/coreclr/jit/lower.cpp (+1/-1): LowerSelectの呼び出し条件を緩和し、いずれかのセレクト操作数が整数定数の場合に条件付きインクリメント変換を試行

パフォーマンスへの影響

改善あり：ARM64の条件付きインクリメント命令（cinc）の使用範囲が拡大することで、より効率的な命令シーケンスが生成されます。比較と分岐の代わりに単一のcinc命令で処理可能になり、命令数削減とパイプラインの最適化につながります。

関連Issue

#96441

その他

この修正は、JITの初期フェーズが「add local, 1」を定数に折り畳んでしまう問題に対応しています。条件付きインクリメント変換の対象パターンを広げることで、より攻撃的なコード最適化が可能になりました。

#117571 JIT: Move remaining xarch floating->integral cast implementation to lowering

  • 作成者: @saucecontrol
  • 作成日時: 2025年07月12日 20:44:13(UTC)
  • マージ日時: 2026年02月02日 17:58:45(UTC)
  • ラベル: area-CodeGen-coreclr community-contribution

概要

このPRはxarch上での浮動小数点→整数キャスト処理をJITの低位化フェーズに完全に移行する変更です。従来はコード生成フェーズでgenFloatToIntCastにより処理されていた一部のキャストを、すべてHWIntrinsicノードに置き換えることで、コードサイズとスループットの改善を実現しています。

// 浮動小数点→整数キャスト処理が低位化フェーズで HWIntrinsics に置き換わります
// 例: (int)(float)value -> 対応するAVX10v2/AVX512命令に置き換え

変更内容

  • lowerxarch.cpp: LowerCast関数を拡張し、浮動→整数キャスト用のAVX10v2、AVX512対応パスとフォールバック実装を追加
  • hwintrinsiclistxarch.h: AVX10v2スカラー飽和変換組み込み関数を新規追加
  • hwintrinsiccodegenxarch.cpp: 新規AVX10v2飽和変換命令のコード生成サポート追加
  • codegenxarch.cpp: 不要になったgenFloatToIntCast関数（68行）を削除
  • instr.cpp: コード生成フェーズでの浮動→整数変換命令選択処理を削除
  • hwintrinsic.cpp: AVX10v2_X64 ISA範囲を64ビット組み込み関数に対応
  • gentree.cpp: 組み込み関数名を"Truncation"から"Truncated"に修正
  • lower.cpp: キャスト低位化後は早期リターン
  • codegenlinear.cpp: xarch向けのガード追加
  • CMakeLists.txt: i386 UnixビルドでSIMD機能を有効化

パフォーマンスへの影響

改善あり

  • コードサイズ削減：キャスト処理が常にHWIntrinsicsで置き換わるため、自己キャストの不完全な消去によるオーバーヘッドが解消
  • スループット向上：genFloatToIntCast関数が不要になり、コード生成パイプラインの処理が簡潔化
  • AVX10v2以降環境：専用の飽和変換命令により直接的なハードウェアサポート

関連Issue

なし

その他

  • ホワイトスペースを無視して表示することを推奨（lowerxarch.cppの大部分は既存コードのインデント調整）
  • 破壊的変更なし（xarch特有の最適化で外部APIに影響なし）
  • 複雑なSIMD操作によるフォールバック実装で、AVX10v2未満のハードウェアでも飽和セマンティクスを保証
目次