Pull Request on 2026年01月30日

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

注意点

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

#123794 Fix bug in RangeOps::ShiftRight

  • 作成者: @EgorBo
  • 作成日時: 2026年01月30日 11:34:55(UTC)
  • マージ日時: 2026年01月30日 21:55:37(UTC)
  • ラベル: area-CodeGen-coreclr

概要

RangeOps::ShiftRight の範囲計算バグを修正しました。右シフト演算で範囲の上下限を入れ替える必要があったミスを解決しています。例えば [0..65535] >> [0..31] の計算結果が [0 >> 31 .. 65535 >> 0] となるべきところが [0 >> 0 .. 65535 >> 31] で計算されていたことを修正しました。

変更内容

  • src/coreclr/jit/rangecheck.h (+26/-23)

    • RangeOps::ShiftRight メソッドの範囲計算ロジックを修正
    • 右シフト演算における下限と上限の計算順序を正しく反転

  • src/tests/JIT/Regression/JitBlue/Runtime_123790/Runtime_123790.cs (+30/-0)

    • バグ再現テストケースを追加
    • Runtime_123790 の回帰テスト

パフォーマンスへの影響

影響なし

関連Issue

dotnet/runtime#123790

その他

  • Azure DevOps のビルド結果でコード差分がなし（No diffs）と報告されており、純粋なロジック修正です
  • Copilot レビューにより2ファイル中2ファイルがレビュー対象となりました

#123791 Move OneLocBuild back to run on every main commit

  • 作成者: @akoeplinger
  • 作成日時: 2026年01月30日 10:30:45(UTC)
  • マージ日時: 2026年01月30日 10:35:39(UTC)
  • ラベル: area-Infrastructure

概要

OneLocBuild（ローカライゼーション処理）の実行スケジュールを変更するPRです。前回のPR #123539で両方のビルドを定期実行のみに変更していましたが、OneLoc チームからの要望により、OneLocBuild を毎回のメインコミット時に実行するように戻しました。一方、SourceIndex は引き続き日次スケジュール実行のままです。

変更内容

  • eng/pipelines/runtime-official.yml (+14/-12, 計26行)
    • OneLocBuild（Localization ステージ）：毎メインコミット実行に変更
    • SourceIndex ステージ：スケジュール実行（日次）のままに変更
    • スケジュール表示名：「Daily OneLocBuild and SourceIndex」から「Daily SourceIndex」に更新

パフォーマンスへの影響

OneLocBuild が毎回のメインコミット時に実行されることで、CI/CD パイプライン全体の実行時間が増加する可能性があります。ただし、OneLoc チームのシステムでアラート発生を防ぐために必要な変更であるため、実質的にはビルド頻度の正常化による改善です。

関連Issue

#123539（前回のスケジュール変更PR）

その他

OneLoc チーム（dotnet/runtime の多言語対応を担当）からの要望に基づいた変更です。ローカライゼーションビルドが定期的に実行されないと、外部の監視システムでアラートが発生するため、この変更は運用上の要件です。

#123785 Replace mangod9 with agocke under area-vm-coreclr in resourceManagement.yml

  • 作成者: @Copilot
  • 作成日時: 2026年01月30日 03:34:00(UTC)
  • マージ日時: 2026年01月30日 04:09:40(UTC)
  • ラベル: 指定なし

概要

GitHub リソース管理ポリシー内で、area-vm-coreclr ラベルの担当者を mangod9 から agocke に変更するメンテナンス更新です。このPRは GitHubの自動ラベリングおよび通知システムの設定変更のみで、.NET ランタイムのコード変更は含まれていません。

変更内容

  • .github/policies/resourceManagement.yml (1645行目): area-vm-coreclr ラベル配下の mentionee を mangod9 から agocke に更新（+1/-1）

パフォーマンスへの影響

影響なし （この変更は GitHub ワークフロー設定のみの変更であり、ランタイムパフォーマンスや実行速度に影響しません）

関連Issue

なし

その他

  • このPRは Copilot によって自動生成されました
  • 変更は管理設定（resource management policy）のみであり、機能コードの変更はありません
  • area-vm-coreclr ラベル付きのIssue/Pull Request は、今後 agocke にメンションされるようになります

#123776 Enable cached interface dispatch by default on non-JIT platforms

  • 作成者: @Copilot
  • 作成日時: 2026年01月29日 21:57:46(UTC)
  • マージ日時: 2026年01月30日 19:02:39(UTC)
  • ラベル: 指定なし

概要

iOS などの非 JIT プラットフォームで R2R 仮想ディスパッチが毎回 ExternalMethodFixupWorker にフォールバックし、署名解析に 18% の時間を消費していた問題を修正。キャッシュされたインターフェースディスパッチをデフォルトで有効化することで、200x の性能低下を解決します。

// Crossgen2RootCommand.cs での変更
public Option<bool?> EnableCachedInterfaceDispatchSupport { get; } =
    new("--enable-cached-interface-dispatch-support", "--CID") { ... };

// Program.cs での条件付きデフォルト適用
nodeFactoryFlags.EnableCachedInterfaceDispatchSupport = 
    Get(_command.EnableCachedInterfaceDispatchSupport) ?? 
    !typeSystemContext.TargetAllowsRuntimeCodeGeneration;

変更内容

ファイル 変更内容
Crossgen2RootCommand.cs EnableCachedInterfaceDispatchSupport オプションを bool から bool? に変更し、3値ロジック（true/false/未指定）をサポート
Program.cs Null 統合演算子を使用した条件付きデフォルトロジックを追加。ユーザー指定がない場合、TargetAllowsRuntimeCodeGeneration が false（非 JIT プラットフォーム）なら true をデフォルト化
Resources.resx ヘルプテキストを更新。デフォルト値がランタイムコード生成をサポートしないプラットフォームで true になることを明記

対象プラットフォーム（デフォルト true）:

  • iOS、iOSSimulator、tvOS、tvOSSimulator、MacCatalyst、WASM/WASI

パフォーマンスへの影響

改善： 200x の性能低下を解決。キャッシュされたインターフェースディスパッチにより、R2R コンパイルされたコードで呼び出しサイトが正しくパッチされるため、毎回の高コストな署名解析が不要に。

計測結果： 元々の問題では ExternalMethodFixupWorker が 18% の実行時間を消費していたが、このパッチで排除可能。

互換性： ユーザーが --enable-cached-interface-dispatch-support を明示指定した場合は、その値が全プラットフォームで優先される。既存の JIT 対応プラットフォーム（Windows、Linux）はデフォルト false のため、既存動作を維持。

関連Issue

#123622 (ValueTupleCompareCached マイクロベンチマークが iOS ライク設定で遅い)

その他

  • 変更は Crossgen2（AOT コンパイラ）に限定され、ランタイムコアには影響なし
  • Platform-conditional な設計により、将来的に他のプラットフォーム固有の最適化を容易に追加可能
  • R2R インターフェースディスパッチのコスト課題は AOT コンパイルパイプラインの改善であり、出力される IL に影響しない

#123772 Add initOpt, VTable fixups, type forwarders

  • 作成者: @am11
  • 作成日時: 2026年01月29日 20:05:26(UTC)
  • マージ日時: 2026年01月30日 22:42:47(UTC)
  • ラベル: area-ILTools-coreclr community-contribution

概要

ILアセンブラ（ilasm）の機能拡張PRで、.param/.propertyのデフォルト値（initOpt）、VTableフィックスアップ、型フォワーダー、汎用パラメータの出力などをサポートしました。IL言語の仕様により準拠した実装となり、より複雑なアセンブリメタデータの生成が可能になります。

変更内容

  • CIL.g4: ANTLR文法の軽微な調整（2行変更）
  • Diagnostic.cs: 診断メッセージ追加（2行）
  • EntityRegistry.cs: メタデータエンティティの登録機能強化（+97行、型フォワーダーやVTableフィックスアップの管理）
  • GrammarVisitor.cs: IL構文解析ロジックの大幅拡張（+381行、initOpt、VTableフィックスアップ、例外ハンドラオフセット対応など）
  • ILCompilation.cs: 不要コードの削除（-20行）
  • VTableExportPEBuilder.cs: 新規追加（628行、VTableフィックスアップのPE出力処理）
  • VTableFixupSupport.cs: 新規追加（239行、VTableフィックスアップのサポート実装）
  • DocumentCompilerTests.cs: テストケース大幅追加（+1248行、新機能の包括的なテストカバレッジ）

パフォーマンスへの影響

影響なし。メタデータ生成パイプラインの機能拡張であり、アセンブリコンパイル時のオーバーヘッド増加は最小限と考えられます。

関連Issue

なし

その他

  • テストカバレッジが非常に充実（1248行の新規テスト）しており、複数の複雑なシナリオをカバー
  • 汎用パラメータ出力、ExplicitLayout解析、アセンブリフラグ解析などの複数の関連修正も同時対応
  • IL仕様上の重要な機能追加であり、ネイティブ相互運用性の向上に寄与

#123763 [NativeAOT] Do not overwrite throw frame with first rethrow frame

  • 作成者: @rcj1
  • 作成日時: 2026年01月29日 18:17:48(UTC)
  • マージ日時: 2026年01月30日 04:17:20(UTC)
  • ラベル: needs-area-label

概要

NativeAOTでの例外スタックトレース表示の不具合を修正するPRです。従来はthrow;で例外を再スローした際に、元のthrow new Exceptionの位置を上書きしてしまう問題がありました。本修正により、CoreCLRと同様に元のスロー位置を保持するようになります。

// 修正前: スタックトレースに "throw" と表示される
// 修正後: スタックトレースに "throw new Exception" と表示される
try
{
    throw new Exception("test");
}
catch
{
    throw;  // ← ここが上書きされていた
}

変更内容

  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Exception.NativeAot.cs
    • AppendStackIPメソッド：isFirstRethrowFrameパラメータを削除し、リスロー時のスタックフレーム上書きロジックを廃止
    • AppendExceptionStackFrameメソッド：isFirstRethrowFrameがtrueの場合、AppendStackIPの呼び出しをスキップ

パフォーマンスへの影響

影響なし。本修正は例外処理時のスタックトレース記録ロジックの修正であり、正常系のパフォーマンスパスには影響しません。

関連Issue

  • #107507（NativeAOT関連）
  • #9518（CoreCLRでの同様の不具合報告）
  • coreclr#16464（CoreCLRでの対応修正）

その他

本修正はCoreCLRの既存修正（2017年）をNativeAOTに適用するもので、NativeAOTの例外処理動作をCoreCLRと統一します。スタックトレースの正確性向上により、デバッグ時の根本原因特定がより容易になります。

#123761 Remove isAsync flag validation from FileStream constructors

  • 作成者: @Copilot
  • 作成日時: 2026年01月29日 17:22:42(UTC)
  • マージ日時: 2026年01月30日 09:32:24(UTC)
  • ラベル: 指定なし

概要

FileStream コンストラクタから isAsync パラメータの検証ロジックを削除し、ハンドルの実際の非同期状態を常に使用するように変更しました。これまでユーザー指定の isAsync が SafeFileHandle.IsAsync と一致しない場合は ArgumentException がスローされていましたが、今後はハンドルの状態を優先します。isAsync パラメータはAPI互換性のため残されますが機能的には無視されます。

// 以前: ArgumentException をスロー
var asyncHandle = new SafeFileHandle(..., isAsync: true);
var fs = new FileStream(asyncHandle, FileAccess.ReadWrite, 4096, isAsync: false);

// 現在: 成功 - fs.IsAsync == true（パラメータではなくハンドルから）

変更内容

  • FileStream.cs: isAsync パラメータの検証ロジック削除、戦略選択時に常に handle.IsAsync を使用
  • ThrowHelper.cs: 未使用のスロー補助メソッド削除（ThrowArgumentException_HandleNotAsync/Sync）
  • Strings.resx: 未使用のリソース文字列削除（Arg_HandleNotAsync/Sync）
  • ctor_sfh_fa_buffer_async.cs: テスト更新、パラメータ不一致時の動作（非同期I/O操作）を検証

パフォーマンスへの影響

影響なし。本変更は検証ロジック削除によるコンストラクタ呼び出しの微細な高速化が期待されますが、測定可能なパフォーマンス差は未検出。

関連Issue

#123760（元Issue）、#123483（関連PR）

その他

破壊的変更ではありません。既存コードが isAsync の不一致で ArgumentException を期待していた場合のみ動作変更の影響を受けます。ハンドルの実際の非同期状態を常に使用することで、API設計の簡潔化と互換性の向上が実現されます。

#123658 Update documentation for AddHostedService.

  • 作成者: @cincuranet
  • 作成日時: 2026年01月27日 08:19:48(UTC)
  • マージ日時: 2026年01月30日 08:26:11(UTC)
  • ラベル: area-Extensions-Hosting

概要

AddHostedService 拡張メソッドのXML ドキュメンテーションを更新し、これらのメソッドが DI コンテナに IHostedService としてのみ登録され、具体的な型そのものは登録されないことを明確化しました。開発者が具体型も登録されると期待していた混乱（Issue #53831）を解決するものです。

変更内容

ファイル： src/libraries/Microsoft.Extensions.Hosting.Abstractions/src/ServiceCollectionHostedServiceExtensions.cs (+26 行)

  • AddHostedService の両方のオーバーロードに <remarks> セクションを追加
  • 登録動作（IHostedService インターフェイスのみ登録）を説明
  • 具体型と hosted service の両方を登録する際のワークアラウンドパターンをコード例で提示
// 例：具体型と IHostedService の両方を登録する場合
services.AddSingleton<MyHostedService>();
services.AddHostedService(provider => provider.GetRequiredService<MyHostedService>());

パフォーマンスへの影響

影響なし

関連Issue

#53831

その他

  • ドキュメンテーション専用の変更のため、ランタイム動作への影響なし
  • 既存の動作は変更されず、API 仕様の説明がより明確になることで開発者の理解が向上

#123646 Use IndexOfAny in Console's TermInfo

  • 作成者: @stephentoub
  • 作成日時: 2026年01月26日 22:19:20(UTC)
  • マージ日時: 2026年01月30日 23:13:25(UTC)
  • ラベル: area-System.Console

概要

System.ConsoleのTermInfo printf形式解析をシンプル化するPull Requestです。手動のスキャンループをIndexOfAnyに置き換えることで、フォーマット終端文字(d/o/x/X/s)を検索する処理をより簡潔に実装しました。

// 変更前の処理をIndexOfAnyで置き換え
// 例: format.AsSpan(pos).IndexOfAny("doxXs")を使用

変更内容

  • ファイル: src/libraries/System.Console/src/System/TermInfo.cs
    • printf形式解析ループをIndexOfAnyメソッドへ置き換え（-8行）
    • 返却インデックスを絶対位置に調整（printfEnd += pos）
    • 終端文字が見つからない場合の既存エラー挙動を保持

パフォーマンスへの影響

影響なし。作成者が「パフォーマンス上重要ではない」とコメントしているように、この変更は可読性・保守性の向上が主目的です。IndexOfAnyはランタイムで最適化された実装を使用するため、手動ループと同等かそれ以上の効率で動作します。

関連Issue

なし

その他

  • 内部実装の改善で、publicな破壊的変更なし
  • エラーハンドリング挙動に変更なし

#123593 Add IdnMapping Span-based APIs (TryGetAscii/TryGetUnicode)

  • 作成者: @Copilot
  • 作成日時: 2026年01月25日 13:44:23(UTC)
  • マージ日時: 2026年01月30日 02:03:20(UTC)
  • ラベル: area-System.Globalization

概要

IdnMapping に Span ベースの API (TryGetAscii/TryGetUnicode) を追加し、国際化ドメイン名の変換時にメモリアロケーションを回避できるようにしました。新しいメソッドは無効入力時に例外をスロー、宛先バッファ不足時のみ false を返します。

public sealed class IdnMapping
{
    public bool TryGetAscii(ReadOnlySpan<char> unicode, Span<char> destination, out int charsWritten);
    public bool TryGetUnicode(ReadOnlySpan<char> ascii, Span<char> destination, out int charsWritten);
}

変更内容

ファイル 変更内容
IdnMapping.cs Span ベース公開 API 2 つを追加、共有ロジックを実装
IdnMapping.Nls.cs Windows NLS 実装を Span ベース interop に対応、Try* コア実装を追加
IdnMapping.Icu.cs ICU 実装を Span ベース interop に対応、Try* コア実装を追加
Interop.Idna.cs ICU グローバライゼーション用 Span ベース P/Invoke オーバーロード追加
Interop.Idna.cs（Windows） Windows Normaliz 用 Span ベース P/Invoke オーバーロード追加
DomainNameHelper.cs 新 Span ベース API を利用してストリング割り当てを削減
System.Runtime.cs リファレンスアセンブリに新公開 API を公開
テストファイル TryGetAscii/TryGetUnicode の包括的なテストを追加

パフォーマンスへの影響

改善点：

  • Span ベース API により、IDN 変換時の一時的なストリング割り当てを完全に回避可能
  • DomainNameHelper.TryGetUnicodeEquivalent で新 API を使用することで直接的な割り当て削減
  • URI やマークダウンパーサなど国際化ドメイン名を扱うコンポーネントでメモリ効率向上

その他：

  • source.Overlaps(destination) パターンを使用したオーバーラップバッファチェック実装済み
  • 無効入力時の例外スロー動作は既存 API と一貫性あり

関連Issue

  • dotnet/runtime#32411
  • dotnet/runtime#123593

その他

  • Span-based Try* メソッドの戻り値 false は宛先バッファ不足のみを示す（無効入力は例外）
  • ソースと宛先バッファがオーバーラップする場合は ArgumentException をスロー
  • ICU と NLS 両実装パスに対応、プラットフォーム横断的なサポート
  • 既存テストデータを活用した包括的なテスト追加

#123584 Fix RangeOps::And incorrect range analysis for bitwise AND

  • 作成者: @Copilot
  • 作成日時: 2026年01月24日 22:53:49(UTC)
  • マージ日時: 2026年01月30日 10:04:29(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラの範囲解析におけるビット演算AND（RangeOps::And）のバグを修正しました。負の下限を持つ広い範囲のオペランドがある場合、不正な範囲推定が行われ、Release buildで間違った最適化判定が発生していました。

// 修正前：Release buildで誤った最適化が発生
if (35009 > (1264240267 & (sbyte)(-s_4)))  // 本来falseなのにtrueと判定された
{
    System.Console.WriteLine(1UL);
}

変更内容

  • Range::IsSingleConstValue — 範囲が単一定数値かどうかを判定する新しいヘルパーメソッドを追加
  • RangeOps::And — より保守的な実装に書き換え：
    • 両オペランドが単一定数 → 実際のAND結果を返す
    • 一つが非負単一定数 → [0, constant]を返す
    • その他 → Unknown（不正確な範囲の代わり）を返す
  • RangeOps::UnsignedMod — 新しいヘルパーを使用して簡略化
  • 回帰テスト — Runtime_123583.csを追加

パフォーマンスへの影響

影響なし。この修正はコンパイル時の範囲解析の正確性向上であり、実行時パフォーマンスには直接的な影響なし。ただし、不正な最適化による誤動作が防止されるため、プログラムの正確性が向上します。

関連Issue

#123583

その他

  • JITコンパイラの内部実装（rangecheck.h）の修正で、公開APIには影響なし
  • 破壊的変更なし
  • コンパイル最適化に関する重要なバグ修正

#123508 [clr-interp] Cause compilation to be skipped when using function only used by tail-call helper

  • 作成者: @davidwrighton
  • 作成日時: 2026年01月22日 21:08:36(UTC)
  • マージ日時: 2026年01月30日 15:38:30(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

NextCallReturnAddress intrinsic は tail-call helper 関数内でのみ使用されます。一部の interpreter モードでこの tail-call helper の interpretation が試みられると問題が発生するため、compilation を スキップするようにしました。これにより、不要な compilation 処理を削減し、interpreter モードでの安定性を向上させます。

変更内容

  • src/coreclr/interpreter/compiler.cpp (+7行)

    • tail-call helper 関数の compilation スキップロジックを追加

  • src/coreclr/interpreter/eeinterp.cpp (+7行)

    • interpreter 実行時に tail-call helper 関数を処理するロジックを追加

  • src/coreclr/interpreter/failures.h (+1行)

    • 新たな失敗ケース定義を追加

パフォーマンスへの影響

改善点：不要な compilation 処理がスキップされるため、interpreter モードでの処理時間が削減されます。特に tail-call helper 関数の compilation による オーバーヘッドが回避されます。

関連Issue

なし

その他

  • 変更は interpreter モード固有のロジックに限定されており、JIT compilation や通常の実行パスへの影響はありません
  • NextCallReturnAddress intrinsic は tail-call helper 内部実装の詳細であり、外部 API への影響なし

#123483 Add File.OpenNullHandle() for efficient process I/O redirection

  • 作成者: @Copilot
  • 作成日時: 2026年01月22日 09:56:31(UTC)
  • マージ日時: 2026年01月30日 16:56:24(UTC)
  • ラベル: area-System.IO

概要

プロセスの標準出力・標準エラー・標準入力を効率的に破棄するための新しい File.OpenNullHandle() API を追加します。従来は出力データを読み込んで無視する非効率な方法が必要でしたが、本APIにより null デバイスへのハンドルを直接取得できます。

// 新しい効率的なパターン
using SafeFileHandle nullHandle = File.OpenNullHandle();
process.StartInfo.StandardOutput = nullHandle;
process.StartInfo.StandardError = nullHandle;

変更内容

  • API追加: System.IO.File.OpenNullHandle() の公開API定義（ref ファイルに追加）
  • Windows実装: File.Windows.cs に "NUL" デバイスを開く処理を実装
  • Unix実装: File.Unix.cs に "/dev/null" デバイスを開く処理を実装
  • コア実装: File.cs にドキュメント付きの OpenNullHandle() メソッドを追加（FileOptions.None で O_CLOEXEC/非継承を強制）
  • テスト: 14個のテストケースを追加（同期/非同期の読み書き、並行アクセス検証）

パフォーマンスへの影響

改善点:

  • プロセスの不要な出力を破棄する際の CPU/メモリオーバーヘッドを排除
  • OutputDataReceived イベントハンドラで空ループを回す必要がなくなり、GC圧力軽減

特性:

  • ハンドルは再利用可能（複数プロセスで同一ハンドルを共有可能）
  • 読み込みは常に EOF（0 バイト）を返す
  • 書き込みは常に成功

関連Issue

  • dotnet/runtime#122803（オリジナルIssue）
  • #123760（ファイルストリーム非同期ハンドル検証の問題、別途追跡中）

その他

  • ハンドルは Windows では継承不可（デフォルト）、Unix では O_CLOEXEC フラグで子プロセスへの漏洩を防止
  • FileStream(handle, FileAccess.*) の簡略化されたコンストラクタと互換性あり
  • 理論テストで明示的な isAsync パラメータの使用は、FileStream の同期ハンドル検証によりリバートされた

#123346 [Mono]: Fix stackwalk callbacks calling mono_jit_info_get_method in async signal safe mode.

  • 作成者: @lateralusX
  • 作成日時: 2026年01月19日 12:19:35(UTC)
  • マージ日時: 2026年01月30日 10:38:12(UTC)
  • ラベル: needs-area-label

概要

Monoのスタックウォーク時に、非同期シグナルセーフモードで読み込まれたMonoJitInfoに対してmono_jit_info_get_methodを呼び出すとアサーション失敗が発生する問題を修正しました。AOT メソッドのMonoJitInfoがシグナルハンドラから呼び出された際にロードされると、asyncフラグが立てられ、このフラグが立った状態でメソッドアクセスを試みるとデッドロックのリスクがあります。本修正では、メソッドアクセス前にasyncフラグをチェックして安全に処理できるようにしました。

// 修正前の危険な呼び出し
mono_jit_info_get_method(ji); // ji->async == true の場合、アサーション失敗

// 修正後の安全な呼び出し
if (ji && !ji->async) {
    mono_jit_info_get_method(ji);
}

変更内容

  • src/mono/mono/mini/mini-exceptions.c

    • mono_find_jit_info (601行目付近): メソッド取得前に!ji->asyncチェックを追加
    • print_stack_frame_signal_safe (2912行目付近): 同様に!ji->asyncチェックを追加

  • src/mono/mono/metadata/threads.c

    • dump_thread (3046行目付近): スレッドダンプ収集時にmono_jit_info_get_method呼び出し前に!frame->ji->asyncチェックを追加

パフォーマンスへの影響

影響なし （条件チェックの追加のみで、パフォーマンス低下なし。むしろクラッシュを防止することで安定性向上）

関連Issue

  • #122797: .NET 10でのアサーション失敗に関する報告
  • #123346: 本PR

その他

本修正は commit d34ef7e2d3f41f85d35d23ec484f7af566fd0d2f で拡張されたスタックウォーク機能の副作用を解決しています。シグナルハンドラから呼び出されるget_thread_dumpとmono_handle_native_crashの2つの処理パスが該当します。

#123110 Remove legacy XUnitWrapper test tree infrastructure

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年01月13日 00:34:12(UTC)
  • マージ日時: 2026年01月30日 22:46:11(UTC)
  • ラベル: area-Infrastructure

概要

legacy XUnitWrapper テスト基盤の削除を行うPRです。新しいテストシステムへの完全移行に伴い、古いXUnitWrapper ロジックをテストビルドシステムとHelix パブリッシングから削除します。BuildAllTestsAsStandalone=true シナリオの互換性維持のため、基本的なローカルテストランナーを新たに追加しています。

変更内容

  • 削除対象:

    • src/tests/Common/Coreclr.TestWrapper/ 全体（MobileAppHandler含む）
    • src/tests/xunit-wrappers.targets （506行削除）
    • Helix パイプラインテンプレートから XUnitWrapper 関連ロジック削除

  • 追加対象:

    • src/tests/Common/CoreCLRTestLibrary/CoreclrTestWrapperLib.cs に新たなテストラッパー実装（579行）
    • src/tests/Common/XUnitLogChecker/XUnitLogChecker.cs を拡張（332行追加）
    • src/tests/run.py に基本的なスタンドアロンテストランナー実装

  • 修正対象: build.proj、build.cmd、build.sh、tests.targets のテストビルドロジック更新

パフォーマンスへの影響

影響なし。本変更はテスト基盤の統一化を目的としており、テスト実行のパフォーマンス特性には直接的な変更なし。ビルド複雑性の削減により、CI/CD パイプラインの効率化が期待されます。

関連Issue

なし

その他

  • テストシステムの二重メカニズムが廃止され、単一のテスト実行メカニズムへの統一が実現
  • BuildAllTestsAsStandalone=true シナリオは新しい run.py ベースのランナーに移行
  • 破壊的変更ではなく、後方互換性を維持する形での移行設計

#122970 Remove CHK_FLOW_UPDATE stress mode

  • 作成者: @Copilot
  • 作成日時: 2026年01月07日 12:21:07(UTC)
  • マージ日時: 2026年01月30日 20:12:24(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT コンパイラから CHK_FLOW_UPDATE ストレスモードを削除し、fgDebugCheckUpdate() 関数がすべてのデバッグビルドで無条件に実行されるようにしました。これにより、開発時のフロー グラフ検証カバレッジが向上します。

変更内容

ファイル 変更内容
src/coreclr/jit/compiler.h ストレスモード列挙からSTRESS_MODE(CHK_FLOW_UPDATE) マクロを削除
src/coreclr/jit/fgdiagnostic.cpp fgDebugCheckUpdate() 関数から compStressCompile(STRESS_CHK_FLOW_UPDATE, 30) 条件チェックを削除し、デバッグビルドでの実行を無条件化

パフォーマンスへの影響

デバッグビルドの JIT コンパイル時間に若干の増加が予想されます。fgDebugCheckUpdate() はフロー グラフの検証を行う関数で、これまでストレスモードによる 30% の確率での実行から無条件実行へ変更されるため、コンパイル時間が増加する可能性があります。ただし、デバッグビルド固有の動作であり、リリースビルドへの影響はありません。

関連Issue

なし

その他

  • fgDebugCheckUpdate() 関数自体は削除されず、デバッグビルドで常に呼び出される
  • フロー グラフの不変条件検証（到達不可能ブロック、空ブロック、未インポート ブロック、未圧縮ブロック、不要なジャンプ、BBJ_CALLFINALLY ブロック構造）は継続して実行される
目次