Pull Request on 2026年01月26日

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

注意点

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

#123613 Clarify compilation and testing requirements in copilot-instructions

  • 作成者: @stephentoub
  • 作成日時: 2026年01月26日 03:27:54(UTC)
  • マージ日時: 2026年01月26日 03:34:04(UTC)
  • ラベル: area-Infrastructure

概要

このPRはcopilot-instructions.mdのコンパイルとテスト要件を厳格化し、ビルドプロセスをより決定論的にするものです。コンパイル/テスト要件を"SHOULD"から"MUST"に昇格させ、コメント変更のみの例外を削除しました。またSystem.Private.CoreLibの再構築設定を-rc releaseから-rc checkedに修正しています。

変更内容

  • .github/copilot-instructions.md
    • コンパイルおよびテスト要件を"SHOULD"から"MUST"に変更（強制化）
    • コメント変更のみでビルドをスキップできる例外を削除
    • ベースラインビルド完了後に変更およびテストを実施することを明確化
    • Librariesコンポーネントのビルドとテスト指示を統合
    • System.Private.CoreLib再構築設定を-rc releaseから-rc checkedに修正
    • CoreCLRおよびMonoコンポーネントの個別ビルドセクションを削除（テスト指示は維持）

パフォーマンスへの影響

影響なし（プロセス指示の明確化であり、実装変更ではない）

関連Issue

なし

その他

注意点： Copilotの低信頼度コメント（3件）で指摘されている通り、以下の懸念があります：

  1. Librariesの段階的ビルド: ベースラインビルド後、ライブラリのみを再構築するコマンド（./build.sh libs -rc release）が削除されたため、開発者が段階的ビルドを行う方法が不明確になる可能性があります。

  2. CoreCLRの段階的ビルド: ベースラインで./build.sh clr+libs+hostを実行後、CoreCLR変更時に./build.sh clrで個別に再構築する方法が示されていません。

  3. Monoの段階的ビルド: 同様にMonoの個別再構築方法が明示されていません。

これらの点は、実装の効率性向上のため別途の改善検討が推奨されます。

#123603 JIT: Fix mask AND with zero incorrectly folded

  • 作成者: @Copilot
  • 作成日時: 2026年01月25日 22:37:24(UTC)
  • マージ日時: 2026年01月26日 18:13:04(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITの定数折畳最適化（gtFoldExprHWIntrinsic）でマスク型と定数ゼロのAND演算が誤って折畳まれ、ゼロではなくマスク値を返していたバグを修正しました。.NET 10.0での回帰です。

// 期待値: <0, 0, 0, ...>  バグ時の実際: <-1, -1, -1, ...>
Vector512.Equals(v, v) & Vector512.LessThan(v.AsUInt32(), Vector512<uint>.Zero).AsInt32();

変更内容

  • src/coreclr/jit/gentree.cpp: GT_ANDケースでマスク型の定数折畳処理を修正。resultNode = otherNodeからresultNode = gtWrapWithSideEffects(cnsNode, otherNode, GTF_ALL_EFFECT)に変更し、ベクトル型と同じ処理に統一
  • src/tests/JIT/Regression/JitBlue/Runtime_123399/: 回帰テストを追加（AVX-512が必須）
  • src/tests/JIT/Regression/Regression_ro_1.csproj: テストファイルをプロジェクトに登録

パフォーマンスへの影響

影響なし。本修正は正確性の向上であり、誤った最適化を修正するもので、パフォーマンスへの悪影響はありません。

関連Issue

#123399

その他

この修正はマスク型とベクトル型の定数折畳処理を統一するもので、構造的な一貫性も向上させます。AVX-512対応環境でのみ回帰が発生していました。

#123600 Add test coverage for DateTime.ParseExact with different DateTimeStyles

  • 作成者: @Copilot
  • 作成日時: 2026年01月25日 18:20:13(UTC)
  • マージ日時: 2026年01月26日 03:50:26(UTC)
  • ラベル: area-System.DateTime

概要

DateTime.ParseExactに関するテストカバレッジを拡充するPRです。特にDateTimeStylesパラメータのカバレッジが不足していた部分を補填しています。新たに9つのテストケースを追加し、無効なスタイル組み合わせの検証も強化されています。

変更内容

ファイル: src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DateTimeTests.cs

  • ParseExact_ValidInput_Succeeds_MemberData への追加テスト（9ケース）

    • RoundtripKind: 3ケース（'K'フォーマット指定子でUTC kindの保持を検証）
    • AssumeLocal: 2ケース（タイムゾーン情報なしの日付がローカルとして解釈されることを検証）
    • NoCurrentDateDefault: 2ケース（日付要素が欠落時に0001-01-01が使用されることを検証）
    • AllowInnerWhite: 2ケース（内部空白の処理を検証）

  • InvalidDateTimeStyles テストの拡張

    • [Fact]から[Theory]へ変更
    • 4つの無効なスタイル組み合わせを検証： 
      [InlineData(DateTimeStyles.AssumeLocal | DateTimeStyles.AssumeUniversal)]
[InlineData(DateTimeStyles.RoundtripKind | DateTimeStyles.AssumeLocal)]
[InlineData(DateTimeStyles.RoundtripKind | DateTimeStyles.AssumeUniversal)]
[InlineData(DateTimeStyles.RoundtripKind | DateTimeStyles.AdjustToUniversal)]

パフォーマンスへの影響

影響なし（テストコード追加のみ）

関連Issue

  • #25295（本PR）
  • corefx#27678（コンテキスト提供元）

その他

全1356個のDateTimeテストが成功しており、既存機能への回帰がないことが確認されています。

#123599 Improve ConcurrentDictionary test coverage by asserting callback arguments

  • 作成者: @Copilot
  • 作成日時: 2026年01月25日 18:17:20(UTC)
  • マージ日時: 2026年01月26日 12:04:52(UTC)
  • ラベル: area-System.Collections

概要

ConcurrentDictionary.GetOrAdd と AddOrUpdate メソッドのテストにおいて、コールバックデリゲートの引数が正しく渡されることを検証するアサーションを追加しました。従来のテストではラムダ式が引数を使用しないか検証なしで使用していたため、引数渡しのバグを検出できませんでした。本変更により、各コールバック内で明示的なアサーションを追加し、期待値が正しく渡されることを確認します。

// GetOrAdd の例
dict.GetOrAdd(j, x =>
{
    Assert.Equal(j, x);
    return -x;
});

変更内容

  • ファイル: src/libraries/System.Collections.Concurrent/tests/ConcurrentDictionary/ConcurrentDictionaryTests.cs
  • 変更内容:
    • TestGetOrAddOrUpdate テストメソッドにおいて、GetOrAdd の両オーバーロード（引数なし、引数あり）のコールバック内にアサーションを追加
    • AddOrUpdate の3つのオーバーロードのコールバック内に、キー、値、ファクトリ引数の検証アサーションを追加
    • 合計44行の変更（39行追加、5行削除）

パフォーマンスへの影響

影響なし。本変更はテストコードのみの修正であり、ランタイムの実装や本番コードには影響しません。

関連Issue

  • Fixes dotnet/runtime#83429

その他

本PR は Issue #83429 において、stephentoub による「テスト内でバグを検出できるような変更を加えよ」というコメントに対応するものです。テストの網羅性を高めることで、将来のリグレッションを防ぐことができます。

#123585 Add FileCheck test for elided bounds checks

  • 作成者: @Copilot
  • 作成日時: 2026年01月24日 23:06:54(UTC)
  • マージ日時: 2026年01月26日 18:13:38(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT の範囲チェック省略（Bounds Check Elision）を検証する FileCheck ベースのリグレッション テストを追加しました。マスキング、シフト、文字列長比較、ulong.Log2() などのパターンで、JIT が安全にインデックスアクセスをプルーフでき、CORINFO_HELP_RNGCHKFAIL 呼び出しが完全に削除されることを確認します。

[MethodImpl(MethodImplOptions.NoInlining)]
static byte AndByLength(int i)
{
    // X64-NOT: CORINFO_HELP_RNGCHKFAIL
    ReadOnlySpan<byte> span = new byte[] { 1, 2, 3, 4 };
    return span[i & (span.Length - 1)];  // マスキングで0-3に制限
}

変更内容

  • ElidedBoundsChecks.cs (+94行)

    • ComplexBinaryOperators: ビットマスク・シフト操作で 65 要素 span へのインデックスを 0-63 に制限
    • LastCharCheck: 文字列長比較によるインデックスバウンド検証
    • CountDigits: ulong.Log2() 結果（0-63）で 64 要素 span をインデックス
    • AndByConst: 定数ビットマスク操作
    • AndByLength: (span.Length - 1) パターンのマスキング
    • FileCheck アノテーション X64-NOT / ARM64-NOT で CORINFO_HELP_RNGCHKFAIL 非出現を確認

  • ElidedBoundsChecks.csproj (+18行)

    • HasDisasmCheck=true で disasm ベースの検証を有効化
    • 最適化されたコード生成を強制する環境設定

パフォーマンスへの影響

改善点: 範囲チェック省略により、実行時の不要な例外ハンドラ呼び出しが削除され、配列/span アクセスのオーバーヘッドが削減されます。このテストは、JIT の範囲解析最適化が正しく機能していることを保証し、リグレッション防止に寄与します。

関連 Issue

Issue #123583

その他

  • テスト配置は src/tests/JIT/opt/RangeChecks/ 下で、既存の Subtract テストを参考に設計
  • x64 と ARM64 の両アーキテクチャ対応
  • [MethodImpl(MethodImplOptions.NoInlining)] で JIT 最適化段階での範囲解析を確認

#123582 Use Array.FindAll in ComEventMethods

  • 作成者: @Henr1k80
  • 作成日時: 2026年01月24日 21:44:05(UTC)
  • マージ日時: 2026年01月26日 12:53:32(UTC)
  • ラベル: community-contribution needs-area-label

概要

ComEventMethodsクラスで、オーバーアロケーションを伴うListベースの実装から改善されたArray.FindAllへ切り替え、コード量削減とメモリ効率の向上を実現します。

// 変更前: List でオーバーアロケーション
// 変更後: Array.FindAll で効率的に配列フィルタリング
var methods = Array.FindAll(methodsArray, predicate);

変更内容

  • src/libraries/Common/src/System/Runtime/InteropServices/ComEventsMethod.cs
    • List を使用したフィルタリング処理を Array.FindAll に置き換え
    • コード削減（-3行）、新規追加（+1行）

パフォーマンスへの影響

改善点:

  • Listのオーバーアロケーション回避によるメモリ削減
  • Array.FindAllの改善（#120336）により、より効率的なフィルタリング実装が実現
  • ヒープ圧力の軽減とGC対象となるオブジェクト数の削減

関連Issue

  • #120336（Array.FindAllの改善に関連）

その他

  • COM相互運用の初期化パスに関連する最適化のため、パフォーマンス影響は限定的ながら、メモリ効率は向上

#123569 [RyuJit Wasm] don't home locals if none are referenced

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年01月24日 00:26:55(UTC)
  • マージ日時: 2026年01月26日 16:21:32(UTC)
  • ラベル: arch-wasm area-CodeGen-coreclr

概要

WebAssemblyのJIT コードジェネレーションにおいて、ローカル変数がスタックに配置されない場合、パラメータのホーミング処理をスキップするように最適化しました。スタックポインタレジスタが設定されていない（REG_NA）フレームレス状態では、不要なパラメータのホーミング処理を回避します。

// genHomeRegisterParams内での防御的チェック
if (GetStackPointerReg() == REG_NA)
{
    // スタックポインタが設定されていない場合はホーミングをスキップ
    return;
}

変更内容

  • src/coreclr/jit/codegenwasm.cpp
    • CodeGen::genHomeRegisterParamsメソッドにGetStackPointerReg()チェックを追加
    • スタックポインタがREG_NA（設定されていない）場合、パラメータホーミングをスキップ
    • フレームポインタが使用されていないことをアサートで検証
    • デバッグ用のJITDUMPメッセージを追加

パフォーマンスへの影響

改善あり

  • ローカル変数がスタック上に配置されないケースで、不要なメモリ操作（パラメータホーミング）を削減
  • 特にWebAssemblyレジスタベースの実行モデルにおいて、スタック操作のオーバーヘッドを低減
  • コードサイズ削減による命令キャッシュ効率の向上が期待される

関連Issue

なし

その他

  • WasmプラットフォームのJITコンパイラ最適化
  • アサーション追加によりデバッグ時の検証強化
  • フレームレス（スタックポインタが不要）な関数に対する特定の最適化

#123563 Analyze reaching PHI in GetRangeFromAssertions (more branch foldings)

  • 作成者: @EgorBo
  • 作成日時: 2026年01月23日 20:20:26(UTC)
  • マージ日時: 2026年01月26日 13:01:05(UTC)
  • ラベル: area-CodeGen-coreclr

概要

このPRはJITコンパイラの範囲分析を強化し、PHI定義の到達可能性を分析できるようにします。GetRangeFromAssertionsがPHIノードを再帰的に分析して、より厳密な範囲を計算できるようになり、分岐の削除最適化(branch folding)が向上します。

例えば以下のコードで、x > yは常に偽となるため削除されます：

void Test(bool cond, int[] arr)
{
    int x = cond ? -1 : -2;      // [-2..-1]
    int y = arr?.Length ?? 0;    // [0..Array.MaxLength]

    if (x > y)                   // 常に偽 → 削除される
        Console.WriteLine("below zero");
}

変更内容

  • rangecheck.cpp/h: TryGetRangeFromAssertionsをGetRangeFromAssertionsにリファクタリング（bool+out-parameterから直接Rangeを返却）。PHI分析機能を追加し、到達可能なPHIの全ての引数に対して範囲を計算し統合
  • assertionprop.cpp: optVisitReachingAssertionsをcompiler.hpにテンプレート関数として移動。全ての呼び出し側を新APIに対応
  • compiler.h/hpp: テンプレート関数optVisitReachingAssertionsを.hppに移動し、他のファイルから利用可能に
  • VNF_NEG操作対応: 範囲計算で単項負演算をサポート
  • 再帰深度制限: 無限再帰を防止するため予算(budget)を追加

パフォーマンスへの影響

直接的なパフォーマンス計測値は記載されていませんが、以下の改善が期待されます：

改善点：

  • より厳密な範囲分析によるブランチ削除の増加 → コード生成サイズ削減
  • SSAベースのGetRangeを模倣する設計により、理論上より強力な最適化が可能
  • オーバーフロー処理の分離パスが不要に

懸念点：

  • PHI分析の再帰処理により、複雑なコントロールフローで解析時間が増加する可能性あり
  • 再帰深度制限(budget)により、深いPHIチェーンでは最適化の効果が制限される可能性

関連Issue

PR番号のみで、特定のIssueリンクは記載されていません。

その他

  • SSA表現を必要としないVN(Value Number)とassertionベースのアプローチにより、Global Assertion Propagation等の一般的な最適化から呼び出し可能な設計
  • テンプレート関数をcompiler.hppに移動することで、ヘッダーオンリーライブラリのパターンを採用

#123558 [release/10.0] Update TypeMap attribute handling

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年01月23日 19:35:31(UTC)
  • マージ日時: 2026年01月26日 19:56:04(UTC)
  • ラベル: Servicing-approved area-System.Runtime.InteropServices linkable-framework

概要

.NET 10の新しいSystem.Runtime.InteropServices.TypeMapAttributeを使用して作成されたタイプマップが、PublishTrimmed=trueでアプリケーションを公開する際にアセンブリ間で正常に機能していなかった問題を修正するバックポートです。ILLinkerのTypeMap属性処理を改善し、クロスアセンブリ参照の保存とマーキングの正確性を向上させました。

変更内容

ファイル 変更内容
TypeMapHandler.cs TypeMapハンドラーロジックの拡張。参照アセンブリ間のTypeMap属性処理を強化し、第2段階の参照(二次参照)の適切なマーキングと保存を実装
MarkStep.cs TypeMapハンドラーの呼び出し条件を最適化。不要な処理を削減し、より効率的なマーキング戦略に改善
SweepStep.cs 軽微な修正。TypeMap関連の整理処理を調整
DependencyInfo.cs 依存関係情報の構造を1行追加で拡張
TypeReferenceEqualityComparer.cs 型参照の等値比較ロジックを3行追加で改善
テストケース TypeMap機能の包括的なテストを追加。単一アセンブリ参照と二次参照の両シナリオをカバー

パフォーマンスへの影響

影響なし。この修正はトリミング処理の正確性を向上させるもので、パフォーマンス特性に直接的な変更はありません。むしろトリミング時の過度な削除を防ぐことで、実行時の安定性を向上させます。

関連Issue

#120477（このPRのバックポート元）

その他

  • 対象バージョン: .NET 10 release/10.0ブランチへのバックポート
  • 影響範囲: 新API仕様のため、既存コードへの破壊的変更なし
  • リスク評価: Low。新APIのみに限定された修正であり、包括的なユニットテストが含まれています
  • ユースケース: .NET for Android、CsWinRTなどのパートナーチーム向けAPIの品質向上
  • テスト: 多数のユニットテストが追加されており、クロスアセンブリシナリオが検証されています

#123517 [release/10.0] Fix hash collision in TypeMapLazyDictionary causing non-deterministic ArgumentException

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年01月22日 23:42:05(UTC)
  • マージ日時: 2026年01月26日 19:55:35(UTC)
  • ラベル: Servicing-approved area-System.Runtime.InteropServices

概要

TypeMapLazyDictionaryでハッシュコリジョンが発生し、ArgumentExceptionが非決定的に発生する問題を修正しました。複数のTypeMapAssociationAttributeが存在する場合、異なる文字列が同じハッシュコードを生成することがありました。修正前はハッシュコード値を直接辞書のキーとして使用していたため、コリジョン時の衝突処理ができていませんでした。修正後は文字列そのものをキーとして使用することで、確実にコリジョンを回避できるようにしました。

変更内容

  • src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/TypeMapLazyDictionary.cs
    • ハッシュコード（int）をキーとしていたDictionary<int, ...>から、文字列（string）をキーとするDictionary<string, ...>に変更
    • コリジョン対策として、直接的なハッシュ値の使用を廃止し、文字列自体を辞書キーとして使用

パフォーマンスへの影響

  • メモリ使用量: coreclr環境では、文字列参照をキーとして保持するため、ハッシュコード値のみを保持する場合と比較してメモリ使用量が増加します
  • 実行速度: ハッシュコード比較から文字列比較による検索に変更されるため、若干のオーバーヘッドが予想されますが、正確性が優先されます
  • native AOT: P1シナリオであるnative AOT環境への影響はありません
  • 信頼性向上: テスト結果では、修正前は100回実行中1回の頻度でコリジョンが発生していましたが、修正後は1000回以上の連続実行でコリジョンが発生しなくなりました

関連Issue

  • 親Issue: #123502（release/main への修正）
  • CsWinRTの再現ケースで検証済み

その他

  • リスク評価: 低リスク。メモリ増加は受容可能と判断され、native AOT（TypeMapの主要シナリオ）は影響を受けません
  • 顧客報告: 本修正は顧客報告の問題に対応しています

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月22日 19:48:01(UTC)
  • マージ日時: 2026年01月26日 20:01:03(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPull Requestは、dotnet/dotnetリポジトリからdotnet/runtimeへのコードフロー更新です。2026年1月23日時点のビルド(20260123.10)から、複数の依存パッケージがアップデートされています。主にCodeAnalysis関連のツール、ビルドタスク、NuGet関連パッケージ、WebAssembly Node Transport関連のランタイムパッケージが更新されています。

変更内容

  • NuGet.config: フィード設定の軽微な変更（+1/-1行）
  • eng/Version.Details.props: バージョン定義ファイルの更新（+37/-37行）
  • eng/Version.Details.xml: 詳細なバージョン情報の更新（+85/-85行）
  • global.json: グローバル設定ファイルの更新（+3/-3行）

主な依存パッケージ更新:

  • Microsoft.CodeAnalysis系: 5.0.0-2.26071.116 → 5.0.0-2.26073.110
  • Microsoft.DotNet.Arcade.Sdk他ビルドタスク系: 10.0.0-beta.26071.116 → 10.0.0-beta.26073.110
  • NuGet.Frameworks/Packaging/ProjectModel/Versioning: 7.0.2-rc.7216 → 7.0.2-rc.7410
  • WebAssembly Node Transport（複数プラットフォーム対応）

パフォーマンスへの影響

影響なし

このコードフロー更新は主に依存パッケージのバージョン管理と設定ファイルの同期を目的としており、ランタイムパフォーマンスに直接的な影響を与えません。

関連Issue

なし

その他

  • 変更タイプ: Codeflow PR（自動化されたVMR同期プロセス）
  • 関連リポジトリ: efcore、runtime、source-build-reference-packages、winformsの複数リポジトリから同期
  • ターゲットブランチ: release/10.0.1xx
  • 依存パッケージ: 合計20以上のパッケージが更新されており、ビルドツールチェーン全体の保守・更新が行われています

#123462 [release/8.0] Change pool for evaluate-paths

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年01月21日 23:47:12(UTC)
  • マージ日時: 2026年01月26日 20:12:43(UTC)
  • ラベル: Servicing-approved area-Infrastructure

概要

このPRは、#123450のバックポート版で、release/8.0ブランチに対するCI/CDパイプラインの変更です。評価パス用（evaluate-paths）のジョブで使用されるプールを変更する修正を含んでいます。これはビルドインフラストラクチャの改善に関連し、パイプラインの実行環境を最適化する変更と考えられます。

変更内容

  • eng/pipelines/common/evaluate-paths-job.yml
    • ジョブのプール設定を変更（+7行、-1行）
    • evaluate-pathsジョブで使用されるビルドエージェントプールの構成を修正

パフォーマンスへの影響

パイプラインの実行効率に関連する可能性がありますが、提供された情報からは具体的な数値や詳細なパフォーマンス測定結果は記載されていません。ジョブのプール変更により、パイプライン全体のスループットやリソース利用率に改善をもたらす可能性があります。

関連Issue

#123450（上流のPR）

その他

  • このPRは自動で生成されたバックポート（github-actions[bot]が作成者）
  • release/8.0-stagingブランチへのバックポートであり、.NET 8のサービシングリリースに含まれる変更
  • テンプレート上、顧客への影響度、回帰テスト、リスク評価などの詳細は本PR内では未記入の状態

#123319 Add performance-benchmark skill for ad hoc benchmarking with EgorBot

  • 作成者: @Copilot
  • 作成日時: 2026年01月17日 22:29:50(UTC)
  • マージ日時: 2026年01月26日 18:22:45(UTC)
  • ラベル: area-Infrastructure

概要

EgorBotを使用したアドホックなパフォーマンスベンチマーク実行を可能にするCopilotスキルを追加しました。このスキルにより、開発者はPRコメント経由でBenchmarkDotNetベンチマークを自動生成・実行でき、パフォーマンス検証が容易になります。

@EgorBot -x64 -arm -profiler --envvars DOTNET_JitDisasm:SumArray

[Benchmark]
public int SumArray() => _data.Sum();

変更内容

  • .github/skills/performance-benchmark/SKILL.md (+254行)
    • BenchmarkDotNetベストプラクティスガイドの追加
    • マイクロベンチマーク設計ガイドラインへの準拠方法
    • EgorBotトリガーコマンドの形式と使用例
    • アーキテクチャ別ターゲット選択ガイド（x64、ARM、Windows_x64など）
    • JIT逆アセンブリ、プロファイリング、環境変数設定オプション

パフォーマンスへの影響

影響なし。本PRはスキル定義ドキュメント追加のみであり、ランタイム実行に直接的な影響はありません。

関連Issue

なし

その他

  • Copilotスキルの追加により、手作業でのベンチマーク記述の負担が軽減されます
  • [GlobalSetup]の活用、デッドコード排除対策など、ベストプラクティスが自動適用される設計です
  • EgorBotとの連携により、複数アーキテクチャでの一括検証が可能になります
  • JCC Erratum対応として、Intelプラットフォームの信頼性注記あり

#123313 Fix Base64.DecodeFromUtf8 consuming whitespace in partial final quantum when isFinalBlock=false

  • 作成者: @Copilot
  • 作成日時: 2026年01月17日 17:49:28(UTC)
  • マージ日時: 2026年01月26日 13:20:19(UTC)
  • ラベル: area-System.Memory

概要

Base64.DecodeFromUtf8()で最終量子（パディング=を含む）がホワイトスペースで分割されており、かつisFinalBlock=falseの場合、ホワイトスペースが誤って消費される問題を修正しました。ストリーミングデコーダーがより多くのデータを受け取った後にisFinalBlock=trueで再試行する際の回復を可能にします。

// 修正前: bytesConsumed=2で復帰不可
Base64.DecodeFromUtf8("AQ\r\nQ="u8, output, out int consumed, out _, isFinalBlock: false);
// consumed=2だが"Q="スライスは無効

// 修正後: bytesConsumed=0で再試行可能
Base64.DecodeFromUtf8("AQ\r\nQ="u8, output, out int consumed, out _, isFinalBlock: false);
Base64.DecodeFromUtf8("AQ\r\nQ="u8, output, out _, out _, isFinalBlock: true); // 成功

変更内容

  • Base64DecoderHelper.cs: DecodeWithWhiteSpaceBlockwiseメソッドの両方のオーバーロード（byte/ushort）を修正。bytesConsumed += skippedの更新をデコード試行前から成功後に移動。デコード失敗時はbytesConsumedを更新せず返却。デバッグアサーションを追加して、失敗時にlocalConsumedとlocalWrittenが両方0であることを検証。

  • Base64DecoderUnitTests.cs: ホワイトスペース分割された最終量子の包括的なテストカバレッジを追加。CRLF、スペース、タブなど複数のホワイトスペースパターンと、複数の完全ブロック後の最終量子分割シナリオをカバー。

パフォーマンスへの影響

影響なし。変更は失敗パスのみ対象で、最小限の修正です。既存テストは全て合格。

関連Issue

dotnet/runtime#123311、dotnet/runtime#123313

その他

  • 低リスク修正。テストは100バイトバッファを使用（#123222対応）
  • DecodeFromUtf8とDecodeFromCharsの両方のデコーダーテストを追加
  • デバッグアサーションでコントラクト維持を保証
  • ストリーミング基本64デコーダー（HTTPレスポンスハンドラー、ファイルパーサー等）の動作改善

#122947 Optimize Directory.GetFiles by passing safe patterns to NtQueryDirectoryFile

  • 作成者: @Copilot
  • 作成日時: 2026年01月06日 23:33:00(UTC)
  • マージ日時: 2026年01月26日 19:12:03(UTC)
  • ラベル: area-System.IO

概要

Windows上のDirectory.GetFilesのパフォーマンスを最適化するPRです。従来は検索パターンに関わらず全ファイルを列挙していたため、大規模ディレクトリでO(N)の処理になっていました。本変更では「安全な」パターンをOS（NtQueryDirectoryFile）のプリフィルタとして渡すことで、O(log N)相当の高速化を実現します。マネージド側のMatchesPatternフィルタは継続して実行し、100%の正確性を保証します。

例：140,000ファイルのディレクトリでA14881*.jpgを検索時、従来は全ファイル列挙、最適化後は数個～数十個に削減。

変更内容

  • FileSystemEnumerator.Windows.cs: OS判定メソッドIsSafePatternForOSFilter()追加。*と有効な文字のみのパターン（*.jpg、prefix*など）を識別。?、*.*、*.終了パターン、無効な文字を含むパターンは除外
  • FileSystemEnumerable.cs: 検索パターンをFileSystemEnumeratorに引き継ぎ
  • FileSystemEnumerableFactory.cs: パターン引き渡し処理の追加
  • FileSystemEnumerator.Unix.cs: Unix互換性コード追加
  • MatchCasingTests.cs/MatchTypesTests.cs: パターンマッチング包括テスト（DOS_QMのコラプス動作など対応）

パフォーマンスへの影響

改善点：

  • 安全パターンでOS側プリフィルタが機能し、返却エントリ数を大幅削減（例：140,000 → 数個～数十個）
  • NTFS B-treeシーク機能を活用、実質O(log N)相当に改善

懸念点：

  • 制御文字、"、<>、|、:、\、/などの無効な文字を含むパターンは従来と同じく未最適化
  • Windowsのみの最適化で、最初のNtQueryDirectoryFile呼び出しに限定

関連Issue

Issue #56464 - .NET Core/5+でのDirectory.GetFilesのパフォーマンス低下

その他

リスク評価：低。最適化はOS側ヒント扱い。マネージド側フィルタが全結果を必ず検証するため、不正な結果の混入は防止。497個のGetFilesテスト、70個の列挙テスト、130個のFileSystemNameテストすべてパス。Windows/Unix両プラットフォームで検証完了。

#122651 Emit task returning thunks in crossgen2

  • 作成者: @jtschuster
  • 作成日時: 2025年12月18日 20:58:08(UTC)
  • マージ日時: 2026年01月26日 21:44:06(UTC)
  • ラベル: area-crossgen2-coreclr runtime-async

概要

crossgen2においてTask返却型の非同期メソッドのthunkをMethodSignatureとして出力するようになりました。AsyncVariantフラグを設定することで、ランタイムが非同期メソッドの継続パラメータを正しく処理できるようになります。同時に、GCRefMapの生成ロジックと例外ハンドリング情報が継続パラメータに対応するよう更新されました。

変更内容

  • AsyncMethodVariant.cs: 新規作成。AsyncVariantフラグ関連の定義
  • MethodDescExtensions.cs: GetPrimaryMethodDescメソッドを追加。インスタンス化されたメソッドの正規メソッド記述子を取得
  • GCRefMapBuilder.cs: 継続パラメータを考慮したGCRefMap生成ロジック更新
  • ArgIterator.cs: 継続パラメータハンドリング機能を大幅拡張
  • EHInfo.cs: R2R例外情報節にSystem.Exception専用フラグを追加
  • ReadyToRunILProvider.cs: ManifestModuleWrappedMethodILによるトークン解決メカニズムを実装（122行追加）
  • ILStubReferences.cs: 不要なコード削除（373行削除）
  • CorInfoImpl.ReadyToRun.cs: 例外ハンドリングロジック更新

パフォーマンスへの影響

影響なし。本変更は機能実装であり、パフォーマンスに直接的な改善・劣化は想定されていません。ただし、ReadyToRun画像生成時の処理が複雑化しているため、コンパイル時間への軽微な影響の可能性があります。

関連Issue

なし

その他

  • 互換性: R2R画像フォーマットが変更される破壊的変更となる可能性があります
  • 検証機能: FakeGcScanRoots（デバッグ構成でReadyToRun画像のGCRefMapを検証）を継続パラメータに対応させました
  • トークン解決の複雑性: インスタンス化型の呼び出しではトークン参照の保証がないため、ManifestModuleWrappedMethodILでトークンをフォールバック処理する設計となっています

#122116 Reduce unsafe usage in TextInfo.cs

  • 作成者: @GrabYourPitchforks
  • 作成日時: 2025年12月02日 20:50:52(UTC)
  • マージ日時: 2026年01月26日 18:20:47(UTC)
  • ラベル: area-System.Globalization reduce-unsafe

概要

TextInfo.csのToLowerAsciiInvariant(string)メソッドから unsafe コードを除去し、モダンな C# パターンに置き換えました。このメソッドはカルチャー名（"aa-BB" など短い文字列）のキャッシング用に使用され、ホットコードパスではないため、安全性を優先した設計に変更されています。

変更内容

src/libraries/System.Private.CoreLib/src/System/Globalization/TextInfo.cs

  • ToLowerAsciiInvariant(string) メソッドから unsafe 修飾子を削除
  • ポインタベースの操作（fixed、FastAllocateString）を string.Create API に置き換え
  • Span ベースの反復処理（foreach (ref char c in span)）で実装を簡素化
  • 変更行数：+11/-17（コード行削減）

パフォーマンスへの影響

影響なし。本メソッドはホットコードパスではなく、非常に小さな文字列（典型的に "aa-BB" 形式）の処理が対象のため、string.Create による実装でも十分な性能を維持できます。

関連Issue

関連する Issue に関する情報はありません。

その他

  • このメソッドは CultureInfo コンストラクタ経由で CultureData.cs から呼び出されることが唯一の使用箇所です
  • unsafe コードの削減により、メモリセーフティが向上し、保守性が改善されます
  • string.Create を使用することで、.NET における現代的なパターンへの準拠が実現されています

#117148 FileSystemWatcher.Linux: use a single inotify instance and refactor watch tracking.

  • 作成者: @tmds
  • 作成日時: 2025年06月30日 14:42:38(UTC)
  • マージ日時: 2026年01月26日 11:58:16(UTC)
  • ラベル: area-System.IO community-contribution

概要

Linux上のFileSystemWatcherを複数インスタンス間で単一のinotifyインスタンスを共有する設計に変更しました。Linuxではユーザーあたり128個のinotify制限があるため、この共有化により他のアプリケーションとの競合を削減します。対応Issue: #62869

変更内容

  • FileSystemWatcher.Linux.cs: 新しいアーキテクチャの実装（INotify、Watcher、WatchedDirectory、Watchクラスを追加）。共有inotifyインスタンス、専用スレッドでのイベント読み取り、Channel ベースのキューイング処理を導入（+1089行）
  • Interop.INotify.cs: IN_MASK_ADD フラグサポートの追加（複数ウォッチャー間でのinotify共有に必要）
  • System.IO.FileSystem.Watcher.csproj: 非Windows プラットフォーム向けに System.Collections.Concurrent と System.Threading.Channels への依存関係を追加
  • FileSystemWatcher.cs: CreateBufferOverflowException メソッドの抽出（Linux実装で再利用）

パフォーマンスへの影響

  • 改善点: inotify インスタンスの共有によりシステムリソース消費を削減。複数FileSystemWatcherオブジェクトの運用時にinotify資源の競合を緩和
  • アーキテクチャ: 専用スレッドでinotifyイベントを読み取り、ThreadPool経由でイベントハンドラーを呼び出すことにより、読み取り処理のブロッキングを防止

関連Issue

#62869

その他

大規模なリファクタリングで、FileSystemWatcher.Linux.csの実装行数が671行から1760行に増加しています。新しい内部クラス群により、ウォッチ管理とパス・ウォッチディスクリプタ間の関係管理が改善されています。

目次