Pull Request on 2026年02月11日

注意点

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

---

---

#124288 Fix browser-wasm test restore NU1102 failures

• 作成者: @lewing
• 作成日時: 2026年02月11日 18:47:55(UTC)
• マージ日時: 2026年02月11日 20:04:15(UTC)
• ラベル: NO-MERGE area-skills

概要

browser-wasm テストの復元時に NU1102 エラー（パッケージが見つからない）が発生していた問題を修正しました。UseMonoRuntime が削除されたことで、SDK が存在しないランタイムパックをNuGetから取得しようとしていました。修正では、テスト依存プロジェクトの復元時に EnableRuntimePackDownload=false と EnableTargetingPackDownload=false を無条件に渡し、ローカルビルドから提供されるパックを使用するようにしました。

変更内容

• src/tests/build.proj: RestorePackage ターゲットの dotnet restore コマンドに RuntimeFlavor パラメータを追加。EnableRuntimePackDownload と EnableTargetingPackDownload フラグを無条件に -p: オプションで渡すように修正（変更: +2/-2）
• eng/targetingpacks.targets: CoreCLR ランタイムパック RID リストに browser-wasm を追加し、ローカルパック解決に対応
• その他: SDK/ツールチェーンバージョンの更新、CI テンプレートの更新、ネイティブ依存関係スクリプトの調整

パフォーマンスへの影響

影響なし。この変更は復元時の不要なNuGet パッケージダウンロード試行を排除し、ローカルパックの利用を確保するもので、パフォーマンスへの悪影響はありません。

関連Issue

#121789（UseMonoRuntime 削除）、#123181（perf パイプラインへの RuntimeFlavor 追加）、#124232（関連コードフロー）

その他

この修正は Mono と CoreCLR の両 browser-wasm 構成に対応しており、根本原因は SDK の UseMonoRuntime 削除に遡ります。テスト復元段階ではランタイムパック/ターゲティングパックが不要（ローカルビルドから提供される）という設計を明確化する修正です。

---

#124280 Fix missing early returns in TensorPrimitives.Round.cs

• 作成者: @Copilot
• 作成日時: 2026年02月11日 16:14:19(UTC)
• マージ日時: 2026年02月11日 22:05:14(UTC)
• ラベル: area-System.Numerics tenet-performance

概要

TensorPrimitives.Round<T>(ReadOnlySpan<T>, int, MidpointRounding, Span<T>) メソッドで digits == 0 の早期終了後に return ステートメントが欠落していたため、丸め処理が2回実行される制御フロー上のバグを修正しました。また、AwayFromZero switch ケースの break を return に変更し、他のケースとの一貫性を確保しました。

if (digits == 0)
{
    Round(x, mode, destination);
    return;  // 修正：returnを追加
}

変更内容

• ファイル: src/libraries/System.Numerics.Tensors/src/System/Numerics/Tensors/netcore/TensorPrimitives.Round.cs
  • digits == 0 条件での早期終了後に return ステートメントを追加
  • MidpointRounding.AwayFromZero switch ケースの break を return に変更（制御フロー一貫性の改善）

パフォーマンスへの影響

改善点: バグ修正による性能向上

• digits == 0 の場合、丸め処理の二重実行が排除され、不要な計算が削除されます
• メモリアクセスと計算量が約50%削減されます

関連Issue

なし

その他

• 変更は内部実装の制御フロー修正であり、公開API署名への影響なし
• 破壊的変更なし
• digits != 0 のケースに対する動作変更なし

---

#124277 Add guideline for preferring [Theory] over multiple [Fact]s

• 作成者: @Copilot
• 作成日時: 2026年02月11日 15:12:01(UTC)
• マージ日時: 2026年02月11日 15:41:09(UTC)
• ラベル: needs-area-label

概要

Copilot coding agentの指示を更新し、重複したテストメソッドよりもパラメータ化されたテストの使用を推奨するようにしました。xUnitの[Theory]属性と[InlineData]または[MemberData]を組み合わせて、複数の類似した[Fact]メソッドを1つの汎用テストメソッドに統合することを推奨しています。

変更内容

• ファイル: .github/copilot-instructions.md
  • テスト作成時のガイドラインを追加
  • 複数の重複した[Fact]メソッドではなく、[Theory]と複数のデータソース（[InlineData]または[MemberData]）の使用を推奨

パフォーマンスへの影響

影響なし

このガイドラインは開発プラクティスの改善を目的とした指示更新であり、パフォーマンスに直接的な影響はありません。ただし、テストコードの保守性向上により、テストスイートの拡張性が改善される可能性があります。

関連Issue

なし

その他

• この変更はCopilot coding agentの指示の改善を目的としています
• テストコードの重複削減とメンテナンス性向上が目標です
• xUnitのパラメータ化テスト機能を活用した開発実践の推奨です

---

#124275 Configure markdownlint to allow 2-space hard line breaks

• 作成者: @Copilot
• 作成日時: 2026年02月11日 14:22:14(UTC)
• マージ日時: 2026年02月11日 14:48:39(UTC)
• ラベル: needs-area-label

概要

Markdownのlintルール設定を改善し、System.Private.Uri/docs内のThreat modelファイルで使用されている標準的なMarkdown構文（2つのトレーリングスペースでのハードラインブレイク）を正式に認識するようにしました。ファイル全体を抑制するのではなく、ルール設定で適切に対応することで、lintの精度を向上させています。

変更内容

• .markdownlint.json: MD009ルール（ハードラインブレイク）の設定に br_spaces: 2 を追加し、2スペースのトレーリングスペースを有効な構文として認識
• ファイル抑制ルールの削除: .github/workflows/markdownlintignoreの廃止
• ワークフロー変更の復元: 削除されたignoreファイルを参照していたworkflow設定を巻き戻し

パフォーマンスへの影響

影響なし（ビルドやランタイムパフォーマンスには関連しない設定変更）

関連Issue

なし

その他

この変更はコード品質管理の改善です。従来の「ファイル全体をlint対象外にする」というアプローチから「ルール設定でセマンティックに対応する」へシフトしており、より粒度の細かいlint管理が実現できます。Threat modelドキュメントの可読性向上にも寄与します。

---

#124269 Fix ProcessRunner StringBuilder race condition causing assertion failure

• 作成者: @Copilot
• 作成日時: 2026年02月11日 13:11:20(UTC)
• マージ日時: 2026年02月11日 23:38:08(UTC)
• ラベル: needs-area-label

概要

ProcessRunnerの標準出力・標準エラー出力ハンドラが共有のStringBuilderに対して非同期に追記する際の同期化漏れにより、内部状態が破損しStringBuilder.ExpandByABlockのアサーション失敗minBlockCharCount > 0が発生していた問題を修正します。両イベントハンドラのAppendLine呼び出しを_outputCaptureオブジェクトでロックすることで競合を排除します。

変更内容

• ファイル: src/coreclr/tools/r2rtest/ProcessRunner.cs
  • StandardOutputEventHandler内の_outputCapture.AppendLine()呼び出しをlock(_outputCapture)で保護
  • StandardErrorEventHandler内の_outputCapture.AppendLine()呼び出しをlock(_outputCapture)で保護
  • プロセス終了後のIsAvailableでのToString()呼び出しはロック不要（プロセス終了後はイベント発火なし）

private void StandardOutputEventHandler(object sender, DataReceivedEventArgs eventArgs)
{
    string data = eventArgs?.Data;
    if (!string.IsNullOrEmpty(data))
    {
        WriteLog(data);
        lock (_outputCapture)
        {
            _outputCapture.AppendLine("  " + data);
        }
    }
}

パフォーマンスへの影響

ロック追加に伴う性能への影響：stdout/stderrの取得スループットに対する軽微なロックオーバーヘッド。ただし、AppendLineの実行時間は短く、かつこれは開発・テストツール（r2rtest）のプロセス実行用途であるため実務的な影響は限定的と考えられます。

関連Issue

• #124067: 元の報告Issue（PGOテストでのアサーション失敗）
• 再現環境: runtime-coreclr pgo、Linux ARM Checked、readytorun/coreroot_determinism テスト

その他

• Copilotによる自動作成のPR
• 競合状態に起因するメモリ破損の修正であり、セキュリティ/信頼性にかかわる重要な修正

---

#124254 Fix incorrect atomic loop optimization when body contains backtracking

• 作成者: @stephentoub
• 作成日時: 2026年02月11日 03:45:24(UTC)
• マージ日時: 2026年02月11日 18:22:14(UTC)
• ラベル: area-System.Text.RegularExpressions

概要

正規表現エンジンの最適化バグを修正しました。MakeLoopAtomicがループをAtomic groupで囲む際、ループ本体内のバックトラッキングを誤って抑制してしまい、不正なマッチ結果を生成していました。修正では、ループ本体にバックトラッキング構文がないことを事前確認してからAtomic化を実行するようにしました。

// 修正前：バックトラッキングを含む本体でも Atomic化されてしまう
// 修正後：MayContainBacktracking() で検査し、不正な最適化を防止
if (!CanBeMadeAtomic(loop) || MayContainBacktracking(loop.Child))
{
    // Atomic化しない
}

変更内容

• RegexNode.cs: IsBacktrackingConstruct プロパティを追加（変動幅ループや選択肢を検出）、MayContainBacktracking() メソッドでサブツリー走査を実装、MakeLoopAtomic() にバックトラッキング検査ゲートを追加
• RegexTreeAnalyzer.cs: 重複していた switch 文を削除し、RegexNode.IsBacktrackingConstruct を再利用するようリファクタリング
• Regex.Match.Tests.cs: 内部バックトラッキングが必要なネストループケースの回帰テストを追加

パフォーマンスへの影響

修正により MayContainBacktracking() がループ最適化時にサブツリーを走査するため、コンパイル時に軽微なオーバーヘッドが発生する可能性があります。ただし、この走査は最適化適用判定フェーズの事前チェックに留まり、実行時パフォーマンスへの影響はありません。むしろ誤った最適化による不正なマッチ結果を防ぐため、整合性向上が期待できます。

関連Issue

#124254

その他

この修正は破壊的変更ではなく、バグ修正です。誤動作していた正規表現が正しく動作するようになります。特定の条件（ネストループで内部バックトラッキングが必要）でのマッチ結果が修正前と異なる可能性があります。

---

#124253 JIT: fix liveness in throw helper blocks

• 作成者: @AndyAyersMS
• 作成日時: 2026年02月11日 01:14:50(UTC)
• マージ日時: 2026年02月11日 15:05:45(UTC)
• ラベル: area-CodeGen-coreclr

概要

PR #123781によるthrow helper blocks生成位置の変更に伴い、liveness情報の更新漏れが発生していました。本PR では、throw helper block生成時に明示的にliveness状態（bbLiveIn/bbLiveOut）を正しく設定するようにしました。これにより、遅延生成されたblockでもGC/livenessの正確性が保証されます。

変更内容

ファイル	変更内容
src/coreclr/jit/compiler.h	fgSetThrowHelpBlockLivenessメソッドを新規宣言
src/coreclr/jit/liveness.cpp	throw helper liveness fixupロジックを専用helper関数として抽出し、unreachableなblockの処理で再利用
src/coreclr/jit/flowgraph.cpp	fgCreateThrowHelperBlockでthrow helper block生成時にliveness fixupを即座に適用

パフォーマンスへの影響

影響なし。 本変更はliveness情報の正確性を確保するメンテナンス的な修正であり、パフォーマンス特性への変更はありません。

関連Issue

#123929（このPRで修正） #123781（根本原因となったPR）

その他

重要な技術的背景： throw helper blocksが下流フェーズで生成されるようになったため、従来の「unreachableなblock」に対するliveness fixupパスから漏れるようになりました。本修正により、JIT最適化段階でのGC参照追跡の正確性が維持され、ランタイム不安定性の原因となるliveness不正を防止します。

---

#124251 Fix MetadataLoadContext: Multiple Type[] methods return internal implementation types

• 作成者: @Copilot
• 作成日時: 2026年02月11日 00:19:35(UTC)
• マージ日時: 2026年02月11日 23:55:03(UTC)
• ラベル: area-System.Reflection

概要

MetadataLoadContextの複数のType[]返却メソッドが、内部実装型のRoType[]やRoModifiedType[]を返していた問題を修正しました。これによりAsSpan<Type>()などのモダンSpan APIを使用する際に発生していたArrayTypeMismatchExceptionが解決されます。

// 修正前：ArrayTypeMismatchException が発生
var type = mlc.LoadFromAssemblyPath(...).GetType("C`2");
var args = type.GetGenericArguments();
args.AsSpan();  // RoType[] cannot be used as Type[]

// 修正後：正常に動作
args.AsSpan();  // OK

変更内容

• RoType.cs: GetGenericArguments() - .CloneArray() → .CloneArray<Type>()でType[]を返すように修正
• RoModifiedFunctionPointerType.cs:
  • GetFunctionPointerParameterTypes() - .CloneArray<Type>()に修正
  • GetFunctionPointerCallingConventions() - .CloneArray<Type>()に修正
• RoModifiedType.cs:
  • GetRequiredCustomModifiers() - .CloneArray<Type>()に修正
  • GetOptionalCustomModifiers() - .CloneArray<Type>()に修正
• TypeInvariants.cs: 既存テスト基盤に配列型検証を統合。返却配列の実行時型がType[]であることを確認

パフォーマンスへの影響

影響なし。変更は配列のラッパー型のみで、要素内容や動作は変更されていません。既存コード内の5つ以上の他のメソッド（GenericTypeParameters、GenericTypeArguments、GetInterfaces()等）で既に使用されているパターンに従っています。

関連Issue

#124214

その他

• すべての686テストが合格
• System.Reflection名前空間のすべての公開API（Type[]返却）を体系的にレビュー完了
• リスク評価：最小限。型変換のみで、実際の要素内容や動作に変更なし

---

#124249 JIT: refactor GS enabling

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

概要

GS（Guard Stack）機能のJIT実装をリファクタリングしました。EnC（Edit and Continue）とWasm環境ではGSが未サポートのため、GSの有効化メカニズムを柔軟にして、オプトアウト理由を記録できるようにしました。また、importer内でlocalloc後のGS要求時にスタック再配置を要求していなかった問題も修正しています。

変更内容

• compiler.h: GS有効化制御を拡張（+28行追加）。オプトアウト理由を記録するメカニズムを追加
• fginline.cpp: 関数インライン化時のGS処理を調整（+10/-6）
• gschecks.cpp: GS検査フェーズの実装を修正。オプトアウト理由の記録と出力を追加（+10/-1）
• importer.cpp: localloc後のGS要求でスタック再配置を同時に要求するよう修正（+3/-8）
• lclvars.cpp: ローカル変数処理でのGS関連ロジックを調整（+9/-8）

パフォーマンスへの影響

影響なし。本変更はGS有効化ロジックのリファクタリングであり、実行時パフォーマンスの変化はありません。ただしlocalloc後のスタック再配置要求の追加は、コンパイラの検証ロジック精度を向上させます。

関連Issue

#124249

その他

• EnCおよびWasm環境でのGS未サポートを明確化しているため、将来的な実装検討時に参考になります
• importerでの修正は「oversight」（見落とし）であったため、この修正により堅牢性が向上しています

---

#124242 Remove bounds checks for 'i + cns < len' pattern

• 作成者: @EgorBo
• 作成日時: 2026年02月10日 20:36:32(UTC)
• マージ日時: 2026年02月11日 16:18:03(UTC)
• ラベル: area-CodeGen-coreclr

概要

JIT コンパイラの範囲チェック最適化を改善し、i + cns < len パターンの冗長な境界チェックを削除します。条件式で事前に上限チェックが行われている場合、その後のアクセスに対する重複チェックを除去することでコード生成を効率化します。

// 例: i + 2 < span.Length の条件下では
// span[i + 1] と span[i + 2] のアクセスは追加チェック不要
if ((uint)(i + 2) < (uint)span.Length)
{
    _ = span[i + 1];  // チェック削除対象
    _ = span[i + 2];  // チェック削除対象
}

変更内容

• src/coreclr/jit/rangecheck.cpp (+116/-76): 範囲チェック最適化ロジックの拡張。i + constant < length パターンを認識し、その条件下で安全なアクセスの境界チェックを除去する機能を実装
• src/coreclr/jit/rangecheck.h (+2/-0): 範囲チェック関連の新規メソッド/フィールド定義
• src/tests/JIT/opt/RangeChecks/ElidedBoundsChecks.cs (+27/-0): 新規テストケース追加

パフォーマンスへの影響

改善あり: コード生成サイズ削減。提供されたアセンブリ例では、冗長な cmp 命令が削除され、より効率的なコード（63バイト）が生成されます。メモリアクセスの削減に伴いL1キャッシュ効率が向上し、特にループ処理で効果的です。

関連Issue

#121262

その他

• JIT の静的解析フェーズで実施される最適化（破壊的変更なし、API変更なし）
• 既存コードの動作は変わらず、コード生成の効率化のみ
• ランタイムの互換性影響なし

---

#124241 [release/10.0] Fix removing module from appdomain in DB_IPCE_UNLOAD_MODULE event

• 作成者: @github-actions[bot]
• 作成日時: 2026年02月10日 19:34:21(UTC)
• マージ日時: 2026年02月11日 20:45:22(UTC)
• ラベル: Servicing-approved area-Diagnostics-coreclr

概要

.NET 10でアセンブリを複数回アンロードする際にデバッガがクラッシュする問題を修正しました。Visual Studioでコレクション可能なアセンブリをデバッグ中にHRESULT=0x80131c36エラーで強制終了する致命的なバグを解決します。デバッガモジュールキャッシュのルックアップキーをアセンブリから正しくモジュールに変更しました。

変更内容

• src/coreclr/debug/di/module.cpp (+2/-2): DB_IPCE_UNLOAD_MODULE イベントハンドラでモジュール削除時のキャッシュルックアップをアセンブリキーからモジュールキーに修正
• src/coreclr/debug/di/process.cpp (+1/-1): デバッガプロセスモジュール管理でのキャッシュ操作を修正

パフォーマンスへの影響

影響なし。本修正は正確なキャッシュルックアップ機構の復元であり、パフォーマンス特性に変更はありません。

関連Issue

• #123930（お客様報告）
• #123931（元のPR）
• #117224（.NET 10で導入された回帰の原因）
• #118414（関連する修正試行）

その他

• 重要度: 低リスク修正。デバッガモジュールキャッシュはモジュールをハッシュキーとして使用するため、正確なキー参照の修正は安定性を向上させます
• 回帰: .NET 9から .NET 10への回帰であり、#118414での修正漏れが原因
• 検証: 顧客の再現可能なテストケース (#123930) で検証済み
• ブランチ: release/10.0へのバックポート版

---

#124239 Add references for getAsyncInfo

• 作成者: @jtschuster
• 作成日時: 2026年02月10日 19:29:11(UTC)
• マージ日時: 2026年02月11日 23:33:46(UTC)
• ラベル: area-crossgen2-coreclr runtime-async

概要

この変更は、Ready-to-Run (R2R) コンパイラにおいて CorInfoImpl.getAsyncInfo メソッドで必要とされる参照をモジュールに追加するための機能拡張です。Continuation フィールドアクセス用の GetHandleForField メソッドを追加し、非同期情報取得に必要なすべての参照を管理するための AddNecessaryAsyncReferences メソッドを実装しています。

変更内容

ModuleTokenResolver.cs (+32行)

• GetHandleForField メソッドを新規追加
• Continuation フィールドアクセス時のハンドル取得機能を実装

ReadyToRunCodegenCompilation.cs (+122行, -49行)

• AddNecessaryAsyncReferences メソッドを新規作成し、getAsyncInfo で必要な参照をミュータブルモジュールに追加
• typedef トークン存在確認コードを EnsureInstantiationReferencesArePresentForExternalMethod に移行
• 非バージョンバブル外のインスタンス化メソッドに対する型定義参照の処理を整理

パフォーマンスへの影響

影響なし。本変更は非同期メタデータの参照管理をより厳密にするための構造的改善であり、実行時パフォーマンスへの直接的な影響はありません。

関連Issue

なし

その他

• 変更は AOT (Ahead-of-Time) コンパイラの内部実装に限定
• メタデータ参照の管理をより体系的に整理することで、非同期情報処理の堅牢性を向上
• 破壊的変更なし

---

#124231 Improve vmr-codeflow-status skill: current-state-first analysis, force push & empty diff detection

• 作成者: @lewing
• 作成日時: 2026年02月10日 17:10:52(UTC)
• マージ日時: 2026年02月11日 16:18:48(UTC)
• ラベル: area-skills

概要

このPRは、VMR（Virtual Mono Repository）コードフロー状態分析ツール（Copilot CLI skill）を改善するもので、**「現在の状態優先、コメントは履歴」**という設計パターンを採用しています。Maestroコメントを読む前に、PR状態、diff サイズ、force push、タイムラインなどの一次信号から独立した判定を形成し、その後コメントを履歴として参照することで、陳腐化したコメントに基づく誤った判断を防ぎます。

// 従来の方法：Maestroコメント → 結論
// 新しい方法：PR状態・force push・diff → 独立判定 → コメント（履歴参照）

変更内容

• Get-CodeflowStatus.ps1 (+245/-139)：

  • 現在の状態評価ロジック追加（MERGED / CLOSED / NO-OP / IN PROGRESS / STALE / ACTIVE）
  • head_ref_force_pushedイベントの検出機能（--slurpパラメータで正確なページネーション対応）
  • Empty diff検出（changedFiles/additions/deletions の確認）
  • Force pushタイムスタンプと警告の比較による、解決状況の後付け検証
  • 硬直した130行以上の推奨判定ロジックをJSON出力に置き換え

• SKILL.md (+93/-9)：

  • 「Staleness & Conflict Check」を「Codeflow History」に改称
  • Maestro警告は履歴表示であることを明示
  • エージェント向けガイダンス追加：JSON要約から推奨事項を生成する方法を説明

パフォーマンスへの影響

影響なし。追加のgh prクエリ（commits、timeline）が導入されていますが、キャッシュ不可の API呼び出しであり、既存の Maestro comment 読み込みと並行処理されることで、全体の実行時間への大きな増加は見込まれません。ただしレート制限に近い環境では考慮が必要です。

関連Issue

#124095（陳腐化したコードフロー PR、conflict + force push 検証対象）、#124229（code-review skill 再構築の参考設計パターン）

その他

• Copilot レビューにより、gh pr checks失敗時に staleness フラグが誤ったまま残る潜在的なバグが指摘されています。commit日付比較をチェック取得から独立させ、try/catch でガード化することで改善可能です
• マルチモデルテスト（Claude Sonnet 4、GPT-5）で機能検証済み、isUpToDate null 処理、daysSinceUpdate 負値、isCodeflowPR フィールド追加など反復改善已了

---

#124230 Update docs for running CoreCLR on Apple mobile

• 作成者: @kotlarmilos
• 作成日時: 2026年02月10日 16:12:28(UTC)
• マージ日時: 2026年02月11日 09:54:31(UTC)
• ラベル: documentation os-ios needs-area-label

概要

CoreCLRをApple モバイルデバイス（iOS）で実行するための公式ドキュメントを更新するPRです。主にiOS向けのビルドおよび実行手順に関するドキュメントを改善し、より正確で実用的な情報を提供することを目的としています。

変更内容

• docs/workflow/building/coreclr/android.md: 2行追加、2行削除（総37行中4行変更）
• docs/workflow/building/coreclr/ios.md: 19行追加、18行削除（総37行中37行変更）

主な変更は、iOSおよびApple モバイルプラットフォーム向けのビルドおよび実行ドキュメントの内容更新です。

パフォーマンスへの影響

影響なし

（本PRはドキュメント更新のみのため、ランタイム、コンパイラ、またはライブラリのコード変更は含まれません）

関連Issue

なし

その他

• 本PRは公式ドキュメントの更新に限定されており、CoreCLRの実装コードへの影響はありません
• Copilot Pull Request Reviewerにより4件のコメントが生成されています
• 複数のレビュワー（steveisok、jkotasなど）による確認が行われています

---

#124217 Re-enable Blazor AppsettingsTests disabled during .NET 11 transition

• 作成者: @Copilot
• 作成日時: 2026年02月10日 12:47:34(UTC)
• マージ日時: 2026年02月11日 07:12:56(UTC)
• ラベル: arch-wasm area-Infrastructure-mono os-browser

概要

.NET 10→11への移行中に無効化されていた Wasm.Build.Tests.Blazor.AppsettingsTests.FileInVfs テストを再度有効化するPRです。リポジトリが.NET 11.0.0への移行を完了したため、バージョン不一致による環境の問題が解決され、テストの再有効化が可能になりました。

変更内容

• AppsettingsTests.cs: FileInVfsメソッドから[ActiveIssue]属性を削除してテスト実行を再度有効化
• BuildWasmAppsJobsList.txt: Wasm.Build.Tests.Blazor.AppsettingsTestsをCI実行リストに追加し、Helix上での自動並列実行を可能に

パフォーマンスへの影響

影響なし。本変更はテストの再有効化であり、テストロジック自体は変更されていません。

関連Issue

#122338 - .NET 10→11移行中にAppsettingsTestsが無効化された問題

その他

元々の失敗原因は環境的なものでした。リポジトリがランタイムパックのバージョン10.0.0から11.0.0への完全な移行を完了したため、テスト実行時のバージョン不一致問題が解決されました。テストロジック自体は変更されていないため、既存の検証ロジックは維持されています。

---

#124208 [release/10.0] Fix PerfMap crash when Enable IPC command is sent early in startup

• 作成者: @mdh1418
• 作成日時: 2026年02月10日 01:42:39(UTC)
• マージ日時: 2026年02月11日 13:17:33(UTC)
• ラベル: Servicing-approved area-VM-coreclr

概要

DiagnosticServerが起動初期段階でPerfMap有効化コマンドを受け取った際のクラッシュを修正するバックポート。PerfMap初期化を早期に移動し、依存関係の準備完了までPerfMap機能の実行を遅延させることで、record-traceなどのツールが即座にPerfMapを有効化する場合でも安全に動作するようにします。

変更内容

• perfmap.h: PerfMap依存関係の準備完了を示すvolatileフラグと公開シグナルAPI（SignalDependenciesReady()）を追加
• perfmap.cpp: 準備完了フラグの実装、依存関係準備完了までsendExisting実行の回避、シグナルAPI実装
• ceemain.cpp: EEStartupHelper()でDiagnosticServer初期化前にPerfMap初期化を移動、ExecutionManager::Init()直後に準備完了をシグナル

パフォーマンスへの影響

影響なし。PerfMap初期化位置の変更は依存関係に影響せず、起動時の計算量は同等です。

関連Issue

• #123226（マージ元PR）
• #124055（マージ元PR）

その他

• 対象範囲: release/10.0ブランチへのバックポート
• リスク評価: 低。PerfMap初期化の新位置は他の起動ロジックに依存しません
• 検証方法: WSL2環境でDOTNET_DefaultDiagnosticPortSuspend=1使用時にDiagnosticClient.EnablePerfMapを実行。修正前はsigsegv発生、修正後は安全に処理されることを確認
• ユースケース: .NET 10のuser_events + One Collectのrecord-traceなど、早期段階でのPerfMap有効化がより頻繁に発生するシナリオに対応

---

#124197 Fix misleading obsolete messages for Uri constructors with dontEscape parameter

• 作成者: @Copilot
• 作成日時: 2026年02月09日 21:10:05(UTC)
• マージ日時: 2026年02月11日 12:55:55(UTC)
• ラベル: area-System.Net

概要

Uriクラスの2つの廃止予定コンストラクタにおいて、誤解を招く廃止メッセージを修正するPRです。メッセージが「dontEscapeパラメータは常にfalse」と述べていましたが、実際にはこのパラメータは使用され、内部のUserEscapedフラグを設定します。誤った説明を削除し、より正確なメッセージに変更されました。

// 修正前
[Obsolete("This constructor has been deprecated; the dontEscape parameter is always false. Use Uri(string) instead.")]

// 修正後
[Obsolete("This constructor has been deprecated. Use Uri(string) instead.")]

変更内容

• src/libraries/System.Private.Uri/src/System/Uri.cs

  • Uri(string uriString, bool dontEscape) の廃止メッセージを更新
  • Uri(Uri baseUri, string? relativeUri, bool dontEscape) の廃止メッセージを更新

• src/libraries/System.Runtime/ref/System.Runtime.cs

  • 参照アセンブリの対応するメッセージを同期更新

パフォーマンスへの影響

影響なし。本変更はメタデータ（[Obsolete]属性）のみの更新であり、実装ロジックの変更はありません。

関連Issue

• #56840 - Uri constructors accepting dontEscape have misleading Obsolete attribute
• 元々は #56690 で指摘された問題

その他

• 本PR修正対象のコンストラクタは廃止予定ですが、既存コード互換性の観点からdontEscape=true時の動作（CreateThis()でFlags.UserEscapedフラグを設定）は引き続き機能します
• ドキュメント上のコメントでは「Do not perform character escaping if DontEscape is true」と記載されており、パラメータが実際に機能していることが明確です
• このような古いAPI群は実際には使用を避けるべきですが、存在する限り正確なドキュメンテーションが重要です

---

#124186 Revert System.Text.Json source generator changes from PR #124077

• 作成者: @Copilot
• 作成日時: 2026年02月09日 17:04:53(UTC)
• マージ日時: 2026年02月11日 08:01:46(UTC)
• ラベル: area-System.Text.Json source-generator

概要

PR #124077で導入されたSystem.Text.Json ソースジェネレータの変更を部分的に巻き戻すPRです。変更によりKnownTypeSymbolsがCompilationごとにキャッシュされず、JsonSerializerContext処理時に毎回新規インスタンスが作成されてしまい、パフォーマンスが低下していました。このPRでは、インクリメンタルパイプラインパターンを復元し、KnownTypeSymbolsをCompilation単位でキャッシュすることでパフォーマンス回帰を解決します。

変更内容

• ファイル: src/libraries/System.Text.Json/gen/JsonSourceGenerator.Roslyn4.0.cs
• 主な変更:
  • context.CompilationProvider.Select(...)でIncrementalValueProvider<KnownTypeSymbols>を再導入
  • 属性プロバイダーで.Combine(knownTypeSymbols).Select(...)パイプラインを復元
  • KnownTypeSymbolsインスタンス生成をForAttributeWithMetadataNameコールバック内から、コンパイレーション単位のインクリメンタル生成に変更
  • LoggerMessageGenerator関連の変更は保持

// 復元されたパターン
IncrementalValueProvider<KnownTypeSymbols> knownTypeSymbols = context.CompilationProvider
    .Select((compilation, _) => new KnownTypeSymbols(compilation));

contextGenerationSpecs = context.SyntaxProvider
    .ForAttributeWithMetadataName(...)
    .Combine(knownTypeSymbols)
    .Select(static (tuple, cancellationToken) =>
    {
        Parser parser = new(tuple.Right);  // キャッシュされたKnownTypeSymbols
        // tuple.Left: ContextClass, SemanticModel
    })

パフォーマンスへの影響

改善点:

• KnownTypeSymbolsとCompilation間の1対1対応を復元することで、型シンボル解決の重複を排除
• JsonSerializerContextごとのKnownTypeSymbols再生成オーバーヘッドを解消

計測: 具体的なベンチマーク値は記載されていませんが、逆のパフォーマンス回帰は避けられます。

関連Issue

• PR #124077（巻き戻し元）
• PR #124186（このPR）

その他

• 154個のSystem.Text.Json.SourceGenerationユニットテストが全てパス
• clr+libs ビルド成功
• LoggerMessageGeneratorの変更は影響を受けないため保持

---

#124184 Remove redundant checked contexts around casts + more bounds checks

• 作成者: @EgorBo
• 作成日時: 2026年02月09日 16:54:10(UTC)
• マージ日時: 2026年02月11日 14:11:33(UTC)
• ラベル: area-CodeGen-coreclr

概要

JIT（Just-In-Time）コンパイラの最適化により、冗長なchecked文脈をキャスト操作から削除し、より多くの境界チェック最適化を実施するようになりました。事前の境界チェック（例：if (a > 100) の後の checked((byte)a)）によって安全性が保証される場合、冗長なchecked修飾子を自動的に削除して、不要なチェック処理をスキップします。

変更内容

• src/coreclr/jit/assertionprop.cpp：チェック済みキャスト周辺の冗長なchecked文脈を削除するロジックを追加（67行追加、50行削除）
• src/coreclr/jit/rangecheck.cpp：境界チェック最適化を拡張（17行追加、7行削除）
• src/coreclr/jit/rangecheck.h：境界チェック関連の関数シグネチャを更新（3行追加、3行削除）
• src/tests/JIT/opt/CheckedContext/CheckedContext.cs：新規テストケース415行追加（各種冗長なchecked文脈削除の動作確認）

パフォーマンスへの影響

改善：不要なオーバーフロー/アンダーフロー検査命令が削除され、キャスト操作の実行速度が向上。特に、事前に値の範囲が確認済みのコード部分で、数命令分の削減が期待できます。具体的なベンチマーク値は提供されていません。

関連Issue

なし

その他

• 本最適化はJIT コンパイル時の静的解析により実施されるため、ソースコードの冗長なchecked修飾子の削除は不要です
• Assertion Propagation（アサーション伝播）メカニズムを活用して、既知の値の範囲情報を追跡し、最適化の安全性を保証しています

---

#124132 Increase number of assertions (GlobalAP) + VN cache

• 作成者: @EgorBo
• 作成日時: 2026年02月07日 19:53:18(UTC)
• マージ日時: 2026年02月11日 18:41:42(UTC)
• ラベル: area-CodeGen-coreclr

概要

このPRは.NET JITコンパイラのアサーション伝播（Assertion Propagation）の最適化に関する2つの改善を実装しています。

1. VN（Value Number）キャッシュの追加：アサーション存在チェックをO(1)で実行可能にし、コンパイル時間（TP）の回帰を約50%削減
2. GlobalAPの最大アサーション数を増加：1M個のメソッドを分析した結果に基づき、基本ブロック数とトラッキング対象のローカル変数数をパラメータとする新しいヒューリスティックを導入

結果として、コード生成品質を改善しながらTP回帰を最小限に抑えています。

変更内容

• assertionprop.cpp：VNキャッシュ実装と新しいヒューリスティックアルゴリズムの追加（+80行）
• compiler.h：VNキャッシュデータ構造の宣言追加（+3行）
• rangecheck.cpp：整合性調整（+1/-1行）

パフォーマンスへの影響

• コンパイル時間（TP）：+0.3%の回帰（変更内容としては許容範囲、先行する最適化PRで相殺予定）
• コード生成品質：条件分岐の最適化改善により全体的に向上
• メモリ使用量：変更(1)のみでは無視できるレベル、VNキャッシュ導入による追加メモリ影響は最小限

注記：オプティマイザは複数の試案を比較検討し、TP結果に基づいて最適版を選択。無条件でoptMaxAssertionCountを256に設定した場合、サイズ改善は約8%向上するがTP回帰は3倍に拡大するため不採用。

関連Issue

なし

その他

• SPMIツール（Static Profile Guided Optimization）を使用した1M個の実メソッドに基づく実証的な分析
• AIエージェントによる複数ラウンドのヒューリスティック最適化
• フォワードフロー分析がコンパイル時間で最も負荷が高い処理と判明

---

#124121 [release/10.0] Add missing HAVE_CLOCK_MONOTONIC to config.h.in

• 作成者: @Copilot
• 作成日時: 2026年02月07日 01:46:57(UTC)
• マージ日時: 2026年02月11日 13:15:06(UTC)
• ラベル: Servicing-approved area-System.Threading linkable-framework

概要

.NET 10 Linux環境において、システムクロックが後方に調整されたとき、Task.Delayなどのタイミング操作が無限にハングする回帰バグを修正します。CMakeが単調時計（monotonic clock）のサポートを検出しても、その設定値がPAL config.hヘッダーに伝播されていなかったため、ランタイムが誤って壁時計（CLOCK_REALTIME）にフォールバックしていました。設定ファイルに1行追加することで対応します。

変更内容

• src/coreclr/pal/src/config.h.in: #cmakedefine01 HAVE_CLOCK_MONOTONIC をPAL config.hテンプレートに追加（+1行）
  • CMakeの単調時計検出結果を、生成されるconfig.hに正しく伝播させます

パフォーマンスへの影響

影響あり（改善）：この修正により、Linuxでのタイミング操作は確実に単調時計（CLOCK_MONOTONIC）を使用するようになります。これにより：

• システムクロック後方調整時の無限ハング回避
• より正確で信頼性の高いタイミング測定
• .NET 8/9と同等の動作を復帰

関連Issue

#124086（元のプルリクエスト、本バージョンへのバックポート）

その他

• レグレッション: Yes（.NET 10で新たに発生した問題）
• 顧客報告: 複数の顧客により報告済み
• テスト状況: 顧客がプライベートビルドで修正を確認
• リスク評価: 最小限（CMake設定の1行追加で.NET 8/9の動作を復帰させるもの）

---

#124075 Document EventSourceLoggerProvider non-caching behavior

• 作成者: @Copilot
• 作成日時: 2026年02月06日 08:44:24(UTC)
• マージ日時: 2026年02月11日 12:19:23(UTC)
• ラベル: area-Extensions-Logging

概要

EventSourceLoggerProvider.CreateLogger() がインスタンスをキャッシュせず、呼び出しのたびに新しい EventSourceLogger を生成する非キャッシング動作を明確に文書化するPRです。この動作は意図的（動的なEventSource/ETW設定変更のため連結リストを維持するため）ですが、Serilogのようにログイベントごとに CreateLogger() を呼び出すライブラリを混乱させていました。このPRは動作を変更せず、ドキュメントのみを追加更新します。

変更内容

• EventSourceLoggerProvider.cs: CreateLogger() メソッドにXML文書コメントを追加し、非キャッシング動作と呼び出し側の責任を明記
• EventSourceLogger.cs: 連結リスト追跡とETW動的設定対応のための設計を説明するコメント追加
• EventSourceLoggerFactoryExtensions.cs: AddEventSourceLogger() 拡張メソッドでキャッシング動作の期待値を明確化
• README.md: 「Important Notes」セクション追加。標準的な ILoggerFactory 経由の使用（依存性注入）はキャッシング済み、直接 ILoggerProvider.CreateLogger() 呼び出しはドキュメント化

パフォーマンスへの影響

影響なし（ドキュメント変更のみで、動作は変更されません）

標準的な依存性注入を通じた ILoggerFactory の使用は既にカテゴリ単位でキャッシュされているため、通常の利用は影響を受けません。直接 ILoggerProvider.CreateLogger() を呼び出す消費者のみが呼び出し側キャッシング実装の必要性を認識する必要があります。

関連Issue

#66072

その他

この変更は Issue #66072 にて報告された、Serilog経由でのメモリリーク疑惑に対応したものです。実際のメモリリークではなく、EventSourceLoggerProvider の非キャッシング動作が十分に周知されていないことが原因であり、このPRで文書化による解決を図っています。

---

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

• 作成者: @dotnet-maestro[bot]
• 作成日時: 2026年02月05日 14:50:49(UTC)
• マージ日時: 2026年02月11日 22:27:52(UTC)
• ラベル: Servicing-approved area-codeflow

概要

このPRはEmscripten SDK関連の依存ファイルをrelease/9.0ブランチで更新するものです。主にEmscriptenワークロード関連パッケージとMonoランタイムツールを複数プラットフォーム（Linux、Windows、macOS）向けに一貫性のある最新ビルドに統一しています。

変更内容

更新されたファイル:

• eng/Version.Details.xml (+49/-49)

  • Emscripten SDK関連パッケージのバージョン番号を更新
  • JIT Tools及びLLVM Toolsの複数プラットフォーム向けバージョンを統一

• eng/Versions.props (+23/-23)

  • Microsoft.SourceBuild.Intermediate.emsdk: 9.0.14-servicing.26102.1 → 9.0.14-servicing.26110.3
  • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: 9.0.14-servicing.26102.1 → 9.0.14-servicing.26110.3

• NuGet.config (+1/-1)

  • NuGet設定の軽微な調整

重点更新:

• Runtime.*.Microsoft.NETCore.Runtime.JIT.Tools: 19.1.0-alpha.1.26071.2 → 19.1.0-alpha.1.26104.3
• Runtime.*.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk/Tools: 同上
• 対象プラットフォーム: linux-arm64, linux-x64, linux-musl-arm64, linux-musl-x64, win-arm64, win-x64, osx-arm64, osx-x64

パフォーマンスへの影響

影響なし。この更新は依存パッケージのバージョン管理であり、ランタイム動作やパフォーマンス特性に直接的な影響はありません。

関連Issue

なし

その他

• 本更新は自動化ツール(dotnet-maestro[bot])により実施された依存関係の整合性確認（Coherency Updates）を含みます
• 変更日時: 2026年2月10日（UTC）
• すべてのプラットフォーム向けのツールチェーンが同一ビルド(26104.3)に統一されており、開発環境の一貫性が保証されます

---

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

• 作成者: @dotnet-maestro[bot]
• 作成日時: 2026年02月05日 02:03:05(UTC)
• マージ日時: 2026年02月11日 22:28:14(UTC)
• ラベル: Servicing-approved area-codeflow

概要

dotnet/icu リポジトリの依存パッケージが更新されました。Microsoft.NETCore.Runtime.ICU.Transport が 10.0.0-rtm.26071.1 から 10.0.0-rtm.26104.1 にアップデートされています。この更新は .NET Runtime 10.0 リリースブランチの定期的な依存関係同期の一部です。

変更内容

• eng/Version.Details.props: バージョン情報を1行追加・1行削除（計2行の変更）
• eng/Version.Details.xml: バージョン詳細を2行追加・2行削除（計4行の変更）

変更内容は dotnet/icu リポジトリのコミット 2d6216b24b63b84c1095f6490b735a0535b0c74e に対応しており、Microsoft.NETCore.Runtime.ICU.Transport パッケージの参照をアップデートしています。

パフォーマンスへの影響

影響なし。本PR は依存パッケージバージョンの更新のみで、機能追加やコード変更はなく、パフォーマンスへの直接的な影響はありません。ただし、ICU（International Components for Unicode）ライブラリのアップデートにより、国際化機能に関連するバグ修正やセキュリティ更新が含まれる可能性があります。

関連Issue

なし

その他

• このPRは自動化ツール（dotnet-maestro[bot]）により生成されています
• 対象ブランチは release/10.0 です
• 日付は 2026年2月4日（RTM版の構築日）です

---

#123991 Fix ZipArchiveEntry.ExtractToFile corruption when extraction fails with overwrite=true

• 作成者: @Copilot
• 作成日時: 2026年02月04日 09:43:00(UTC)
• マージ日時: 2026年02月11日 12:29:32(UTC)
• ラベル: area-System.IO.Compression

概要

ZipArchiveEntry.ExtractToFileでoverwrite: true指定時に抽出失敗（パスワード保護やデータ破損など）すると、宛先ファイルが0バイトに破損する問題を修正しました。修正内容は、既存ファイル上書き時に一時ファイルへ抽出してから、抽出成功後のみ宛先へ移動させる戦略です。

// 修正前：ファイルを開いた後に抽出を試みるため、失敗時に既存ファイルが破損
using (var destination = new FileStream(destinationFileName, FileMode.Create))
{
    using (var source = zipArchiveEntry.Open())
    {
        source.CopyTo(destination); // ここで例外発生 → ファイルは既に空に
    }
}

// 修正後：一時ファイルに抽出して、成功時のみ移動
string tempPath = Path.GetTempFileName();
using (var destination = new FileStream(tempPath, FileMode.Create))
{
    using (var source = zipArchiveEntry.Open())
    {
        source.CopyTo(destination); // 例外発生 → 元のファイルは無傷
    }
}
File.Move(tempPath, destinationFileName, overwrite: true);

変更内容

• ZipFileExtensions.ZipArchiveEntry.Extract.cs：同期メソッドExtractToFileに一時ファイル戦略を実装。上書き対象ファイルが存在する場合、Path.GetTempFileName()で一時ファイルを作成して抽出。抽出成功後のみFile.Moveで宛先へ移動。失敗時は一時ファイルをクリーンアップ
• ZipFileExtensions.ZipArchiveEntry.Extract.Async.cs：非同期メソッドExtractToFileAsyncに同等のロジックを実装。FileOptions.Asynchronousフラグを使用し、全てのawait操作にConfigureAwait(false)を適用
• テスト追加：ExtractToFile_OverwritePreservesOriginalFileOnExtractionFailureテストにより、破損データから抽出失敗時に元ファイルが保持されることを検証。190テスト全て成功

パフォーマンスへの影響

懸念点：

• 既存ファイル上書き時に一時ファイル経由で処理するため、追加のI/O操作が発生（コピー→移動）
• 一時ファイルが異なるボリューム上にある場合、クロスボリュームコピーのオーバーヘッドが発生する可能性あり

改善点：

• 非同期実装でFileOptions.Asynchronous使用により、async I/Oパフォーマンス向上
• 抽出失敗時の自動クリーンアップで一時ファイル蓄積を防止
• OSがプロセスクラッシュ時に自動的にテンポラリディレクトリをクリーンアップ

関連Issue

Fixes #123059（ZipArchiveEntry.ExtractToFileが例外時に宛先ファイルを破損）

その他

セキュリティ脆弱性は導入されていません。データ損失防止により堅牢性が向上します。

---

#123986 Remove MethodDescCallSite in comutilnative.cpp

• 作成者: @huoyaoyuan
• 作成日時: 2026年02月04日 08:29:56(UTC)
• マージ日時: 2026年02月11日 18:14:47(UTC)
• ラベル: area-VM-coreclr community-contribution

概要

このPRは、COM相互運用性コードの改善の一環として、comutilnative.cpp内の非効率なMethodDescCallSiteの使用を削除しています。関連Issue #123864に貢献するもので、戻り値サポート機能の追加が含まれています。変更により、COM呼び出し機構の実装がより簡潔になり、保守性が向上します。

変更内容

• comutilnative.cpp: MethodDescCallSiteの直接使用を削除し、より効率的な呼び出し機構に置き換え（68行削除、14行追加）
• callhelpers.h: COM呼び出しの新しいヘルパー実装を追加（51行追加）
• Exception.CoreCLR.cs: COM相互運用エラーハンドリング機能を拡張（56行追加）
• metasig.h: メタデータシグネチャ定義を更新（戻り値関連）
• corelib.h: プロトタイプ定義の調整

パフォーマンスへの影響

直接的なパフォーマンス改善は提示されていませんが、MethodDescCallSiteの削除により、COM呼び出しのオーバーヘッドが軽減される可能性があります。コード削減（68行→14行）により、メモリフットプリントが縮小します。

関連Issue

#123864（COM相互運用性の改善に関連するより大規模な取り組み）

その他

• 複数レビュワーの承認を得ており、特にAaronRobinsonMSFT（COM相互運用性の専門家）による監査が複数回実施されている
• 戻り値サポート機能の追加は、COM呼び出しの機能拡張につながる重要な変更

---

#123907 Fix bug in LowerCallMemmove

• 作成者: @EgorBo
• 作成日時: 2026年02月02日 18:31:19(UTC)
• マージ日時: 2026年02月11日 14:47:30(UTC)
• ラベル: area-CodeGen-coreclr

概要

LowerCallMemmove関数のバグ修正です。CORINFO_HELP_MEMCPY呼び出しで、memmove セマンティクスを使用すべき場合に正しく処理されていませんでした。修正により、Unsafe.CopyBlockUnalignedなどのコピー操作で、すべてのデータをレジスタに読み込んでから一度に書き込む、より効率的なコード生成が実現されます。

static void Test(ref byte a, ref byte b, uint len)
{
    if (len == 200)
    {
        Unsafe.CopyBlockUnaligned(ref a, ref b, len);
    }
}

変更内容

• ファイル: src/coreclr/jit/lower.cpp (+6/-6, 合計12行)
• 変更内容: LowerCallMemmove関数内で、CORINFO_HELP_MEMCPYのハンドリングを修正。GenTreeBlk::BlkOpKindUnrollではなく、memmove モードを使用するよう変更

パフォーマンスへの影響

改善あり: コード生成の最適化により、メモリコピー操作がより効率的になります。

• 修正前: レジスタとメモリ間の往復でデータをコピー（メモリレイテンシの影響大）
• 修正後: すべてのソースデータを複数のレジスタに読み込み、その後一括書き込み（メモリバンド幅の効率的利用）
• SIMD命令（zmm/xmm）の活用により、特に大容量データコピーで効率向上

関連Issue

#123748

その他

• 修正によるビルドテストのDiff無し（回帰なし）
• memmove モードはLSRA（線形スキャンレジスタ割り当て）コストが高いものの、CORINFO_HELP_MEMCPYの使用頻度が低いため、実際の影響は限定的

---

#123883 [release/10.0] Rework and enable Wasm.Build.Tests.Blazor.AssetCachingTests

• 作成者: @github-actions[bot]
• 作成日時: 2026年02月02日 13:12:19(UTC)
• マージ日時: 2026年02月11日 23:15:52(UTC)
• ラベル: Servicing-approved area-Infrastructure

概要

Blazor Wasm テストの AssetCachingTests における競合状態の問題を修正したバックポート。テストサーバーからのログ取得時に発生していた競合状態を解決し、テストの安定性を向上させています。修正後の本番ブランチでは 100% の成功率を達成しており、出荷コードへの影響はなくテストコードのみの修正です。

変更内容

• AssetCachingTests.cs: テストロジックの簡潔化（-17行）
• BlazorWebWasmLogClient.cs: 新規追加（+44行）- テストサーバーからのログ取得を安全に行うクライアント実装
• BlazorWebWasmRequestLog.cs: 新規追加（+15行）- ログデータ構造の定義
• Counter.razor: テスト用ページの修正（+4行）
• BlazorWebWasmRequestLog.cs（testassets）: ログ記録機能の追加（+6行）
• Program.cs（testassets）: ログ記録エンドポイントの実装（+33行）

パフォーマンスへの影響

影響なし。テスト実行時の安定性向上のみで、実行時パフォーマンスへの影響はありません。

関連Issue

なし（#123388 への直接的なバックポート）

その他

• リスク評価: 低（出荷コードへの影響なし）
• テスト成功率: 修正前（release/10.0）は2回の失敗、修正後（main）は過去14日間で 100% 成功
• 修正の性質: テストの競合状態解消のため、ログ取得メカニズムを改善

---

#123822 Add CLI project for managed ilasm

• 作成者: @am11
• 作成日時: 2026年01月30日 22:51:57(UTC)
• マージ日時: 2026年02月11日 23:14:32(UTC)
• ラベル: area-ILTools-coreclr community-contribution

概要

dotnet/runtimeにマネージドILアセンブラ（ilasm）のCLIプロジェクトが追加されました。既存のILアセンブラ機能を.NET CLIツールとして利用可能にするための実装で、コマンドラインインターフェースの整備とプロジェクト構成の強化が行われています。

変更内容

• ilasm.csproj: 新規CLIプロジェクト定義（14行追加）
• Program.cs: メインエントリーポイント実装（297行追加）
• IlasmRootCommand.cs: System.CommandLineベースのCLIコマンド定義（184行追加）
• Options.cs: コマンドラインオプション解析機能の大幅拡張（127行追加）
• GrammarVisitor.cs: IL文法処理ロジックの拡張（165行追加）
• PreprocessedTokenSource.cs: トークン処理の改善（32行追加）
• EntityRegistry.cs: エンティティ登録機能の強化（20行追加）
• DocumentCompiler.cs: ドキュメント処理の微調整（5行追加）
• ilasm.slnx: ソリューションファイルへのプロジェクト追加

パフォーマンスへの影響

影響なし。本変更はCLIツールチェーンの構築と機能統合に焦点を当てており、既存アセンブラのコア処理パフォーマンスに対する直接的な最適化は含まれていません。

関連Issue

なし

その他

このプロジェクトはSystem.CommandLineを使用したモダンなCLIインターフェースの実装と考えられます。マネージドコードで実装されたILアセンブラがCLIツールとして提供可能になることで、.NETツールチェーンの一部として統合される道が開かれました。

---

#123562 Add an in-memory cache for CRLs on Linux

• 作成者: @bartonjs
• 作成日時: 2026年01月23日 20:14:50(UTC)
• マージ日時: 2026年02月11日 05:55:46(UTC)
• ラベル: area-System.Security tenet-performance

概要

LinuxにおけるCRL（Certificate Revocation List）検証の性能向上を目的とした、メモリ内キャッシュレイヤーを追加します。固定サイズ30要素のLRU（Least Recently Used）キャッシュを実装し、GCのファイナライズタイミングで段階的にエントリを削除します。呼び出し元はAddReferenceで参照カウントを管理し、キャッシュ削除時はDisposeを呼び出すことでSafeHandleのファイナライズを回避します。

// キャッシュからCRLを取得（呼び出し元で参照カウント管理）
var crl = cache.GetOrAdd(crlPath);
try
{
    // CRL使用
}
finally
{
    crl.Release(); // 参照カウント減少
}

変更内容

• OpenSslCrlCache.cs (+466行): LRUキャッシュ実装、ファイナライズベースの段階的削除ロジック、AddReference/Dispose管理
• OpenSslX509ChainEventSource.cs (+70行): キャッシュヒット/ミス、削除処理などのETWイベント追加
• X509FilesystemTests.Unix.cs (+122行): キャッシュ動作の単体テスト追加

パフォーマンスへの影響

• 改善: 同一CRLの再検証時にディスク読み込みを回避し、X.509チェーン検証の応答時間を短縮
• メモリ使用量: 固定30要素のキャッシュに限定され、予測可能なメモリフットプリント
• 懸念点: GC頻度が低い環境では、キャッシュエントリの削除が遅延する可能性あり（1分間のウォームアップ期間を設定して対策）

関連Issue

なし

その他

• 実装の特徴: ArrayPoolと同じファイナライズセンチネルパターンを採用し、GCのタイミングに依存した段階的な削除で、即座の削除オーバーヘッドを回避
• 互換性: Linux環境の内部実装変更のため、公開APIへの影響なし
• 参照管理: キャッシュが返すハンドルの参照カウントを管理することで、GCとの競合状態を防止

---

#123296 Fix BitArray to clear dangling high bits in LeftShift and deserialization

• 作成者: @Copilot
• 作成日時: 2026年01月16日 23:57:15(UTC)
• マージ日時: 2026年02月11日 04:14:14(UTC)
• ラベル: area-System.Collections

概要

BitArray.LeftShiftでシフト後に未使用の上位ビットがクリアされず、PopCount()が不正な値を返していた問題を修正しました。デシリアライゼーションコンストラクタでも同様の問題を修正し、ClearHighExtraBits()の呼び出しを追加しました。

// 修正前：LeftShift後にダングリングビットが残る
BitArray ba = new(33);
ba[^1] = true;
ba.LeftShift(1);
// ba.PopCount()が1を返す（不正）

// 修正後：ClearHighExtraBits()で未使用ビットをクリア
// ba.PopCount()が0を返す（正常）

変更内容

• BitArray.cs: LeftShiftメソッドでシフト操作後にClearHighExtraBits()を呼び出し、未使用の上位ビットをクリア
• BitArray.cs: デシリアライゼーションコンストラクタでClearHighExtraBits()を呼び出し、古いバージョンや不正なデータからの逆シリアル化時にゴミビットをクリア
• BitArray_OperatorsTests.cs: LeftShiftとRightShiftの包括的なTheory-basedテストを追加。32ビット境界周辺（1, 8, 31, 32, 33, 64, 65ビット）のエッジケースをカバー

パフォーマンスへの影響

影響なし。ClearHighExtraBits()はシフト操作の最後に最上位ストレージ要素の1つをマスクするのみで、計算量的な変化はありません。

関連Issue

#123281（BitArray ShiftLeftとPopCountが予期しない動作を起こす）

その他

デシリアライゼーションコンストラクタの修正により、古いバージョンから逆シリアル化されたデータや不正形式のデータでも内部不変式が保証されます。この修正はバグ修正であり、既存コードへの互換性問題はありません。

---