Pull Request on 2026年03月12日

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

注意点

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

#125474 Add tests for lazy quantifier inside optional group

  • 作成者: @stephentoub
  • 作成日時: 2026年03月12日 02:53:14(UTC)
  • マージ日時: 2026年03月12日 23:09:36(UTC)
  • ラベル: area-System.Text.RegularExpressions

概要

正規表現パターン a(b.*?c)?d のテストケースを追加し、#124254での修正が#125321で報告されたリグレッション（オプショナルグループ内の遅延量指定子が正しくマッチしない問題）を解決したことを確認します。

変更内容

  • src/libraries/System.Text.RegularExpressions/tests/FunctionalTests/Regex.Match.Tests.cs
    • Match_MemberData_Cases テストデータプロバイダーに4つのテストケースを追加
      • 遅延拡張: abccd — 遅延量指定子 .*? が最初の c を越えて拡張され、d がマッチ
      • 遅延ゼロ幅: abcd — 遅延量指定子 .*? が何もマッチせず、c と d が直後に続く
      • オプショナルグループをスキップ: ad — グループ (b.*?c)? 全体がバイパスされる
      • マッチなし: abce — d がないため正しくマッチ失敗

パフォーマンスへの影響

影響なし

関連Issue

#125321、#124254

その他

このPRはテストケースの追加であり、ランタイムやコンパイラの実装変更は含みません。リグレッション修正の検証が主な目的です。

#125465 [release/10.0] Avoid C4319 build warnings in libunwind

  • 作成者: @steveisok
  • 作成日時: 2026年03月11日 23:11:55(UTC)
  • マージ日時: 2026年03月12日 13:06:57(UTC)
  • ラベル: Servicing-approved area-Infrastructure

概要

MSVC 19.44.35221でのC4319警告（ゼロ拡張による型警告）をlibunwindで解決するバックポート。UNW_ALIGNマクロに(size_t)キャストを追加し、/WX（警告をエラーとして扱う）オプションでのコンパイルエラーを回避します。

変更内容

  • src/native/external/libunwind/include/libunwind_i.h: UNW_ALIGNマクロのオペランドに(size_t)キャストを追加
  • src/native/external/libunwind-version.txt: libunwindバージョン情報を更新（libunwind#931のアップストリーム修正を取り込み）

パフォーマンスへの影響

影響なし

関連Issue

#123535（main）、#122179（release/9.0）

その他

  • 修正対象: release/10.0への後方移植
  • 修正内容は既にrelease/9.0とmainで検証済み
  • リスク評価: 低（キャストのみの変更）
  • 影響範囲: Windows上のクロスOS DAC build（libunwind）に限定

#125444 Fix crossgen2 crash on Apple mobile for InstantiatedType token resolution in async methods

  • 作成者: @kotlarmilos
  • 作成日時: 2026年03月11日 14:15:27(UTC)
  • マージ日時: 2026年03月12日 09:38:20(UTC)
  • ラベル: area-crossgen2-coreclr os-ios runtime-async

概要

crossgen2がApple mobileプラットフォーム上で非同期メソッド内のジェネリック型インスタンス化（例：CallStruct1M0<T>）を参照する際に、InstantiatedTypeトークン解決が未対応でNotImplementedExceptionをスローするリグレッションを修正します。#124203で導入された問題への対応です。

変更内容

  • src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs
    • HandleToModuleToken内のGetModuleTokenForTypeローカル関数にInstantiatedTypeケースを追加
    • 合成メソッド本体のトークン再マッピング時に_compilation.NodeFactory.Resolver経由でモジュールトークン解決を実行

パフォーマンスへの影響

影響なし

関連Issue

#124203（リグレッション原因となったPR）

その他

本修正により、SignatureMethodVariable、ParameterizedType、EcmaTypeに加えてInstantiatedTypeがサポートされます。影響を受けたビルド対象：

  • iossimulator-arm64 Release AllSubsets_CoreCLR_RuntimeTests
  • iossimulator-x64 Release AllSubsets_CoreCLR_RuntimeTests
  • tvossimulator-arm64 Release AllSubsets_CoreCLR_RuntimeTests

#125429 [browser][CoreCLR] startup helpers cleanup

  • 作成者: @pavelsavara
  • 作成日時: 2026年03月11日 09:04:24(UTC)
  • マージ日時: 2026年03月12日 12:23:24(UTC)
  • ラベル: arch-wasm area-Host os-browser

概要

WebAssembly/ブラウザでのランタイム起動フローをリファクタリングし、可読性を向上させるものです。リソース集合の反復処理を簡潔にするヘルパー関数（forEachResource/normalizeCollection）を導入し、ライブラリ初期化ロジック（onRuntimeConfigLoaded/onRuntimeReady）をassets.tsに集約しました。

変更内容

  • src/native/libs/Common/JavaScript/loader/run.ts: ランタイム作成フローをリファクタリング。オプショナルなリソース処理用のヘルパー関数を導入し、ライブラリ初期化呼び出しを再配線。
  • src/native/libs/Common/JavaScript/loader/assets.ts: ライブラリ初期化フックを設定読み込み完了フェーズとランタイム準備完了フェーズで呼び出すためのヘルパー関数をエクスポート。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

本変更は内部実装（JavaScript/TypeScriptのローダー処理）の整理であり、公開APIへの影響はありません。

#125428 arm64: Fix and/bic issue when bailing early

  • 作成者: @jonathandavies-arm
  • 作成日時: 2026年03月11日 07:51:21(UTC)
  • マージ日時: 2026年03月12日 05:03:12(UTC)
  • ラベル: area-CodeGen-coreclr community-contribution

概要

ARM64アーキテクチャにおいて、and/bic命令の早期バイアウト時の問題を修正しています。JITコンパイラの下位レベル（lower）処理で、特定の条件下での命令生成ロジックが改善されました。

変更内容

  • src/coreclr/jit/lower.cpp: and/bic命令生成時の早期バイアウト処理を修正（16行追加、10行削除）
  • src/tests/JIT/Regression/JitBlue/Runtime_125327/Runtime_125327.cs: 回帰テストケースを新規追加（66行）
  • src/tests/JIT/Regression/Regression_ro_1.csproj: テストプロジェクト設定を更新（1行追加）

パフォーマンスへの影響

影響なし（バグ修正のため、正確な命令生成による動作確保が主目的）

関連Issue

#125327

その他

ARM64ランタイム専用の修正です。JITコンパイラの内部実装（lower層）に関わる変更であり、公開APIへの影響はありません。

#125425 fix #125301 (NOL bug for partial loads/stores)

  • 作成者: @EgorBo
  • 作成日時: 2026年03月11日 04:06:40(UTC)
  • マージ日時: 2026年03月12日 01:32:00(UTC)
  • ラベル: area-CodeGen-coreclr

概要

Issue #125301のNOL（Normalize-On-Load）バグを修正します。小型ローカル変数（shortなど）がアドレスベースのアクセスで部分的に定義される場合、不正な上位ビット状態を防ぐため、該当ローカル変数をアドレス公開してnormalize-on-loadさせるようにしました。

変更内容

  • src/coreclr/jit/morph.cpp: 間接参照の最適化時に部分定義が検出された場合、小型ローカルをアドレス公開にマークする処理を追加
  • src/coreclr/jit/lclmorph.cpp: ローカル変数アドレス訪問時に部分定義に対する同じアドレス公開ルールを適用
  • src/coreclr/jit/compiler.h: 新しいデバッグ理由と対応する登録統計カウンターを追加
  • src/coreclr/jit/compiler.cpp: 新しい登録統計カウンターの記録・ダンプ機能を追加
  • src/tests/JIT/Regression/JitBlue/Runtime_125301/Runtime_125301.cs: shortの周辺でのバイト単位の部分アクセスをカバーするリグレッション テストを追加
  • src/tests/JIT/Regression/Regression_ro_2.csproj: テストプロジェクトに新しいリグレッション テスト ソースファイルを追加

パフォーマンスへの影響

影響なし。このPRはバグ修正であり、小型ローカル変数の不正な値の生成を防ぐ正確性の修正です。

関連Issue

#125301

その他

なし

#125420 Enable devirtualization of async methods in crossgen2

  • 作成者: @jtschuster
  • 作成日時: 2026年03月10日 22:51:36(UTC)
  • マージ日時: 2026年03月12日 01:13:43(UTC)
  • ラベル: area-crossgen2-coreclr

概要

Crossgen2（ReadyToRun コンパイラ）での非同期仮想メソッドの非仮想化を有効にするPRです。従来の MetadataVirtualMethodAlgorithm では非同期メソッドの変種が考慮されていなかったため、R2R コンパイル時に非同期仮想メソッドの非仮想化ができませんでした。AsyncAwareVirtualMethodResolutionAlgorithm に切り替え、ILC の動作と統一します。

インターフェース経由のディスパッチでは、修正前は VIRTUAL_ENTRY による間接ディスパッチが発行されていましたが、修正後は非同期メソッドの変種を解決して直接呼び出しに最適化されます。

変更内容

  • ReadyToRunCompilerContext.cs: 仮想メソッド解決アルゴリズムを MetadataVirtualMethodAlgorithm から AsyncAwareVirtualMethodResolutionAlgorithm に変更（内部実装の変更）
  • CompilerTypeSystemContext.cs: 共通部分への minor 変更
  • CompilerTypeSystemContext.Aot.cs: 既存コードの整理
  • 非同期デバイトライザーテスト追加: シールドクラス仮想ディスパッチ、シールドインターフェース ディスパッチ、ジェネリック制約付きディスパッチなど複数の非同期仮想メソッド呼び出しシナリオをテスト

パフォーマンスへの影響

改善により、対象となる非同期仮想メソッドの呼び出しが間接ディスパッチから直接呼び出しに最適化されるため、呼び出しオーバーヘッドが削減されます（特にインターフェース経由のディスパッチで顕著）。その他の呼び出しはランタイム ディスパッチを必要とします。

関連Issue

#124620

その他

なし

#125413 Prepare for xunit.v3.assert migration: forward-compatibility changes

  • 作成者: @Copilot
  • 作成日時: 2026年03月10日 21:27:14(UTC)
  • マージ日時: 2026年03月12日 22:49:46(UTC)
  • ラベル: area-Infrastructure linkable-framework

概要

xUnit v3への将来的な移行に向けた前方互換性の改善です。EqualException.ForMismatchedValues()の呼び出しをすべてstring引数に統一し、xUnit v3では文字列引数のみをサポートする仕様に対応させました。また、xUnit v3固有のxUnit1051アナライザ警告を抑制する設定を追加しました。実際のパッケージ切り替えは行われていません。

変更内容

  • EqualException.ForMismatchedValues()の文字列変換: 複数のテストファイル（System.Runtime、System.Numerics.Tensors、System.Runtime.Numerics、System.Runtime.InteropServices、System.Globalization、Microsoft.Extensions.Logging、ICollectionTest、Wasm.Build.Tests）で、object型の引数をstring型に変換しました。
  • xUnit1051アナライザ抑制: .editorconfig、eng/testing/xunit/xunit.props、src/tests/Directory.Build.propsにxUnit1051警告の抑制設定を追加しました。この警告はv3パターンのTestContext.Current.CancellationToken使用を推奨するため、完全な移行まで抑制します。
  • GroupCollectionTests2.csの修正: Assert.Equal(col, items)をAssert.Equal(col.Cast<Group>(), items)に変更し、xUnit v3のコレクション比較動作と互換性を持たせました。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このPRは移行準備段階であり、現在のMicrosoft.DotNet.XUnitAssert/xunit.assertパッケージとの互換性を保ちながら、xUnit v3へのスムーズな移行基盤を構築しています。19ファイルの変更はすべてテストコードに限定されており、本体コードへの影響はありません。

#125407 Fix race condition leak in RegisterResumptionStub

  • 作成者: @jtschuster
  • 作成日時: 2026年03月10日 21:01:42(UTC)
  • マージ日時: 2026年03月12日 23:21:43(UTC)
  • ラベル: area-VM-coreclr

概要

RegisterResumptionStub内のレース条件によるメモリリークを修正しました。複数スレッドが同時にMethodDescを割り当てた場合、敗者のスレッドが割り当てたメモリが解放されずにリークしていました。SuppressRelease()呼び出しを挿入成功後に移動し、条件付きにすることで、敗者のAllocMemTrackerが確実にメモリを回収できるようにしました。

変更内容

  • src/coreclr/vm/readytoruninfo.cpp: SetMethodDescForEntryPointInNativeImage()呼び出しの後にSuppressRelease()を移動。挿入成功時のみSuppressRelease()を実行。
  • src/coreclr/vm/readytoruninfo.h: SetMethodDescForEntryPointInNativeImage()の戻り値をboolに変更（挿入成功時はtrue、既存エントリがある場合はfalse）

パフォーマンスへの影響

影響なし（リークしたメモリを回収できるようになるため、長期的なメモリ効率が向上）

関連Issue

#125407

その他

この変更はランタイムの内部実装（ReadyToRun情報管理）に関するもので、公開APIには影響しません。

#125389 ref struct ASN.1 Decoder type generation

  • 作成者: @vcsjones
  • 作成日時: 2026年03月10日 15:44:58(UTC)
  • マージ日時: 2026年03月12日 01:29:27(UTC)
  • ラベル: area-System.Security

概要

ASN.1デコーダの型生成システムを拡張し、ref structベースのスパン指向デコーダ（Value*型）を既存のstructデコーダと並行して生成できるようにしました。これにより、PointerMemoryManagerの使用を廃止し、メモリ安全性を向上させます。XSLT生成ツールにemitType属性を追加し、struct/ref struct/両方の生成を制御できるようになりました。PublicKeyとCertificateRequestの実装をこの新しいValue*デコーダに移行し、実装の有効性を実証しています。

変更内容

  • asn.xslt/asn.xsd: emitType（生成対象の指定）、valueTypeName（ref struct型での入れ子型マッピング）、valueName（列挙子の命名）属性を追加。ref struct向けのスパンベースデコード実装とレイジーコレクション列挙子生成ロジックを追加
  • Shared*ヘルパークラス: デフォルトDER初期化定数をfileスコープの共有ヘルパー（例：SharedSubjectPublicKeyInfoAsn）に抽出し、struct/ref struct両型で共用してコード重複を削減
  • Value*型の生成: ValueSubjectPublicKeyInfoAsn、ValueCertificationRequestInfoAsnなど、ReadOnlySpan<byte>フィールドを持つref struct型を新規生成
  • オプション型対応: ReadOnlySpan<byte>はNullable<T>化できないため、オプションフィールドに対応するHasプレフィックス付きbool型フィールド（例：HasParameters）を追加
  • コレクション処理: GetAttributes()のようなGet<Name>()メソッドにより、ref struct列挙子を返すことで遅延デコードを実現
  • PublicKey.cs: SubjectPublicKeyInfoAsnからValueSubjectPublicKeyInfoAsnに移行し、PointerMemoryManager使用を廃止
  • CertificateRequest.Load.cs: PKCS#10パース処理をValue*デコーダに切り替え、属性値の遅延列挙に対応

パフォーマンスへの影響

  • メモリ効率: PointerMemoryManager廃止により、アンセーフメモリ操作が排除。スパンベースのアプローチでスタックメモリを活用
  • ソースコード/アセンブリサイズ削減: デフォルトDER初期化を共有ヘルパーに統合し、struct/ref struct両型で重複排除
  • 遅延デコード: コレクション要素は列挙時にオンザフライでデコード（eager decodeとの動作差）。デコード例外はDecode呼び出し時でなく列挙時に発生
  • 具体的なベンチマーク数値は提供されていません

関連Issue

なし

その他

  • 内部実装変更: 生成されたコード内のref struct列挙子における定義確実割り当てエラーの可能性（コンパイル時の問題として指摘）
  • Encode非対応: 今回のPRではDecode機能のみ実装。Encode機能は将来の追加で検討
  • ヘルパーメソッド重複: `ValuePssParamsAs

#125360 Fix clang -Walloc-size error in CloseHandle test by removing unused WriteBuffer

  • 作成者: @Copilot
  • 作成日時: 2026年03月10日 03:24:54(UTC)
  • マージ日時: 2026年03月12日 23:13:17(UTC)
  • ラベル: area-PAL-coreclr

概要

PALテストスイートのCloseHandleテストで、未使用で不正なサイズ割り当てをしていたWriteBuffer変数を削除しました。WriteBufferはLPDWORD（4バイト）型でしたが、malloc(sizeof(WORD))で2バイトしか割り当てられておらず、実際には使用されていなかったため、新しいclangの-Walloc-sizeエラーチェックで検出されていました。

変更内容

  • src/coreclr/pal/tests/palsuite/miscellaneous/CloseHandle/test1/test.cpp:
    • 未使用のWriteBuffer変数とそのmalloc、null-check、free呼び出しを完全に削除
    • 依存関係コメントを「/* Depends on: CreateFile and WriteFile */」から「/* Depends on: CreateFile */」に更新（WriteFileは実際に呼び出されていなかった）

パフォーマンスへの影響

影響なし（不要なメモリ割り当てと解放コードの削除により、テスト実行時の軽微な改善の可能性あり）

関連Issue

なし

その他

このPRは原因を正しく特定しました。初期の推奨（sizeof(WORD)をsizeof(DWORD)に変更）ではなく、実装者は変数が完全に未使用であることに気付き、より優れたソリューションとしてコード全体を削除しました。ビルドシステムがclangの-Werrorフラグで強制される厳密な型チェックに対応しています。

#125353 Sync cDAC's RV64/LA64 implementations with ARM64

  • 作成者: @am11
  • 作成日時: 2026年03月09日 23:16:25(UTC)
  • マージ日時: 2026年03月12日 20:33:26(UTC)
  • ラベル: area-Diagnostics-coreclr community-contribution arch-loongarch64 arch-riscv

概要

RV64（RISC-V 64）およびLA64（LoongArch 64）アーキテクチャのcDAC（Compact DAC）実装をARM64の実装と同期させ、GCInfo処理、スタックウォーク、アンワインド機能を拡張するPullRequestです。両アーキテクチャのデバッグ・診断機能を強化し、ARM64と同等のサポートレベルを提供します。

変更内容

  • UnwindDataSize.cs: RV64/LA64向けのアンワインドデータサイズ計算をARM64仕様と同期
  • GCInfoFactory.cs・GCInfoTraits: RV64/LA64専用のGCInfo特性クラスを新規追加（PlatformTraits/RISCV64GCInfoTraits.cs、LoongArch64GCInfoTraits.cs）
  • Unwinder実装: RISCV64Unwinder.cs（+172行）およびLoongArch64Unwinder.cs（+163行）を大幅拡張し、完全なアンワインド機能を実装
  • RISCV64FrameHandler.cs: フレーム処理ロジックを新規追加
  • IPlatformAgnosticContext.cs: プラットフォーム共通インターフェースに1行追加
  • dacdbiimpl.cpp: DAC側でRV64/LA64対応サポートを追加
  • テスト関連: GetRegisterNameTests.cs、RuntimeInfoDumpTests.cs、DumpInfo.csにテストケース追加

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

本変更はcDAC（Compact Data Access Component）の診断機能強化で、RV64およびLA64アーキテクチャのデバッグ体験をARM64レベルまで向上させるものです。ダンプ解析やレジスタ名取得など、診断インフラストラクチャ側の内部実装の拡張であり、公開APIへの影響はありません。

#125326 Convert some COM interop to UCO

  • 作成者: @am11
  • 作成日時: 2026年03月09日 11:37:27(UTC)
  • マージ日時: 2026年03月12日 16:00:45(UTC)
  • ラベル: area-VM-coreclr community-contribution

概要

COM相互運用性の機能をUnmanaged Callable Object (UCO)に段階的に変換するプロジェクト(#123864のグループ5の一部)の実装。マネージドコードからアンマネージドコードへのCOM呼び出し処理をUCOベースのアプローチに移行し、既存のネイティブ実装との段階的な置き換えを行います。

変更内容

  • ComActivator.cs: COM活性化ロジックの拡張（+36行）
  • RuntimeType.CoreCLR.cs: ランタイム型情報への新規メソッド追加（+33行）
  • StubHelpers.cs: スタブヘルパー機能の追加（+14行）
  • Variant.cs: バリアント型の新規機能追加（+39行）
  • __ComObject.cs: COM オブジェクト基盤クラスへの機能追加（+14行）
  • clrtocomcall.cpp: CLRからCONへの呼び出しロジックの最適化（-7行のネット削減）
  • corelib.h: 定義の調整（9行の置換）
  • custommarshalerinfo.cpp: カスタムマーシャラー情報の微調整
  • metasig.h: メソッドシグネチャ定義の追加（+14行）
  • olevariant.cpp: OLE バリアント処理の簡素化（-12行のネット削減）
  • runtimecallablewrapper.cpp: ランタイム呼び出し可能ラッパーの最適化（-6行のネット削減）

パフォーマンスへの影響

ベンチマーク結果の記載なし。段階的な移行のため、パフォーマンスへの直接的な影響は不明です。ネイティブコード側で削減されている行数から、一部の処理最適化が期待されます。

関連Issue

#123864

その他

  • この変更は.NETランタイムの内部実装（System.Private.CoreLib およびVM層）に影響します
  • COM相互運用機能の段階的な現代化を進めるプロジェクトの一環であり、破壊的変更の可能性は低いと考えられます
  • 複数のレビュワーによる検証を経ており、COM相互運用に関連する専門家による十分なレビューが行われています

#125220 Add SafeFileHandle.CreateAnonymousPipe with per-end async support, non-blocking I/O support, and Process.Windows adoption

  • 作成者: @Copilot
  • 作成日時: 2026年03月05日 13:40:29(UTC)
  • マージ日時: 2026年03月12日 18:30:51(UTC)
  • ラベル: area-System.IO breaking-change needs-breaking-change-doc-created

概要

新しい公開API SafeFileHandle.CreateAnonymousPipe(out readHandle, out writeHandle, asyncRead = false, asyncWrite = false) を導入し、Windows/Unix両プラットフォームで真のエンド単位の非同期I/Oセマンティクスを実現します。Windows側は名前付きパイプトリックを採用し、Unix側はO_NONBLOCKフラグで非ブロッキング状態を検出します。Process.Windows.csは新APIを採用し、標準ハンドルアクセスはConsole.OpenStandardInputHandle()等に移行しました。

SafeFileHandle.CreateAnonymousPipe(
    out SafeFileHandle readHandle,
    out SafeFileHandle writeHandle,
    asyncRead: true,
    asyncWrite: false);

変更内容

公開API

  • SafeFileHandle.CreateAnonymousPipe(...) を System.Runtime ref に追加（公開API）

CoreLib実装

  • Windows (SafeFileHandle.Windows.cs)：同期時は標準CreatePipe、非同期時は名前付きパイプベースの実装を採用。エラー処理を整理し、IsAsyncキャッシュを設定
  • Unix (SafeFileHandle.Unix.cs)：新しいO_NONBLOCK_READ/O_NONBLOCK_WRITEフラグでInterop.Sys.Pipeを呼び出し。IsAsyncを動的にSystemNative_FcntlGetIsNonBlockingで検出（従来は常にfalseを返していた）。NullableBoolバッキングをsbyteに統一

ネイティブレイヤー

  • pal_io.cにReadFromNonblocking/WriteToNonblockingヘルパーを追加。poll()で待機後I/O実行し、EAGAINをループで処理
  • SystemNative_Pipeを拡張し、パイプエンド毎にO_NONBLOCKを独立して設定
  • RandomAccess.UnixがノンブロッキングFDを検出し、新ヘルパーにルーティング

その他の変更

  • SendPacketsElement：Windows固有の非同期要件に対応（if (!fileStream.IsAsync && OperatingSystem.IsWindows())に修正）
  • Process.Windows.cs：CreatePipeWithSecurityAttributes P/Invoke廃止、新API採用。GetStdHandleをConsole.OpenStandardInputHandle()等に置き換え
  • プロジェクト参照：System.ConsoleをSystem.Diagnostics.Process.csprojに追加、不要なinterop参照を削除
  • テスト：4通りのasyncRead × asyncWrite組み合わせをカバー。Unix側のIsAsync動作変化に対応（SendPacketsElementTestに[PlatformSpecific(TestPlatforms.Windows)]追加）

パフォーマンスへの影響

ノンブロッキングパイプでのUnix側ポーリングベースI/O（poll()ループ）は追加のシステムコール呼び出しを伴うため、高スループット環境での微細な性能低下の可能性があります。詳細なベンチマーク結果は提供されていません。

関連Issue

なし

その他

  • 破壊的変更：Unix側でFileStream.IsAsyncが正しく動作するようになり、従来は常にfalseを返していた挙動が改善されます
  • 互換

#125198 Add TraverseEHInfo cDAC API

  • 作成者: @rcj1
  • 作成日時: 2026年03月05日 00:42:07(UTC)
  • マージ日時: 2026年03月12日 14:10:07(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

cDAC（Debugger Cooperative Access Contracts）に TraverseEHInfo API を追加し、例外処理情報（EHInfo）の走査機能を実装しました。同時に、catch-all ハンドラーの型判定バグを修正しています。従来は mdTypeRefNil との比較で判定していましたが、実際の catch-all ハンドラーは System.Object 型であるため、キャッシュされた System.Object メソッドテーブルとの比較に変更されました。

変更内容

  • cDAC API層: IExecutionManager インターフェースに TraverseEHInfo メソッドを追加（ISOSDacInterface.cs、ExecutionManager*.cs）
  • 例外処理データ構造: ExceptionClause、ExceptionLookupTableEntry、EEILException など複数のデータ型を新規定義
  • ReadyToRun サポート: ReadyToRunInfo、ReadyToRunCoreHeader、ReadyToRunSection などのデータ構造を実装
  • バグ修正: eexcp.h の catch-all ハンドラー判定ロジックを修正（mdTypeRefNil から System.Object メソッドテーブル比較に変更）
  • 実装層: ExecutionManagerCore.cs、SOSDacImpl.cs で EHInfo 走査ロジックを実装
  • テスト: ExceptionHandlingInfoDumpTests.cs に E2E テストを追加、テスト用デバッギープログラム（ExceptionHandlingInfo.csproj）を追加
  • ドキュメント: ExecutionManager.md に新 API の仕様を記載

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

本変更はマネージドデバッグ/診断ツール向けの cDAC API 拡張であり、パブリック API ではなく内部実装の追加です。ReadyToRun イメージ内の例外処理情報の読み取りと走査を可能にするものです。

#125177 [clr-interp] Fix Swift error handling for marshaled P/Invokes in interpreter

  • 作成者: @kotlarmilos
  • 作成日時: 2026年03月04日 13:51:52(UTC)
  • マージ日時: 2026年03月12日 18:16:59(UTC)
  • ラベル: os-ios area-CodeGen-Interpreter-coreclr

概要

Swift P/Invokeがマーシャリングを必要とする場合（例：ref SwiftError）、インタープリタがILスタブ経由で呼び出すときのSwiftエラーハンドリングの問題を修正しました。従来は二重のネイティブ遷移が発生し、x21レジスタ（Swiftエラー用）の値がExecuteInterpretedMethodによる保存/復元で上書きされるバグがありました。修正により、マーシャリング後のcalliでSwift呼び出し規約を正しく適用し、Swiftエラーレジスタを適切なネイティブ遷移時点でキャプチャするようにしました。

変更内容

  • jitinterface.cpp: インタープリタのcalliクッキー生成時にMethodDescコンテキストを渡すよう修正
  • interpexec.cpp: GetCookieForCalliSigがコンテキストを受け取り、CallStubGeneratorへ転送するよう拡張
  • callstubgenerator.h/cpp: GenerateCallStubForSigにオプショナルコンテキストMethodDesc*を追加し、ComputeCallStubに転送。マーシャリング必要なSwift P/Invokeを「Swift IL stub」とマークして外部スタブの処理をスキップ
  • prestub.cpp: スタブ生成時にコンテキスト情報の伝播処理を追加
  • wasm/helpers.cpp: WASM実装のGetCookieForCalliSigにコンテキストパラメータを追加（署名互換性のため）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

Copilotのコードレビューで、WASM実装のGetCookieForCalliSigにおいてpContextMDパラメータが未使用のため、-Wunused-parameter警告を引き起こす可能性があると指摘されています。この修正は内部APIの変更であり、公開APIには影響しません。

#125039 Fix missing big-endian conversions for multi-byte NTLM wire fields

  • 作成者: @Copilot
  • 作成日時: 2026年03月02日 08:37:36(UTC)
  • マージ日時: 2026年03月12日 21:56:54(UTC)
  • ラベル: area-System.Net.Security

概要

PR #124598でNTLM big-endianサポート実装時に見落とされた複数の多バイトフィールドのエンディアン変換を追加します。NTLM wire protocolはリトルエンディアンであり、big-endianアーキテクチャ上でMessageField.Length/MaximumLength、ChallengeMessage.Flags、AuthenticateMessage.Flags、NtChallengeResponse.Timeが正しくバイトスワップされていないため、wire formatが破損していました。

既に確立されているパターン（_payloadOffset、_productBuild、NegotiateMessage.Flags）を踏襲し、プライベートバッキングフィールド + エンディアン対応プロパティで統一します。

変更内容

src/libraries/System.Net.Security/src/System/Net/NegotiateAuthenticationPal.ManagedNtlm.cs

  • MessageField.LengthとMaximumLength：パブリックフィールドからプライベートバッキングフィールド + エンディアン対応プロパティに変更。GetFieldLengthとGetFieldOffsetを削除し、GetFieldでフィールドプロパティを直接アクセスするよう簡素化。SetFieldを廃止し、プロパティ代入に置き換え。unsafe修飾子を削除。
  • ChallengeMessage.Flags（uint）：プライベート_flags + プロパティに変更。呼び出し元の inline byte swap変換を削除。
  • AuthenticateMessage.Flags（uint）：ChallengeMessage.Flagsと同じ処理。
  • NtChallengeResponse.Time（long）：プライベート_time + エンディアン対応プロパティに変更。

全StructLayout(LayoutKind.Sequential)は変更なし（バッキングフィールド宣言位置は同一）。

パフォーマンスへの影響

影響なし

関連Issue

#124598（この修正の基となるPR）

その他

  • すべての変更は既存のBitConverter.IsLittleEndian ? value : BinaryPrimitives.ReverseEndianness(value)パターンに従っています。
  • 本修正により、big-endianアーキテクチャ上でのNTLM認証処理のwire format破損が解決されます。
  • 内部実装（System.Net.Securityライブラリ内部）の修正であり、公開APIに影響はありません。

#125022 Fix memory overwrites in SystemNative_GetNetworkInterfaces

  • 作成者: @gwr
  • 作成日時: 2026年03月01日 03:03:19(UTC)
  • マージ日時: 2026年03月12日 21:27:55(UTC)
  • ラベル: area-System.Net community-contribution

概要

SystemNative_GetNetworkInterfacesでのメモリ上書きバグを修正しています。getifaddrsがIPv4/IPv6エントリのみを返す場合（count == ip4count + ip6count）、割り当てたバッファがNetworkInterfaceInfo配列とIpAddressInfo配列の両方を収容しきれず、メモリ上書きが発生していた問題を解決しました。

変更内容

  • src/native/libs/System.Native/pal_interfaceaddresses.c
    • メモリ割り当てサイズをcount + ip4count + ip6countエントリ分に変更し、プラットフォーム固有の条件分岐を削除
    • addressListポインタをNetworkInterfaceInfo[count]直後から開始するよう設定（計算値が0になるケースを回避）
    • Android限定の条件付きサイズ決定ロジックを削除し、プラットフォーム非依存なアプローチに統一

パフォーマンスへの影響

影響なし

関連Issue

#124728の作業中に発見

その他

Copilotの指摘として、メモリ割り当て失敗時にgetifaddrs()の結果（head）が解放されずにリークする可能性があります。OOM時にfreeifaddrs(head)を呼び出してからエラーを返すべきです。

#125002 Streamline SystemIPGlobalProperties

  • 作成者: @pentp
  • 作成日時: 2026年02月28日 05:00:28(UTC)
  • マージ日時: 2026年03月12日 14:24:39(UTC)
  • ラベル: area-System.Net community-contribution

概要

Windows上のSystemIPGlobalPropertiesのTCP/UDP列挙処理を最適化し、管理側のメモリ割り当てを削減します。GetExtendedTcpTable/GetExtendedUdpTableネイティブAPIを使用してネイティブ層でのフィルタリングを活用し、バイトスライシング解析から型付きspan列挙へ移行することで、複数の割り当てレイヤーを削減します。

変更内容

  • Interop.NetworkInformation.cs: IpHlpApi相互運用構造体のレイアウトを再設計し、ネイティブ宣言により密接に一致させます。LocalEndPoint/RemoteEndPointヘルパープロパティを追加し、未使用のレガシーP/Invokeを削除します。
  • SystemIPGlobalProperties.cs: TCP/UDP列挙をGetExtendedTcpTable/GetExtendedUdpTableを使用するように変更。リスナークエリではネイティブのテーブルクラスフィルタリングを活用し、span ベースの反復処理でエントリを列挙するよう改善します。
  • SystemTcpConnection.cs: 新しい相互運用層のState/エンドポイントヘルパーを消費して接続情報の構築を簡潔化します。

パフォーマンスへの影響

メモリ割り当てが複数削減されます：

  • ネイティブAPIフィルタリングにより、不要なエントリの管理側処理が削減
  • バイト配列スライシング解析から型付きspan列挙への移行により割り当て削減
  • 安全なspan操作により危険なポインタ操作を最小化

具体的なベンチマーク数値は提供されていません。

関連Issue

なし

その他

レビュー過程でCopilotから低信頼度のコメントが提出されています：GetActiveUdpListenersのGetUdpTableAPI参照のコメントが、実際にGetExtendedUdpTableに変更されているため、ドキュメント更新の必要性が指摘されています。

#124959 Feature and ifdef FEATURE_MULTITHREADING

  • 作成者: @pavelsavara
  • 作成日時: 2026年02月27日 11:40:55(UTC)
  • マージ日時: 2026年03月12日 20:47:37(UTC)
  • ラベル: arch-wasm area-Infrastructure-libraries os-browser

概要

このPRは、.NETランタイムのスレッド機能検出メカニズムをリファクタリングしています。複数のスレッド関連の機能フラグ（FEATURE_WASM_MANAGED_THREADSとFEATURE_SINGLE_THREADED）を、より一貫性のある単一のフラグFEATURE_IS_MULTITHREADING_SUPPORTEDに統一します。WebAssemblyターゲットを中心に、スレッド機能の有無を明確かつ統一的に表現する目的です。

変更内容

  • MSBuildプロパティの統一: FeatureWasmManagedThreadsをFeatureIsMultithreadingSupportedに、FeatureSingleThreadを廃止
  • C#プリプロセッサディレクティブ: FEATURE_WASM_MANAGED_THREADSをFEATURE_IS_MULTITHREADING_SUPPORTEDに置換
  • 逆ロジックの活用: 従来のFEATURE_SINGLE_THREADEDは!FEATURE_IS_MULTITHREADING_SUPPORTEDで表現
  • ランタイム層の更新: CoreClR PAL（Platform Abstraction Layer）のC/C++コードの条件付きコンパイルディレクティブ（#ifdef/#ifndef）を統一
  • 影響範囲: System.Threading系ライブラリ、System.Runtime.InteropServices.JavaScript、System.Linq.Parallel、ThreadPool実装、ドキュメント更新（threads.md）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

注意点: レビュー時にThreadPoolWorkQueueの高優先度アイテム処理にて、シングルスレッドビルド（#if !FEATURE_MULTITHREADING）で条件判定が逆になっている可能性が指摘されています。具体的には、キューが空のときに処理を試みており、実装の意図確認が必要な箇所があります。

#124468 [release/10.0] Fix ZIP64 header corruption when large file at large offset

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年02月16日 15:23:52(UTC)
  • マージ日時: 2026年03月12日 09:37:29(UTC)
  • ラベル: Servicing-approved area-System.IO.Compression

概要

ZipArchiveが4GB以上のファイルを既に4GB以上のサイズを持つアーカイブに書き込む際にZIP64ヘッダーを破損させていた問題を修正しました。この不具合により、7-ZipがExtra_ERROR Zip64_ERRORを表示し、.NETで生成されたファイルに対してZipFile.OpenReadがInvalidDataExceptionをスローしていました。

変更内容

  • ZipArchiveEntry.cs: ZIP64中央ディレクトリヘッダー生成時の1行のロジック修正。エントリのサイズとオフセットの両方が4GBを超える場合、既に初期化されているZip64ExtraFieldを削除しないようにしました（以前は破棄されていました）
  • zip_LargeFiles.cs: リグレッションテストLargeFile_At_LargeOffset_ZIP64_HeaderPreservationを追加。メモリ不足時はSkipTestExceptionで適切にスキップします

パフォーマンスへの影響

影響なし

関連Issue

#122489、#122837

その他

  • 回帰情報: .NET 10で導入された回帰。コミット44c08b874792487f81c546ea112b7d4a677c911eで問題が発生
  • 顧客への影響: RavenDBが報告した問題。ZipArchiveで生成されたスナップショットバックアップがZIPヘッダー破損により復旧不可能になっていました
  • リスク評価: 低。ZIP64のみに影響する特定のコード経路での単一行の修正であり、エクストリームケース（サイズとオフセットの両方が4GB超）のみ対象
目次