Pull Request on 2026年10月21日

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

注意点

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

目次

  1. #136252 Clarify guidance for historical implementation context
  2. #136235 [release/10.0] Update build and packaging Pkcs dependency to 9.0.21
  3. #136233 [release/10.0] Update MsQuic to 2.5.12
  4. #136220 Update Zip Encryption mode state checks
  5. #136202 Enable native AOT WASI testing in CI (build only)
  6. #136188 Remove managed-only ilasm round-trip exclusions
  7. #136183 Support IJW native TLS static field access
  8. #136176 ILVerify: allow family access through implemented interfaces
  9. #136167 [release/8.0] Reset October OOB package generation for November servicing
  10. #136156 Use Volatile.ReadBarrier in JsonArray/JsonObject.GetUnderlyingReprese…
  11. #136151 [browser] Restore HotReload functional test execution in CI
  12. #136140 Fix #136137-COM IDispatch property setter dropping BINDER_IgnoreReturn flag
  13. #136133 ILVerify: continue checking methods that use calli, mkrefany, refanyval and refanytype instead of aborting them
  14. #136126 Fix NativeAOT MethodInvoker span argument-count validation
  15. #136115 [release/11.0] ILC/crossgen2: make IsAsyncCall instantiation-invariant
  16. #136100 JIT: Devirtualize calls before probing them in optimized instrumented code
  17. #136095 [release/8.0] Update dependencies from dotnet/emsdk
  18. #136070 [release/11.0] Update dependencies from dotnet/xharness
  19. #136067 [release/11.0] Update dependencies from dotnet/icu
  20. #136066 [release/9.0] Update dependencies from dotnet/emsdk
  21. #135990 [NativeAOT] Recognize recursive tail-call epilogues on Unix x64
  22. #135955 Add dedicated NativeAOT WASM build integration for WASI
  23. #135928 [Android] Avoid eager trust-anchor enumeration in certificate-chain builds
  24. #135847 Flatten NativeAOT reflection metadata namespaces
  25. #135776 Allow non-metadata JSON property names with a leading dollar sign
  26. #135763 Support for interface dispatch on native AOT/WASM
  27. #135671 [automated] Merge branch 'release/9.0' => 'release/9.0-staging'
  28. #135670 [automated] Merge branch 'release/8.0' => 'release/8.0-staging'
  29. #135638 JIT: make sure the block a catch returns to generates an instruction
  30. #135543 [wasm] Regalloc: Allow Non-exposed GC Ref Locals to Live in Wasm Locals
  31. #135438 [mono][aot] Fix recursive struct wrapper normalization
  32. #135296 [wasm] [spmi] Collect SPMI contexts from libraries via crossgen2
  33. #135291 [wasm][R2R] Skip methods with explicit tail calls in crossgen2
  34. #130935 Remove target and target-dependent ifdefs from dbi
  35. #130717 JIT: Materialize partially-constant Vector.Create as CNS_VEC + inserts

#136252 Clarify guidance for historical implementation context

概要

Copilot向けの指示ファイル（conventions.instructions.md）のコメントに関するガイダンスを修正するPRです。過去の実装に関する履歴的な説明は、ソースコードのコメントではなく annotate_diff_line ツールを使って記載するよう明確化しています。ツールが利用できない場合は、ソースコメントとして残さず、その説明自体を省略するよう指示しています。

これにより、CopilotがPRに履歴的な説明コメントを追加してしまうことを避けつつ、Copilotを操作している人間のコーディネーターには見える形を維持する狙いです。

変更内容

  • .github/instructions/conventions.instructions.md（+1/-1）
    • 過去の実装コンテキストに関するソースコメントのガイダンスを更新

パフォーマンスへの影響

影響なし（ランタイム/ライブラリのコードではなく、Copilot向けの指示ドキュメントのみの変更）

関連Issue

なし

その他

  • 公開APIや内部実装への変更、互換性への影響はありません。
  • PR説明によると、この説明文自体もGitHub Copilotによって生成されています。

#136235 [release/10.0] Update build and packaging Pkcs dependency to 9.0.21

概要

release/10.0 ブランチのビルド・パッケージングで使用される System.Security.Cryptography.Pkcs の依存バージョンを 9.0.21 に更新するPRです。これらのプロジェクトは NuGet.Packaging/7.0.3-rc.46203 経由で Pkcs 9.0.6 を推移的に解決しており、公開済みの脆弱性アドバイザリ（GHSA-846f-f764-76mx、GHSA-2fmv-rv2c-59x7）により NU1902/NU1903 が発生し、warnings-as-errors ポリシーのためWindows/Linuxのビルドが失敗していました。直接の PackageReference でパッチ済みバージョンを選択することで、NuGetツールセットの変更や脆弱性監査の抑制をせずに解消しています。

変更内容

  • eng/Versions.props: Pkcs のバージョンを共有プロパティとして追加（+1）
  • src/tasks/Crossgen2Tasks/Crossgen2Tasks.csproj: Pkcs 9.0.21 への直接参照を追加（+1）
  • src/tasks/installer.tasks/installer.tasks.csproj: 同上（+1）
  • src/installer/tests/Microsoft.DotNet.CoreSetup.Packaging.Tests/Microsoft.DotNet.CoreSetup.Packaging.Tests.csproj: 同上（+1）

プロダクトコードの変更や監査の抑制はなく、ビルド/テスト用依存関係のサービシング更新です。

パフォーマンスへの影響

影響なし

関連Issue

#136231

その他

  • main ブランチ側の対応PRはなく、release/10.0 のビルド依存グラフ固有の対応です。
  • MsQuic更新の #136233 とは別PRです。
  • 脆弱性はいずれもサービス拒否（DoS）に関するもので、9.0.21 はアドバイザリに記載された9.x系のパッチ済みリリースです。
  • 検証（Windows x64, SDK 10.0.111）:
    • 3プロジェクトとも restore が成功（修正前は失敗）し、Pkcs 9.0.21 が解決されて監査エラーも発生しない
    • 2つのタスクプロジェクトとパッケージングテストアセンブリのビルドが成功（テストは /p:SkipBuildingSharedFrameworkTestDependencies=true 指定時）
    • パッケージングテストは3件中3件が失敗。ローカルにプロダクトの .nupkg が存在しないことが原因
    • フルプロダクトビルドは未実施で、main ブランチとのベースライン比較は省略
  • リスクは低いと評価されていますが、パッケージ成果物に依存するテストは未検証です。

#136233 [release/10.0] Update MsQuic to 2.5.12

概要

Microsoft.Native.Quic.MsQuic.Schannel のバージョンを定義するプロパティ MicrosoftNativeQuicMsQuicSchannelVersion を 2.5.11 から 2.5.12 に更新する release/10.0 向けのバックポートです（main の #135749 に対応）。2.5.11 には GHSA-2mxg-prvg-9jfg（CVE-2026-85790）が報告されており、この脆弱性の影響で NuGet の監査警告 NU1902 が警告をエラーとして扱う設定下で restore を失敗させていました。2.5.12 は修正済みのバージョンです。マネージドコードの変更はありません。

変更内容

  • eng/Versions.props: MicrosoftNativeQuicMsQuicSchannelVersion を 2.5.11 → 2.5.12 に変更（1行）。この共有プロパティにより、Windows 向け製品パッケージと functional テスト用パッケージの両方の参照が更新されます。
  • 監査の抑制（suppression）やマネージドコードの変更は含まれません。

パフォーマンスへの影響

影響なし（ネイティブ依存関係のパッチバージョン更新のみ。ベンチマーク結果の記載もなし）。

関連Issue

  • #136232（本PRが修正対象とするIssue）
  • #135749（main ブランチの対応PR）
  • #135883（適用元の依存関係変更）
  • #135884（release/9.0 側の対応PR）
  • #136068（同じ MsQuic 起因のブロッカー）
  • #136231（別件：System.Security.Cryptography.Pkcs 9.0.6 の監査失敗。本PRでは未対応）

その他

  • 作成者によるテスト結果（Windows x64、SDK 10.0.111）:
    • 変更前: System.Net.Quic.csproj の restore が NU1902（Schannel 2.5.11）で失敗。
    • 変更後: 同じ restore が成功し、project.assets.json で 2.5.12 に解決。ビルドも警告・エラーなしで成功。
    • functional テストは「共有フレームワークが未ビルド」のため実行前に失敗しており、ネイティブのランタイム動作はローカルでは未検証です。
    • フルのランタイム／ライブラリビルドおよび main ブランチとの完全なベースライン比較は実施されていません。
    • Crossgen2Tasks.csproj の restore は、NuGet.Packaging 経由の Pkcs 9.0.6 に起因する NU1902/NU1903 で引き続き失敗します（#136231 で追跡）。
  • リスク評価: 低。main、release/8.0、release/9.0 で既に使用されているバージョンに合わせた1行の更新です。
  • 互換性への影響（破壊的変更など）の記載はありません。

#136220 Update Zip Encryption mode state checks

概要

ZIPエントリの暗号化状態チェックを整理する小規模なリファクタリングです。AES判定を EncryptionMethod を中心に統一し、冗長な状態判定を削除しています。同期・非同期の読み取り／書き込み／更新の各パスで一貫した形に揃えています。

変更内容

  • src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs（+22/-35）
    • AES関連のチェックを EncryptionMethod ベースに集約
    • 冗長なヘッダー圧縮状態の判定およびZipCryptoの判定を削除
  • src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.Async.cs（+6/-6）
    • 非同期パスの暗号化チェックを同期パスと同じ形に揃えた

パフォーマンスへの影響

影響なし（提供された情報にパフォーマンスに関する記載・ベンチマーク結果はありません）

関連Issue

なし

その他

  • Copilotのレビュー概要では、レビュー対象パスで暗号化の扱いは維持されており、未解決の指摘事項はないとされています。
  • ビルドおよびテストは実行されていない旨が記載されています。
  • 公開APIや互換性への影響について、提供情報からは言及がありません。

#136202 Enable native AOT WASI testing in CI (build only)

概要

CIにおいて、native AOT WASI向けのテストをビルドのみ有効化するPull Requestです。作成者によると、UnitTestsにruntime asyncへの参照が含まれていることに加え、別の箇所でJITに関するアサートが発生するため、UnitTestsはビルドできない状態です。そのため、暫定対応として一部を除外しています（「This is just for now」とのこと）。

変更内容

  • eng/pipelines/runtime.yml（+30/-0）: native AOT WASIのビルドをCIに追加する設定（30行追加）
  • src/tests/nativeaot/SmokeTests/UnitTests/UnitTests.csproj（+3/-0）: UnitTestsに関する3行の追加（詳細は提供情報からは不明）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • テストは実行せず「build only」でのCI有効化です。
  • UnitTestsのビルド不可は暫定的な状況で、将来的な解消が前提とみられます。

#136188 Remove managed-only ilasm round-trip exclusions

概要

IL ラウンドトリップテスト向けの「managed-only ilasm」除外の仕組み（プロパティ、マーカー処理、ラッパー内のチェック、関連ドキュメント）を削除するPRです。あわせて、gentype テストは意図的に無効なメタデータを生成するため、IL ラウンドトリップ非対応として明示的にマークしています。

変更内容

  • src/tests/Loader/classloader/regressions/dev10_403582/gentype.ilproj: gentype を IL ラウンドトリップ非互換としてマーク（+2/-1）。無効なメタデータを意図的に生成するため。

  • src/tests/Common/CLRTest.Execute.Bash.targets / CLRTest.Execute.Batch.targets / CLRTest.Execute.targets: managed-only 関連のマーカー処理・ラッパー内チェックを削除（Bash: -8、Batch: -11、共通: -3）。

  • src/tests/Common/CLRTest.Jit.targets: 関連処理を削除（-5）。

  • src/tests/Directory.Build.targets: 不要になった managed-only 関連の定義を削除（-3）。

  • ドキュメント更新:

    • docs/workflow/ci/disabling-tests.md
    • docs/workflow/testing/coreclr/requiresprocessisolation.md
    • docs/workflow/testing/coreclr/test-configuration.md

    いずれも obsolete となった managed-only 関連の記述を削除・修正しています。

パフォーマンスへの影響

影響なし（テストインフラとドキュメントのみの変更で、ランタイム／ライブラリの実装や公開APIには影響しません）。

関連Issue

なし

その他

  • 変更対象は src/tests 配下のテストビルド／実行基盤とドキュメントに限られ、互換性への影響（破壊的変更・非推奨化）はありません。
  • 全体として、ほぼ削除中心（追加は数行）のクリーンアップです。

#136183 Support IJW native TLS static field access

概要

IJW（C++/CLI）のネイティブTLS（スレッドローカルストレージ）静的フィールドへのアクセスをサポートするための変更です。関連Issue（#133538、#42187）を修正する対応で、CoreCLRのJITヘルパー関連のコードに追加が行われています。提供された情報からは、実装の詳細な動作までは確認できません。

変更内容

  • src/coreclr/inc/jithelpers.h: 4行追加
  • src/coreclr/vm/jithelpers.cpp: 17行追加
  • src/coreclr/vm/jitinterface.h: 4行追加
  • テストファイルの修正（各1行追加/1行削除）:
    • src/tests/JIT/Directed/tls/MutualRecurThd-TLS.cs
    • src/tests/JIT/Directed/tls/Test-TLS.cs
    • src/tests/JIT/Regression/CLR-x86-EJIT/v1-m10/b07847/b07847.cs
    • src/tests/JIT/Regression/CLR-x86-JIT/V1.2-M01/b03689/b03689.cs

変更はランタイム内部（CoreCLRのVM/JITインターフェース層）が中心で、公開APIの変更は提供情報からは確認できません。

パフォーマンスへの影響

影響なし（提供された情報にベンチマーク結果やパフォーマンスに関する記載はありません）

関連Issue

その他

  • 作成者は jkoritzinsky です。
  • 破壊的変更、セキュリティ修正、非推奨化に関する記載は提供情報にはありません。
  • テストファイルの具体的な変更内容は提供情報からは不明です。

#136176 ILVerify: allow family access through implemented interfaces

概要

ILVerify が、インターフェイスを実装した型から、そのインターフェイスの protected（family）メンバーを呼び出すコードを MethodAccess エラーとして拒否していた問題を修正します。ランタイム（ClassLoader::CanAccessFamily）はこの呼び出しを許可しているため、ILVerify のアクセスチェックをランタイムの挙動に揃えます。

AccessVerificationHelpers.cs の CanAccessFamily は、対象の型定義を現在の型の基底型の中からしか探していませんでした。対象がインターフェイスの場合は、現在の型の RuntimeInterfaces の中から型定義で比較するように変更しています。これにより、ジェネリックインターフェイスの別のインスタンス化でも許可されます。RuntimeInterfaces には基底クラスや他のインターフェイスから継承したインターフェイスも含まれ、入れ子型は既存の外側の型へのループでカバーされます。

変更内容

  • src/coreclr/tools/ILVerification/AccessVerificationHelpers.cs（+12）
    • CanAccessFamily に、対象がインターフェイスの場合の判定を追加しました。実装しているインターフェイスを型定義で比較します。
    • protected インスタンスメンバーは現在の型のインスタンス経由でアクセスする、という既存のチェックは先に実行されます。ランタイムにはこのチェックはありませんが、ILVerify がクラスに適用している制約をインターフェイスにも維持しています。
  • src/coreclr/tools/ILVerification.Tests/ILTests/AccessTests.il（+133）
    • ルールごとに 7 つの IL テストを追加しました。
    • 有効になるケース（4 件）:
      • 別インスタンス化のジェネリックインターフェイスの protected static メソッドを constrained. 経由で呼ぶ構造体（Int32.CreateChecked と同じ形）
      • 基底クラスがインターフェイスを実装しているクラス
      • インターフェイスを実装するクラスの入れ子型
      • 派生インターフェイスの既定メソッドが this の protected インスタンスメソッドを呼ぶケース
    • MethodAccess になるケース（3 件）:
      • インターフェイスを実装していないクラス
      • 無関係なインターフェイスだけを実装するクラス
      • 別の実装クラスのインスタンス経由で protected インスタンスメソッドを呼ぶケース
    • 有効な 4 件は main では MethodAccess で失敗し、無効な 3 件は main でも本変更後でも通ります。
    • ILVerification.Tests は Release / Debug とも 535 件中 535 件が成功しています。
    • 意図的に壊した 6 種類の実装で、それぞれ対応するテストが失敗することを確認しています。
    • .NET 10.0.12 の実ランタイムでも各ケースを実行して確認しています。

パフォーマンスへの影響

影響なし（ILVerify の検証ロジックの変更であり、ランタイムのパフォーマンスには関係しません）。

実測した検証結果への影響は次のとおりです。

  • 共有フレームワーク（Microsoft.NETCore.App 10.0.12、130,146 メソッド本体）と 4 セットの NuGet パッケージ（388,490 メソッド本体）を main と本ブランチで比較しました。
  • 検証モードで変化があったのは DotNext 6.10.0 のみです。
    • MethodAccess エラーが 52 件から 1 件に減りました（41 メソッドで 51 件解消、うち 38 メソッドが検証を通過）。
    • 残る 1 件は Object.Finalize の ldvirtftn で、インターフェイスメンバーではありません。
    • InlineBufferWriter<T>.GetBuffer では、これまで MethodAccess エラーで最初のブロックで検証が止まっていたため見えていなかった ReturnPtrToStack が ret で報告されるようになります。
    • フレームワークの結果は変わりません。該当する 57 件の呼び出しは、先に InitLocals で失敗するメソッド内にあるためです。
  • 検証のみモード（#136169 の上に本変更を適用）では、フレームワークの 57 件の MethodAccess エラー（19 個の数値型の CreateChecked、CreateSaturating、CreateTruncating）が解消し、これらのメソッドが通過します。DotNext も同じく 51 件が解消します。
  • いずれのモードでも、これ以外の変化はありません。

関連Issue

#136175（本 PR により修正）。検証のみモードの確認で #136169 も参照されています。

その他

  • 作成者の記載によれば、本 PR は AI（Anthropic Claude と OpenAI Codex）の支援のもとで作成され、作成者がレビューしています。
  • Copilot のレビューでは未解決の指摘はなく、承認推奨（Approval recommended）とされています。ビルドとテストはレビュー中には再実行されていません。
// 例: Int32.CreateChecked と同じ形（自身を型引数とする interface の protected static を constrained. で呼ぶ）
// このパターンが、これまで ILVerify で MethodAccess として拒否されていました。

#136167 [release/8.0] Reset October OOB package generation for November servicing

概要

release/8.0 ブランチにおいて、10月のOOB（Out-of-Band）パッケージ生成設定をリセットし、11月のサービシングに備える定例のパッケージ作成クリーンアップです。すでに公開済みのOOBパッケージが後続のビルドで不要に再生成されることを防ぐため、3つのライブラリプロジェクトの GeneratePackageOnBuild を true から false に変更します。

変更内容

以下の3つの .csproj で、GeneratePackageOnBuild の値を true → false に変更（各 +1/-1）。

  • src/libraries/System.Formats.Cbor/src/System.Formats.Cbor.csproj（8.0.1）
  • src/libraries/System.Security.Cryptography.Pkcs/src/System.Security.Cryptography.Pkcs.csproj（8.0.2）
  • src/libraries/System.Security.Cryptography.Xml/src/System.Security.Cryptography.Xml.csproj（8.0.5）

補足事項:

  • 3つとも2026年10月13日に公開済みのバージョンです。
  • ServicingVersion、IsPackable、ライブラリの実装は変更していません。
  • 変更の影響範囲は.NET 8のサービシングに限られ、.NET 9以降には適用されません。
  • この設定は #135733 で release/8.0 に取り込まれた内部変更により有効化されていたものです。
  • リセット後、release/8.0 上で明示的に有効なOOBライブラリパッケージはありません。トランスポートパッケージと Microsoft.NET.HostModel は対象外で、変更はありません。

パフォーマンスへの影響

影響なし。ランタイム/ライブラリのAPI挙動やコードは変更されず、自動パッケージ生成の設定のみが対象です。

関連Issue

なし

その他

  • 互換性: 公開APIの変更や破壊的変更はありません。製品のリグレッションではなく、リリース後のパッケージ作成のクリーンアップです。
  • リスク: 低。3つのプロパティ値の変更のみで、ソースコード、ターゲットフレームワーク、パッケージバージョン、依存関係は変わりません。
  • 検証: git diff --check と、3プロジェクトに対する dotnet msbuild ... -getProperty:GeneratePackageOnBuild,ServicingVersion,IsPackable が成功しました。評価結果は GeneratePackageOnBuild=false、IsPackable=true、サービシングバージョンは変更なし（1、2、5）です。また src/libraries/**/src/*.*proj に、明示的な GeneratePackageOnBuild=true が残っていないことを確認済みです。製品ビルド、パッケージ生成ビルド、製品テストは未実施です。
  • パッケージ作成のレビュー: 依頼済みですが、サインオフは保留中です。
  • 作成者の記載によると、本PRの説明と変更はGitHub Copilotにより生成されています。

#136156 Use Volatile.ReadBarrier in JsonArray/JsonObject.GetUnderlyingReprese…

概要

System.Text.Json の JsonArray / JsonObject の GetUnderlyingRepresentation で使用していたメモリバリアを、Interlocked.MemoryBarrier から Volatile.ReadBarrier に置き換える変更です（.NET 10+ 向け）。読み取り側に必要な最小限のバリアへ切り替えることが意図と考えられます。

なお、提供された情報にはサンプルコードや詳細な変更差分は含まれていません。

変更内容

  • src/libraries/Common/src/Polyfills/VolatilePolyfills.cs（+15）: Volatile 関連のポリフィルを追加
  • src/libraries/System.Text.Json/src/System.Text.Json.csproj（+1）: 上記ポリフィルを参照するための設定を追加
  • src/libraries/System.Text.Json/src/System/Text/Json/Nodes/JsonArray.cs（+1/-1）: GetUnderlyingRepresentation 内で Volatile.ReadBarrier を使用
  • src/libraries/System.Text.Json/src/System/Text/Json/Nodes/JsonObject.IDictionary.cs（+1/-1）: 同上

公開APIの変更は提供情報からは確認できず、内部実装の変更です。

パフォーマンスへの影響

ベンチマーク結果は提供されていません。Interlocked.MemoryBarrier（フルフェンス）から Volatile.ReadBarrier（読み取りバリア）への変更のため、バリアのコスト削減が見込まれますが、具体的な数値は不明です。

関連Issue

なし

その他

なし

#136151 [browser] Restore HotReload functional test execution in CI

  • 作成者: @vitek-karas
  • 作成日時: 2026年10月20日 13:52:08(UTC)
  • マージ日時: 2026年10月21日 07:28:16(UTC)
  • ラベル: area-Build-mono

概要

Windowsのbrowserライブラリテスト用CIジョブで、WebAssembly.Browser.HotReload.Test.zip がビルドされているにもかかわらず、Helixに投入されずHotReloadの機能テストが実行されていなかった問題を修正します。継承された機能テスト用プロパティによりZIPが runonly ディレクトリに配置されており、Helixは同ディレクトリ内の .Sample.zip のみを対象とするため選択されていませんでした。HotReloadプロジェクト側でアーカイブ関連プロパティを上書きし、ZIPの出力先を browseronly に変更することで、既存のbrowser用セレクタが対象に含めるようになります。テストランナー、期待される終了コード、非Windows CIでの除外設定は変更していません。

変更内容

  • src/tests/FunctionalTests/WebAssembly/Browser/HotReload/WebAssembly.Browser.HotReload.Test.csproj（+4/-0）
    • インポート済みの既定値が評価された後で、アーカイブ関連プロパティを上書きし、ZIPの配置先を browseronly に変更

共通のアーカイブプロパティ自体を変更しなかったのは意図的です。変更するとRuntimeConfigとStartupHookも有効化されてしまいます。StartupHookは、ローカルでICUデータのロード中に異常終了するため、これらのルーティングは変更されていません。

パフォーマンスへの影響

影響なし（CIのテスト対象ルーティングの修正であり、ランタイム/ライブラリの実装変更ではありません）。

関連Issue

その他

作成者によるローカル検証（Windows、Mono/browser Release）の結果:

  • /t:Test でのビルド・実行、およびCI設定（ContinuousIntegrationBuild=true、ArchiveTests=true）でのビルドがともに成功。デルタのリビジョン1・2が適用され、ブラウザ終了コードは 42、XHarness終了コードは 0
  • CI形式のZIPは browseronly\browser.AnyCPU.Release 配下に生成され、展開して生成された RunTests.cmd をヘッドレスChromeで実行しても同様の結果
  • 実際の _AddWorkItemsForLibraryTests セレクタ（Helixジョブは未投入）では、HotReloadのワークアイテムがChromeとFirefoxで各1件ずつ選択され、V8では選択されない。従来の runonly 配置では選択されないことも確認済み
  • 他のbrowser機能テストのアーカイブルーティングは従来どおりで、非Windows CIでのHotReload除外も維持

なお、このパッチを適用した公式CIでの実行はまだ確認されていません。また、本PRはGitHub Copilotの支援を受けて作成されたと記載されています。

#136140 Fix #136137-COM IDispatch property setter dropping BINDER_IgnoreReturn flag

概要

Preview 4 でリグレッションしていた COM IDispatch プロパティセッターの動作を修正する PR です。LateBoundCLRToCOM_ILStub​State::GetInfoFromMetadata（#126330 で導入）の msSetter ケースで、binderFlags = BINDER_SetProperty; と代入していたため、先に設定されていた BINDER_IgnoreReturn フラグが上書きされていました。これを binderFlags |= BINDER_SetProperty; に変更し、フラグを保持するようにしています。

BINDER_IgnoreReturn が失われると、InvokeDispMethod が COM の戻り値を System.Void に変換しようとして OleAutBinder.ChangeType で COMException (0x80020005): Type mismatch が発生していました。

// Before (broken):
binderFlags = BINDER_SetProperty;

// After (fixed):
binderFlags |= BINDER_SetProperty;

変更内容

  • src/coreclr/vm/dllimport.cpp: msSetter ケースの代入（=）を OR 代入（|=）に修正（+1/-1）
  • src/tests/Interop/COM/NETClients/IDispatch/Program.cs: IDispatch クライアント側テストを追加（+11）
  • src/tests/Interop/COM/NETServer/DispatchTesting.cs: .NET サーバー側のテスト用実装を追加（+7）
  • src/tests/Interop/COM/NativeServer/DispatchTesting.h: ネイティブサーバー側のテスト用実装を追加（+50/-1）
  • src/tests/Interop/COM/ServerContracts/Server.Contracts.cs: サーバーコントラクトに定義を追加（+2）

影響範囲は CoreCLR ランタイム内部（COM interop の late-bound IL スタブ生成）で、公開 API の変更ではなく、Preview 4 で発生したリグレッションの修正です。

パフォーマンスへの影響

影響なし

関連Issue

#136137、#126330（リグレッションの原因となった変更）

その他

  • 作成者による手動検証として、Excel COM オートメーションアドインで COM プロパティセッター（Font.Bold、Font.Italic）が例外なく完了することを確認しています。
  • 作成者の説明によれば、#126330 のレビュー時に Copilot が同箇所を指摘していましたが、互換性のためそのままにされていました。しかしフラグ設定の順序が変わったため、現状では = のままだと互換性が保たれないと説明されています。

#136133 ILVerify: continue checking methods that use calli, mkrefany, refanyval and refanytype instead of aborting them

概要

ILVerify が calli、mkrefany、refanyval、refanytype に到達した時点でメソッドの検証を中断していた問題を修正し、これらの命令に対する検証ロジックを追加して検証を継続するようにします。calli は(ランタイムが関数ポインタの寿命を追跡しないため)常に Unverifiable として報告されますが、呼び出し箇所の引数不一致などのエラーは引き続き報告されます。arglist は変更しておらず、ImportArgList は従来どおり "RuntimeArgumentHandle not supported in .NET Core" を throw します。

変更内容

  • src/coreclr/tools/ILVerification/ILImporter.Verify.cs
    • calli: オペランドがスタンドアロンシグネチャトークンであること、メソッドポインタが native int であること、引数が呼び出し先シグネチャに代入可能であることを検証。tail. の戻り値チェックを CheckTailCallReturn に切り出し、call と calli で共有。
    • mkrefany: ポインタが readonly でないマネージドポインタであること、指す型がクラストークンの型と完全一致すること、型がアクセス可能であることを検証し、TypedReference を push。
    • refanyval: オペランドが TypedReference であることを検証し、マネージドポインタを push(戻り値として返すと ReturnPtrToStack を報告)。
    • refanytype: オペランドが TypedReference であることを検証し、RuntimeTypeHandle を push。
  • src/coreclr/tools/ILVerification/VerifierError.cs / Strings.resx: 新しいエラーコード 2 件とそのメッセージを末尾に追加。
  • テスト: CalliTests.il(17件)、TypedReferenceTests.il(16件)と対応する .ilproj を追加。ILVerification.Tests は 513 → 546 件となり、すべて成功。

パフォーマンスへの影響

影響なし(検証ツールの変更であり、ランタイムの実行性能には関係しません)。

計測結果(検証結果への影響):

  • .NET 10.0.12 共有フレームワーク(130,146 メソッド): 中断されていた 31 メソッドが 0 件に。その 31 メソッドで Unverifiable 以外の新規指摘が 37 件(InitLocals 33、UnmanagedPointer 2、StackUnexpected 2)。他のメソッドの結果は変化なし。
  • 公開パッケージ(388,443 メソッド): 149 メソッドで検証が継続され、新規指摘 6 件。うち 1 件は ImpromptuNinjas.ZStd 1.4.5.5 の ZStdDCtx::Copy における実バグ(calli のシグネチャが 3 引数なのに 2 つしか push していない)。

関連Issue

  • #136111(arglist は未対応のため、本 PR は「寄与」であり、対象を 4 命令に絞れば完了となる)
  • #37391(calli の検証のみモードは本 PR では未対応)

その他

  • 制限事項:
    • エラーを報告したブロックからのみ到達可能なブロックは検証されないため、calli 後の別ブロックはチェックされない場合がある。
    • 可変長引数(vararg)の呼び出しで余分な引数を渡すケースは、共有型システムで引き続き失敗する(calli・call 共通)。
  • Roslyn の 4 つのテストが旧メッセージを参照しており、Roslyn が新しい ILVerify を取り込む際に更新が必要。
  • レビューで確認したい未確定事項(作成者が既定値を選択済み):
    1. mkrefany と byref-like クラス: 拡張仕様に従い許可。すべての byref-like クラスを拒否することも可能。
    2. mkrefany の型一致: 完全一致を要求(int32& と uint32 はエラー)。検証型での比較なら許容される。
    3. エラーコード: メッセージごとに 1 つ追加。TokenResolve や ReadOnlyIllegalWrite など既存コードの再利用や改名も可能。
  • 本 PR は AI(Anthropic Claude と OpenAI Codex)の支援のもと作成され、作成者がレビュー済み。

#136126 Fix NativeAOT MethodInvoker span argument-count validation

  • 作成者: @Copilot
  • 作成日時: 2026年10月20日 03:39:14(UTC)
  • マージ日時: 2026年10月21日 07:47:51(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

NativeAOTの MethodInvoker.Invoke(object?, Span<object?>) は、オープンジェネリックメソッドに対して引数の数が誤っている場合に InvalidOperationException をスローしていました。これはCoreCLRや固定アリティのオーバーロードの挙動と異なります。本PRでは、ディスパッチ前に引数の数を検証し、既存のスローヘルパーを使って TargetParameterCountException をスローするよう修正します。引数の数が正しい場合は従来どおり InvalidOperationException が維持されます。

変更内容

  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/MethodInvoker.cs: Spanベースの呼び出しでディスパッチ前に引数の数を検証（+17/-53）
  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/ConstructorInvoker.cs: 同様の変更（+16/-51）
  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/DynamicInvokeInfo.cs: 変更あり（+5/-15）
  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/Runtime/MethodInfos/OpenMethodInvoker.cs: 変更あり（+17/-0）
  • src/coreclr/nativeaot/System.Private.CoreLib/src/Internal/Reflection/Core/Execution/ExecutionEnvironment.cs: 変更あり（+3/-3）
  • src/coreclr/nativeaot/System.Private.CoreLib/src/System/Reflection/Runtime/MethodInfos/NativeFormat/NativeFormatMethodCommon.cs: 変更あり（+1/-1）
  • src/libraries/System.Runtime/tests/System.Reflection.Tests/MethodInvokerTests.cs: オープンジェネリック型の宣言型とジェネリックメソッド定義を対象に、引数が少ない・正しい・多い場合を、Spanおよび固定アリティの各オーバーロードで検証する回帰テストを追加（+18/-0）

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）

関連Issue

#136102

その他

  • 影響範囲はNativeAOTのリフレクション（MethodInvoker）で、CoreCLRとの例外挙動の整合性を取る修正です。
  • Copilotの概要によると、ビルドおよびテストは実行されていません。

#136115 [release/11.0] ILC/crossgen2: make IsAsyncCall instantiation-invariant

概要

release/11.0 への #136002 のバックポート。ILC（Native AOT）および crossgen2（ReadyToRun）で、IsAsyncCall の判定がジェネリックのインスタンス化に依存しないよう修正しています。Runtime Async 使用時に不正なコード生成が起こり、クラッシュする問題（顧客報告: #135922）への対応です。Native AOT と ReadyToRun の両方に影響します。

変更内容

  • src/coreclr/tools/Common/Compiler/MethodExtensions.cs: IsAsyncCall 関連のロジックを修正（+1/-1）。インスタンス化の違いによって判定結果が変わらないようにする変更です。
  • src/tests/async/regression/135922.cs: 問題を再現する回帰テストを追加（+31行）。
  • src/tests/async/regression/135922.csproj: 上記テスト用のプロジェクトファイルを追加（+5行）。

パフォーマンスへの影響

影響なし

関連Issue

その他

  • 顧客報告の不具合の修正です。Runtime Async は新機能のため、リグレッションではありません。
  • 問題の発生には複数の要素の組み合わせが必要で、既存のテストでは検出できていませんでした。そのため新規テストが追加されています。
  • 作成者はリスクを低いと評価しており、修正は変更1行のみで内容も明確としています。

#136100 JIT: Devirtualize calls before probing them in optimized instrumented code

概要

最適化＋インストルメント済みコンパイル（OSR+PGO、TieredPGO_InstrumentedTierAlwaysOptimized、JitInstrumentIfOptimizing など）において、プローブ対象の呼び出しが devirtualize されない問題を修正します。これにより JIT/opt/GuardedDevirtualization/badinlinee が rolling jitstress パイプラインで Test allocated 24000 bytes と失敗していた件（#135557）を解消します。作成者によれば原因は3つ独立して存在し、本PRは (1) JIT の修正、(2) JitStress 下でのテストのスキップ、(3) テストの壁時計依存の解消、の3点でそれぞれ対処しています。

  • 従来は impConsiderCallProbe を devirtualize の前に呼び、プローブ対象にした呼び出しは impDevirtualizeCall をスキップしていました。そのため this が型情報のない一時変数に退避され、後段の devirtualization やインライン化が失敗し、new Base().M() のアロケーションが残っていました。
  • 修正後は先に devirtualize を試み、それでも仮想呼び出しのまま残るものだけをプローブ対象にします。

変更内容

  • src/coreclr/jit/compiler.h
    • impConsiderCallProbe が値を返さなくなったことに伴う宣言の変更（+1/-1）。
  • src/coreclr/jit/importercalls.cpp
    • impImportCall で devirtualize を先に試み、なお仮想のままの呼び出しのみプローブ対象にするよう順序を変更。
    • プローブ対象の呼び出しは GenTreeCall 内でプローブ情報と GDV 候補情報が記憶域を共有するため、considerGuardedDevirtualization で GDV 候補にならないよう早期に抜ける（従来の挙動を維持）。
    • 戻り値が不要になった impConsiderCallProbe を戻り値なしに変更。
  • src/tests/JIT/Regression/JitBlue/Runtime_135557/*（新規）
    • new Base().M() を DOTNET_JitInstrumentIfOptimizing=1（Checked/Debug JIT のみ有効）で最終ティアまで到達させ、アロケーションが発生しないことを検証する最小再現テスト。
  • src/tests/JIT/opt/GuardedDevirtualization/badinlinee.cs / .csproj
    • JitStress ではメソッドがハッシュで選ばれ Test が MinOpts になりインライン化されないため、[SkipOnCoreClr(..., RuntimeTestModes.JitStress)] を付与（TestLibrary 参照を追加）。
    • 固定回数＋Sleep(15) のウォームアップをやめ、JitInfo.GetCompiledMethodCount() が20イテレーション変化しなくなるまで呼び続ける方式に変更（Poison、次に Test の順）。
    • 結果を出力して -1 を返す方式から Assert.Equal による検証に変更。

パフォーマンスへの影響

  • 非インストルメントのコンパイルには影響しません。SuperPMI の asm diff（benchmarks.run、coreclr_tests.run、libraries.pmi など計 1,466,464 コンテキスト）では差分なしです。
  • 最適化＋インストルメント済み Tier1 では、Test() が「仮想呼び出し＋アロケーション（61 バイト）」から mov eax, 42; ret になります。
  • CoreLib を TieredPGO / TieredPGO_InstrumentedTierAlwaysOptimized で crossgen2 した 15,616 コンテキストでは、45 件の diff（サイズ改善 8、悪化 37）、全体で +2,420 バイト（+0.04%）。いずれも、受け手が既知の呼び出しを devirtualize・インライン化するようになった Instrumented Tier1 のコンパイルです。
  • coreclr_tests.run の replay では、optimized+instrumented コンパイルでの新しい JIT-EE クエリ（ResolveVirtualMethod）により 620,965 コンテキスト中 8,179 件で missing data が報告されます（旧 JIT では clean）。

関連Issue

  • #135557
  • #133993（再導入すると、新テストでは通常シナリオで 3/3 失敗するため、回帰検出力の確認に言及されています）

その他

  • テスト結果（作成者報告）:
    • src/tests/JIT 全体（priority 1、22,288 テスト）を新 JIT で、既定構成と instrument_if_optimizing、fullpgo_methodprofiling_always_optimized シナリオで実行し、各構成で 22,125 pass、0 fail、163 skip、2 active issue。
    • 新規の Runtime_135557 は旧 JIT で 10/10 失敗（Expected: 0 Actual: 24000）、修正後 10/10 成功。
    • badinlinee を testenvironment.proj の 49 シナリオで検証。旧 JIT＋旧テストは forcerelocs、jitstress1、jitstress1_tiered、jitstress_isas_1_*、instrument_if_optimizing で失敗。旧 JIT＋新テストでは instrument_if_optimizing のみ失敗。新 JIT＋新テストは全て成功。
  • jitpartialcompilation_pgo_stress_random は旧 JIT・旧テストでも同様にクラッシュ（exit code `0x80

#136095 [release/8.0] Update dependencies from dotnet/emsdk

概要

release/8.0 ブランチにおいて、dotnet/emsdk からの依存関係を Maestro（dotnet-maestro[bot]）が自動更新するPRです。emsdk のビルド 20261020.2（コミット 20528d19ab74790d1874872d9fb9377d1c458307）の成果物が取り込まれます。

変更内容

  • NuGet.config: 1行変更（詳細な変更内容は提供情報からは不明）
  • eng/Version.Details.xml: 4行追加・4行削除（依存関係のバージョン／コミット情報の更新と思われる）
  • eng/Versions.props: 3行追加・2行削除（バージョンプロパティの更新と思われる）

更新される依存関係:

  • Microsoft.SourceBuild.Intermediate.emsdk: 8.0.33-servicing.26508.4 → 8.0.34-servicing.26520.2
  • Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: 8.0.33 → 8.0.34

パフォーマンスへの影響

影響なし（提供情報にパフォーマンスに関する記載はありません）

関連Issue

なし

その他

#136070 [release/11.0] Update dependencies from dotnet/xharness

概要

release/11.0 ブランチで、dotnet/xharness からの依存関係を Maestro（dotnet-maestro[bot]）経由で自動更新する PR です。XHarness 関連パッケージのバージョンを 11.0.0-prerelease.26506.1 から 11.0.0-prerelease.26517.1 に更新します（xharness の Build 20261017.1、main ブランチ、コミット 38ed2081）。

変更内容

  • .config/dotnet-tools.json: ツールのバージョン定義を更新（+1/-1）
  • eng/Version.Details.props: 依存パッケージのバージョンを更新（+3/-3）
  • eng/Version.Details.xml: 依存パッケージのバージョンとコミット情報を更新（+6/-6）

更新対象パッケージ:

  • Microsoft.DotNet.XHarness.CLI
  • Microsoft.DotNet.XHarness.TestRunners.Common
  • Microsoft.DotNet.XHarness.TestRunners.Xunit

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 差分は依存関係のバージョン定義に限られ、ランタイムやライブラリのソースコード変更は含まれません。
  • 変更内容の詳細は xharness の比較 で確認できます。
  • 互換性への影響やセキュリティ修正に関する情報は、提供された内容からは確認できません。

#136067 [release/11.0] Update dependencies from dotnet/icu

概要

dotnet-maestroによる自動依存関係更新のPRです。release/11.0ブランチで、dotnet/icuリポジトリからの依存パッケージ Microsoft.NETCore.Runtime.ICU.Transport を 11.0.0-alpha.1.26505.3 から 11.0.0-alpha.1.26517.3 に更新します。

更新元のビルドは dotnet/icu の dotnet/release/11.0 ブランチ（Build 20261017.3、コミット cc0636e50d30b71ebf043284bb66cc77a4289446）です。

変更内容

  • eng/Version.Details.props: ICU Transportパッケージのバージョン指定を更新（+1/-1）
  • eng/Version.Details.xml: 依存関係のバージョンおよび参照元コミット情報を更新（+2/-2）

いずれも依存関係のバージョン管理用メタデータファイルの変更で、ソースコードやAPIの変更は含まれません。

パフォーマンスへの影響

影響なし（提供情報にパフォーマンスに関する記載はありません）

関連Issue

なし

その他

  • Maestroのサブスクリプション 6a84f872-3d62-42ab-b609-66bc4451b876 による自動生成PRです。
  • 更新対象はICU（国際化・Unicode関連）のランタイム向けトランスポートパッケージです。ICUのどの内容が変わったかは、提供情報からは不明です（差分はこちら）。
  • 互換性への影響や破壊的変更についての記載はありません。

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

概要

dotnet-maestroによる自動依存関係更新PRで、release/9.0 ブランチ向けに dotnet/emsdk の依存関係を更新します。emsdkのビルド 20261020.1（コミット 5a21e41）から、9.0.22-servicing.26508.5 → 9.0.23-servicing.26520.1、9.0.22 → 9.0.23 へバージョンを引き上げています。サンプルコードはありません。

変更内容

  • NuGet.config: 1行変更（詳細な差分内容は提供情報からは不明）
  • eng/Version.Details.xml: 以下の依存関係のバージョン/コミット情報を更新
    • Microsoft.SourceBuild.Intermediate.emsdk
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100
  • eng/Versions.props: 上記依存関係に対応するバージョンプロパティを更新

公開APIやランタイム/ライブラリのコード自体の変更はなく、ビルド・ワークロード関連の依存バージョン更新です。

パフォーマンスへの影響

影響なし（提供された情報にはパフォーマンスに関する記載はありません）

関連Issue

なし

その他

  • 更新元: dotnet/emsdk release/9.0 ブランチ（差分）
  • 互換性への影響や破壊的変更に関する記載は提供情報にはありません。emsdk側の変更内容の詳細は上記の差分リンクで確認してください。

#135990 [NativeAOT] Recognize recursive tail-call epilogues on Unix x64

  • 作成者: @agocke
  • 作成日時: 2026年10月17日 03:11:08(UTC)
  • マージ日時: 2026年10月21日 18:31:07(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

Unix x64 の NativeAOT において、現在のプロシージャのエントリへの直接ジャンプ（再帰的な fast tail call）を tail-call epilogue として認識するよう修正します。

従来の TrailingEpilogueInstructionsCount はプロシージャのアドレス範囲外への直接ジャンプのみを認識し、自身のエントリへのジャンプを除外していました。再帰的 fast tail call ではフレームを復元してからエントリへジャンプするため、この epilogue を通常のメソッド本体のコードとして扱うと、return address hijacking が部分的に解体されたフレームに対して本体の unwind 情報を使用し、誤ったスタックスロットを選択する可能性がありました。

下限の比較を < から <= に変更することで、既存のコメントおよび Windows x64 の unwinder における自己エントリへのジャンプの扱いと整合させています。これにより既存の epilogue 経路が、現在のスタックポインタと残りの pop から return address スロットを特定できるようになります。

変更内容

  • src/coreclr/nativeaot/Runtime/unix/UnixNativeCodeManager.cpp: 下限の比較を < から <= に変更（+1/-1）。自己エントリへのジャンプも tail-call epilogue として分類されます。プロシージャ内部への分岐とプロシージャ外へのジャンプの分類は従来どおりです。
  • src/tests/nativeaot/Regressions/Runtime135912/Runtime135912.cs: 回帰テストを追加（+91）。
  • src/tests/nativeaot/Regressions/Runtime135912/Runtime135912.csproj: 回帰テスト用のプロジェクトファイルを追加（+12）。

対象は NativeAOT ランタイム（Unix x64）の内部実装であり、公開 API や互換性への影響はありません。

パフォーマンスへの影響

影響なし（パフォーマンスに関する記載はありません）。GC のスタックスロット復元の正確性に関する修正です。

関連Issue

#135912（Resolves）

その他

  • 作成者によると、本 PR は GitHub Copilot を用いて作成されています。
  • Copilot の概要では、GC のスタックスロット復元という安全性に関わる変更であり、報告された検証が独立して確認されていないため、慎重なレビューが推奨されています。

#135955 Add dedicated NativeAOT WASM build integration for WASI

概要

NativeAOT向けに、専用のWASMリンカーバックエンド（初期サポートはWASI）をビルド統合として追加するPRです。WASI SDKのClangとllvm-ar、移植可能なランタイムアーカイブ、必要なネイティブ依存を使い、wasm32-wasip2をターゲットとする.wasmコンポーネントを生成します。アーキテクチャ選択はWASI用ツールチェーン設定とは分離されており、すべてのWASMをWASIとして扱うものでも、ブラウザ向けリンクを追加するものでもありません。SDKの場所はWASI_SDK_PATHで指定します。

変更内容

  • Microsoft.NETCore.Native.Wasm.targets（新規、+62行）: WASM向けのリンカー統合を追加
  • Microsoft.NETCore.Native.targets（+19/-10）: WASMをUnix/ELFのリンカー、リンカースクリプト、objcopyによるストリップの経路から外すための調整
  • StripSymbolsはWASMでは無視され、埋め込みデバッグ情報（DWARF）が保持される
  • WASMではデータのdehydrationとマネージドスタックトレースのメタデータをデフォルトでオフにする（相対関数ポインタ形式がWASMのテーブルインデックス型関数ポインタと合わないため）
  • 以下は未サポートとして明示的に拒否される
    • 上記の相対関数ポインタ形式
    • 共有ライブラリ
    • マルチモジュールコンパイル
    • 集約実行ファイル

パフォーマンスへの影響

影響なし（記載なし）

関連Issue

なし

その他

  • 検証は、他の未マージの対応を含むローカルの統合ツリー上で実施されています。
    • BuildIntegration.projのビルド（TargetOS=wasi、TargetArchitecture=wasm）が成功
    • AttributeTrimmingスモークテストが、強制的な再生成と再リンクの後に成功（Wasmtime実行の戻り値は100）
    • StripSymbols=trueでも埋め込みDWARFが残ることを確認
    • SDKのClangが、明示的な-fuse-ldなしでコンポーネントリンカーを選択することを確認
  • このブランチはmainからcherry-pickした単一コミットのみを含み、単独ではビルドされていません。
  • Unixホストとブラウザターゲットはビルド・実行されていません。
  • 説明文はGitHub Copilotにより生成された旨が記載されています。

#135928 [Android] Avoid eager trust-anchor enumeration in certificate-chain builds

概要

Android上での証明書チェーン構築時、AndroidCAStore 全体を列挙して全トラストアンカーを実体化する処理を避け、渡された証明書から特定できるシステムのトラストアンカーのみで PKIXBuilderParameters を構築するよう変更しています。調査対象の Samsung A16 では、この全件列挙のセットアップに約123msかかり、その後のパス構築より大幅に重い処理でした。公開APIの変更はありません。

変更内容

  • マネージド側（Android固有のチェーン処理）
    • ChainPal.Android.cs: 対象証明書と ExtraStore の証明書を現在の AndroidCAStore に照会し、一致するシステムアンカーでPKIXパラメータを構築。ビルド・検証・失効確認・ポリシーチェックのいずれかに失敗した場合は、新規に初期化した全ストアのパラメータでリトライ。使えるアンカーがなければ即座に全ストアを使用。
    • CertificateValidationPal.Android.cs / SslStream.Android.cs: TLSサーバー検証時、プラットフォームのトラストマネージャーが選んだアンカーを一時的なヒントとして同期検証の範囲内で伝搬。アプリケーションの証明書検証コールバック呼び出し前にヒントは除去。
    • Interop.Ssl.cs / Interop.X509Chain.cs: コールバックシグネチャの更新と、トラスト選択・ビルド結果のマーシャリング。
  • ネイティブ/Java側
    • pal_x509chain.c/.h: 対象を絞ったアンカー探索と、新規の全ストア状態でのフォールバックを実装。
    • pal_trust_manager.c/.h、pal_jni.c/.h: ヒントの検証と参照管理、新しいJavaメソッドのバインディング登録、コールバックシグネチャ更新。
    • DotnetProxyTrustManager.java: プラットフォームが選んだサーバーアンカーを転送。
  • テスト
    • ChainTests.cs: アンカーの指定あり/なし、無関係なアンカーからのフォールバック、ポリシー・期限切れ失敗、並行ビルダー、カスタムトラストの分離などを追加。
    • AndroidPlatformTrustTests.cs（および csproj）: コールバック証明書の所有権、ホスト名/ポリシー拒否、カスタムトラスト分離などを追加。

パフォーマンスへの影響

  • 以前のプロトタイプでの計測では、オフラインのシステムトラスト X509Chain.Build の中央値が変更前 169.819ms から変更後 8.166ms に短縮（約95%削減）。
  • 計測環境は Samsung SM-A165F、Android 16/API 36、arm64 CoreCLR、Release/フルトリミング、新規プロセス3回×8サンプル。失効確認と証明書ダウンロードは無効化。
  • ただし上記は初期プロトタイプの数値であり、最終的な3コミット構成での物理デバイス再計測は未実施。この数値は過去の.NETのリグレッション証拠ではなく、全アンカー先行セットアップのコストを示すものです。
  • ビルド間でのトラストストア、ルート証明書、可変なPKIX状態のキャッシュは導入されていません。

関連Issue

  • dotnet/android の Issue #12934（関連）

その他

  • 信頼モデル: TLSヒントは現在のシステムストア内の証明書と独立に一致する必要があり、ヒント単体では信頼を付与しません。PKIX検証とマネージド側のポリシーチェックは独立して維持されます。CustomRootTrust はシステムトラストと分離されたままです。
  • 検証状況: Android arm64 CoreCLR Release でビルドし、API 35 arm64エミュレーターで ChainTests（44件成功、1件は従来どおりスキップ）と AndroidPlatformTrustTests（19件成功）を確認。実機での最終シリーズの再実行は未実施。
  • レビュー指摘（Copilot）: 失効確認が引き金となるフォールバックを直接検証するテストが未追加で、新しいチェッカー/エラー状態と最終的な検証結果を確認する回帰テストの追加が推奨されています（重要度: 低）。

#135847 Flatten NativeAOT reflection metadata namespaces

概要

NativeAOT のリフレクションメタデータにおける名前空間の保持方法を変更するPRです。名前空間を . 区切りのパーツごとのツリー構造で保持する方式をやめ、完全な文字列としてフラットに保持します。あわせて、TypeDefinition / TypeForward をハッシュテーブルに格納することで、型検索のパフォーマンス低下を避ける設計になっています（作成者によると、ハッシュテーブルはパーツ単位の名前空間表現よりも検索で優位になるとのことです）。

変更内容

  • メタデータ形式・生成コード（src/coreclr/tools/Common/Internal/Metadata/NativeFormat/ 配下）
    • SchemaDef.cs、ReaderGen.cs、WriterGen.cs、MdBinaryReaderGen.cs などのジェネレーターを更新し、フラット化した名前空間とスコープ（アセンブリ）単位の型テーブル（ハッシュテーブル）を扱えるようにしています。
    • 生成物である NativeFormatReaderGen.cs、MdBinaryReaderGen.cs が更新されています。
    • MetadataTypeHashingAlgorithms.cs は、フラット化した名前空間名をハッシュするように変更されています。
  • メタデータ書き出し（ILCompiler.MetadataTransform）
    • Transform.Namespace.cs で、名前空間レコードをフラットに作成するように変更されています。
    • Transform.Type.cs で、トップレベル型をスコープに登録するようにしています。
    • Transform.TypeForwarders.cs で、型フォワーダーを転送先の名前空間と関連付けています。
    • NativeMetadataWriter.cs / NativeFormatWriterGen.cs で、テーブルの配置とルックアップ用ハッシュの計算を行います。
  • ランタイム側のリフレクション（System.Private.CoreLib）
    • NamespaceChain.cs を削除し、名前空間チェーンのキャッシュを廃止しています。
    • MetadataReaderExtensions.NativeFormat.cs で、名前空間関連のヘルパーを簡素化しています。
    • NativeFormatRuntimeAssembly.GetTypeCore.CaseSensitive.cs は、ハッシュを使った型検索に変更されています。
    • NativeFormatRuntimeAssembly.GetTypeCore.CaseInsensitive.cs は、スコープのテーブルから辞書を構築する方式に変更されています。
    • NativeFormatRuntimeNamedTypeInfo.cs は、直接スコープを参照し、名前空間文字列をキャッシュします。
    • TypeResolver.NativeFormat.cs は、名前空間スコープを直接解決するようになっています。
  • その他ランタイムコンポーネント
    • System.Private.StackTraceMetadata（MethodNameFormatter.cs、StackTraceMetadata.cs）と System.Private.TypeLoader（MetadataNameExtensions.cs）で、フラット化した名前空間名とスコープを参照するように更新されています。
  • ハッシュ関連
    • VersionResilientHashCode.cs に、文字スパン向けの名前ハッシュ計算が追加されています。
    • ILCompiler.MetadataTransform.csproj に、この共有ハッシュコードが含められています。
  • コンパイラ（メタデータマネージャー）
    • UsageBasedMetadataManager.cs と AnalysisBasedMetadataManager.cs で、未解決の型フォワーダーの保持条件が変更されています。
  • その他
    • CompatibilitySuppressions.xml と System.Private.CoreLib.csproj は、生成型や共有ソースの取り込みに合わせて調整されています。

パフォーマンスへの影響

  • 型の検索はハッシュテーブルに基づくようになり、名前空間のパーツごとのツリーをたどる処理がなくなります。作成者は、この方式でパフォーマンスへの影響を避けられるとしています。
  • 具体的な測定値やベンチマーク結果は提供されていません。Copilot の概要でも、ビルド・テスト・計測は実施されていないと記載されています。

関連Issue

なし

その他

  • 未解決の指摘（Copilot レビュー、重要度 Medium）
    • 転送先アセンブリが存在しない場合に、未解決の型フォワーダーを保持できなくなる退行の可能性が指摘されています（"Preserve unresolved type forwarders when destination assemblies are missing"）。
    • UsageBasedMetadataManager.cs / AnalysisBasedMetadataManager.cs の変更に関係する部分です。
  • レビュー面の注意点
    • メタデータの形式そのものを変更しており、生成コードやリーダー/ライターの両方に影響します。人手による詳細レビューと NativeAOT での検証が必要とされています。

#135776 Allow non-metadata JSON property names with a leading dollar sign

概要

System.Text.Jsonは、参照保持（reference preservation）またはポリモーフィックデシリアライズが有効な場合、メタデータと競合しない名前も含めて$で始まるすべてのプロパティ名を拒否していました。本PRでは既存の「完全一致のメタデータ判定」を利用するよう変更し、認識されたメタデータプロパティ（$id、$ref、$values、$typeなど）は従来どおり検証し、無関係な$始まりの名前は通常のプロパティとして処理します。また、カスタムの型識別子名が設定されている場合、$typeはメタデータではなく通常のプロパティとして扱われます。

変更内容

  • JsonSerializer.Read.HandleMetadata.cs / JsonSerializer.Read.HandlePropertyName.cs / JsonDictionaryConverter.cs: $始まりの名前を一律で拒否していた判定を削除し、完全一致のメタデータ判定を使用するよう変更
  • ThrowHelper.Serialization.cs / Strings.resx: 不要になったスローヘルパーとリソース文字列を削除（計約37行）
  • ReferenceHandling_spec.md: 参照ハンドリングの仕様ドキュメントを更新
  • テスト更新（ReferenceHandlerTests.Deserialize.cs、PolymorphicTests.CustomTypeHierarchies.cs、ConstructorTests.Exceptions.cs）:
    • マップされたプロパティ、辞書キー、拡張データ、パラメータ付きコンストラクタ
    • エスケープされた名前、大文字小文字を区別した一致、順序が前後したメタデータ

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）

関連Issue

#79482（このPRで解決）

その他

  • 互換性: 従来は例外となっていた$始まりのプロパティ名が受け入れられるようになる動作変更です。
  • 作成者によると、DebugおよびReleaseビルドは成功し、シリアライザーとソースジェネレーションの5つのテストプロジェクトが.NETおよび.NET Frameworkの両方で失敗なく通過しています。
  • 本PRはGitHub Copilotを用いて作成されています。

#135763 Support for interface dispatch on native AOT/WASM

概要

NativeAOT/WASM において、インターフェイスメソッド呼び出しを任意シグネチャの RhpInterfaceDispatch スタブ経由ではなく、インターフェイスターゲットを解決したうえで実際のメソッドシグネチャで間接呼び出しする方式に変更します。Console.WriteLine の hello world を WASI/NativeAOT でコンパイル・リンク・実行可能にするための一連の PR の一部です。

  • ILC が CORINFO_VIRTUALCALL_LDVIRTFTN を報告し、具象/ジェネリックのディスパッチセル参照を保持し、null インスタンスチェックを要求します。
  • RyuJIT はレシーバーとセルを CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT に渡します。Wasm ではこれを未対応の高速ヘルパーではなく、既存の固定シグネチャ RhpResolveInterfaceMethod にマップします。
  • 既存のジェネリック仮想メソッドのパスは維持されます。
  • クラス仮想メソッドの ldvirtftn（クラス仮想メソッドにバインドされたデリゲートなど）でも、NativeAOT Wasm の既存の ReadyToRun リゾルバーを有効化します。
  • 非 Wasm の NativeAOT のスタブ選択と CoreCLR Wasm のフォールバックは維持されます。

変更内容

  • src/coreclr/tools/aot/ILCompiler.RyuJit/JitInterface/CorInfoImpl.RyuJit.cs（+12/-5）: Wasm 向けのディスパッチ参照、リゾルバー選択、null チェック要求の切り替え。
  • src/coreclr/jit/importer.cpp（+33/-2）: Wasm のインターフェイス参照のインポート処理を追加。NativeAOT でのクラス仮想 ldvirtftn 解決を有効化。
  • src/coreclr/jit/importercalls.cpp（+5/-1）: 呼び出しインポート側の対応。
  • src/coreclr/jit/gentree.h（+2/-1）、utils.cpp（+1/-0）、valuenum.cpp（+5/-0）、valuenumfuncs.h（+1/-0）: 新しいヘルパーに伴う JIT 内部の対応（値番号関連を含む）。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）。

関連Issue

なし

その他

  • 検証: Wasm JIT、ネイティブ x64 JIT、ILC、crossgen2 のビルドは成功。ローカルの verify-interface-codegen.ps1 で Wasm の 6/6 ケースがコンパイルされ Wasm 検証を通過しました。どのケースも RhpInterfaceDispatch をインポートせず、具象/ジェネリック呼び出しのケースは RhpResolveInterfaceMethod をインポートしました。Windows x64 の対照 6/6 も成功しています。
  • 対象ケースは、具象インターフェイス呼び出し、共有ジェネリックのメソッド/型、インターフェイスのデリゲート、クラス仮想のデリゲートです。ただしこれらはコード生成の確認であり、インターフェイスディスパッチの実行テストではありません。
  • 検証結果は前提となる NativeAOT/Wasm 対応を含むローカルの統合ツリーによるもので、この main ベースの分離ブランチをクリーンビルドしたものではありません。検証スクリプトはローカルのフィクスチャで、この PR に追加されるテストではありません。
  • Copilot レビューの指摘（未解決 3 件）:
    • （高）ジェネリックなインターフェイス参照が失敗した場合の処理がヘルパー構築前に必要。未対応のジェネリック参照でコンパイルがクラッシュする可能性。
    • （中）単独のインターフェイス ldvirtftn にレシーバーの null チェックが必要。
    • （中）クラス仮想 ldvirtftn にレシーバーの null チェックが必要。

#135671 [automated] Merge branch 'release/9.0' => 'release/9.0-staging'

概要

release/9.0 ブランチの未マージ変更を release/9.0-staging に取り込む、自動生成のブランチ間マージPRです（github-actions[bot]作成）。対象コミットの作成者は svick と dotnet-maestro[bot] です。自動マージされないため、チェック通過後に squash/rebase ではなく マージコミットで完了させる必要があります。

変更内容

提供された情報から確認できる範囲の主な変更は以下です（コミット内容そのものの詳細は提供情報にないため、ファイル名と差分量のみに基づきます）。

  • 依存関係・ビルド基盤の更新: NuGet.config、eng/Version.Details.xml（+92/-92）、eng/Versions.props（+42/-42）、global.json、eng/common/ 配下（job.yml、send-to-helix.yml、extract-artifact-packages.ps1 の削除）。dotnet-maestro[bot] による依存関係更新と思われますが、断定はできません。
  • CoreCLR PAL（名前付きMutex/共有メモリ）: Mutex.CoreCLR.Unix.cs、pal.h、pal_error.h、mutex.hpp、sharedmemory.h/.inl、sharedmemory.cpp（+1213/-415）、mutex.cpp、init/pal.cpp が変更され、PALテスト（NamedMutex/test1）も追加されています。Unix上の名前付きMutexおよび共有メモリ実装に大きな変更が入っていることが分かります。
  • System.Formats.Cbor: CborReader の Array/Map/String 各実装、Strings.resx が変更され、リーダー関連のテスト（CborReaderTests.cs、SkipValue）が追加・更新されています。
  • System.Formats.Tar: TarEntry.cs（+94/-107）、Strings.resx、.csproj などが変更されています。
  • HTTP関連テスト: HttpClientHandlerTest.Proxy.cs（+106）と LoopbackProxyServer.cs が変更されています。
  • その他48ファイルが変更されていますが、詳細は提供情報にありません。

パフォーマンスへの影響

提供情報からは判断できません（ベンチマーク結果の記載なし）。

関連Issue

なし

その他

  • 本PRは自動生成されたマージPRであり、新規機能の導入を目的としたものではありません。
  • マージコンフリクトが発生した場合は、GitHub UIまたはコマンドラインで手動解決が必要です。ブランチ merge/release/9.0-to-release/9.0-staging への push で更新できます。
  • 手動マージの手順例:
git fetch
git checkout release/9.0
git pull --ff-only
git checkout release/9.0-staging
git pull --ff-only
git merge --no-ff release/9.0
git push https://github.com/dotnet/runtime HEAD:merge/release/9.0-to-release/9.0-staging
  • 問題があれば .NET Core Engineering (dotnet/dnceng) に連絡してください。

#135670 [automated] Merge branch 'release/8.0' => 'release/8.0-staging'

概要

release/8.0 ブランチの未マージのコミットを release/8.0-staging へ取り込む、github-actions[bot] による自動ブランチ間マージPRです。対象コミットの作成者は svick と dotnet-maestro[bot] です。PRの説明に基づくと、このPRは自動マージされず、チェック通過後にsquash/rebaseではなくマージコミットで完了させる必要があります。

変更内容

PRの説明には個別の変更内容の記載がないため、変更ファイル一覧から確認できる範囲のみ記載します（変更ファイルの総数は約79ファイル、うち約30件のみ提供情報に含まれます）。

  • 依存関係・ビルド設定: NuGet.config、eng/Version.Details.xml、eng/Versions.props
  • CoreCLR PAL（名前付きMutex／共有メモリ）:
    • src/coreclr/pal/inc/pal.h、src/coreclr/pal/src/include/pal/mutex.hpp
    • src/coreclr/pal/src/include/pal/sharedmemory.h、sharedmemory.inl（sharedmemory.inl は21行削除）
    • src/coreclr/pal/src/sharedmemory/sharedmemory.cpp（+1107/-241）
    • src/coreclr/pal/src/synchobj/mutex.cpp（+225/-63）
    • テスト: src/coreclr/pal/tests/palsuite/threading/NamedMutex/test1/namedmutex.cpp、nopal.cpp（新規）
  • CoreCLR VM: src/coreclr/vm/qcallentrypoints.cpp（+2）
  • System.Net.Http テスト: HttpClientHandlerTest.Proxy.cs（+106）、LoopbackProxyServer.cs
  • System.Formats.Cbor: Strings.resx、.csproj、CborReader.Array.cs、CborReader.Map.cs、CborReader.String.cs、CborReader.cs（+33）と、関連テスト（CborReaderTests.SkipValue.cs、CborReaderTests.cs）
  • System.Formats.Tar: Strings.resx、.csproj、TarEntry.cs、TarFile.cs、TarHelpers.Unix.cs、TarHelpers.Windows.cs、TarHelpers.cs（+329）と、TarFile.ExtractToDirectory.File.Tests.cs などのテスト
  • 上記以外に49ファイルの変更あり（詳細は提供情報に含まれません）

パフォーマンスへの影響

影響なし（提供情報にはベンチマーク結果や性能に関する記載はありません）。

関連Issue

なし

その他

  • 提供情報からは、各変更の具体的な目的（セキュリティ修正かどうか、CVE番号など）や公開APIへの影響、互換性への影響は確認できません。
  • マージ時にコンフリクトが発生した場合は、merge/release/8.0-to-release/8.0-staging ブランチに直接pushして解消できます。
  • このPRの内容は、元の release/8.0 上のコミットを確認しないと正確には把握できません。

#135638 JIT: make sure the block a catch returns to generates an instruction

概要

catchブロックの終了時にスレッド中断（ThreadAbort）が保留されている場合、ランタイムはcatchの戻り先アドレスから中断を再送出し、そのアドレスに対応するハンドラを検索します。JITはこの戻り先ブロックを関連するEH領域内に配置していますが、そのブロックがコード生成上で命令を1つも出力しない場合、戻り先アドレスが後続コードに属してしまい、abortが誤った位置から発生したものとして扱われます。

この問題は、未最適化コード（tier 0、JITMinOpts、デバッグ可能コード）と、一部の最適化コード（GC.KeepAliveのみのブロック、try領域の先頭ブロック、xarchでのemitRemoveJumpToNextInstによるジャンプ除去など）で発生します。その結果、finallyが実行されない、外側のcatchがabortを受け取れない、catch直後のtryが誤って捕捉する、といった誤動作が起きます。

本PRは genEmitEndBlock で、catchの戻り先となる BBJ_ALWAYS ブロックが命令を出力していない場合、次ブロックへのジャンプが省略されるなら nop を出力し、そうでなければジャンプを削除可能としてマークしないようにします。判定は次ブロックのEH領域には依存しません。

変更内容

  • src/coreclr/jit/codegen.h: 宣言の追加（+1）
  • src/coreclr/jit/codegenlinear.cpp: genEmitEndBlock に、catch戻り先ブロックが命令を生成することを保証するロジックを追加（+53/-2）
  • src/tests/Regressions/coreclr/GitHub_135637/test135637.cs: 6つの再現シェイプ（CatchThenFinally、LeaveOutOfOuterTry、ConsecutiveTry、KeepAliveAfterCatch、KeepAliveThenFinally、CatchInLoop）を持つ回帰テストの追加
  • src/tests/Regressions/coreclr/GitHub_135637/test135637.csproj: テストプロジェクトの追加
  • インタプリタ上ではabort関連の別問題（#135871）のため、[ActiveIssue]でスキップ

パフォーマンスへの影響

実行速度の変化に関する計測は記載されていませんが、コードサイズがわずかに増加します。

  • SuperPMI asm diff（linux-x64）: 3,267,793コンテキスト中1,591が変化し、MinOpts +2,659バイト、FullOpts +10バイト（合計 +2,669バイト）
  • linux-arm64: 3,124,627コンテキスト中1,488が変化し、合計 +8,828バイト（arm64ではnopは4バイト）
  • browser-wasm: コードサイズ変化なし
  • tier 0のコードサイズ（ReadyToRun=0）: 安定して比較できた2,468メソッドのうち4メソッドが増加（多くは1バイト）。TieredCompilation=0では958メソッドに変化なし

関連Issue

  • #135637（Resolves）
  • #135871（インタプリタ上でのテストスキップ理由）
  • 参考: #135531（Windows上のCETシャドウスタック環境でテスト実行に必要、マージ済み）、#135520、#135463

その他

  • 診断用のローカルツール（本PRには含まれない）で、catch戻り先アドレスとtry/handler範囲の不一致を検出しています。linux-x64のSuperPMIコレクション再生で、現行JITでは2,421件（未最適化2,411件、最適化10件）の不一致が記録されましたが、本変更後は0件です。
  • 以前のリビジョンで試みた fgOptimizeEmptyBlock の GT_NO_OP 削除は、Wasm crossgenで失敗したため取り下げられています。
  • 作成者による注記として、本PRはAI（Anthropic Claude、OpenAI Codexによる確認）の支援で作成され、作成者が変更・テスト・計測結果をレビュー済みとされています。

#135543 [wasm] Regalloc: Allow Non-exposed GC Ref Locals to Live in Wasm Locals

概要

WebAssembly (Wasm) 向けJITのレジスタ割り当てにおいて、GCセーフポイントをまたいで生存しない（GCから見える必要のない）追跡対象のGC参照ローカル変数を、固定されたスタックスロットではなくWasmの local に割り当て可能にする変更です。セーフポイントでライブなGC参照ローカルは従来どおり固定スタックホームを使用します。そのために、GC参照ローカルの生存解析を行う独立したフェーズ（WasmGCLiveness）を新設し、後続の2つのフェーズがその結果を利用します。

変更内容

  • src/coreclr/jit/fgwasm.cpp: GC参照ローカルがセーフポイントでライブかを判定する解析を実装し、Wasm local に割り当て可能な候補集合を算出。fgWasmSpillRefs も更新し、「ローカル由来の一時的なツリー値がcallをまたいで生存する」ケースでは固定スタックスロットを引き続き使用するよう対応
  • src/coreclr/jit/regallocwasm.cpp: 候補集合に含まれるGC参照ローカルを、レジスタ割り当て（Wasm local ホーム）の対象として許可
  • src/coreclr/jit/compiler.cpp / compiler.h / compphases.h / compmemkind.h: 新フェーズの登録・呼び出し、候補集合の保持、メモリ種別の追加
  • src/tests/JIT/Directed/WasmGCLiveness/WasmGCLiveness.cs / .csproj: GC生存性の正しさを検証するテストシナリオを追加（finally/EH をまたぐ生存、スタック/レジスタホーム混在など）

技術的な注意点（作成者の記述より）:

  • 例外をスローし得るLIRノード（null チェック、ゼロ除算チェック、範囲チェック等）を考慮して解析する
  • 参照がローカルに保持されていても、GCが発生し得るのがスロー経路のみで、かつその地点のハンドラにライブでなければ、GCには露出しないものとして扱う
  • 影響範囲は内部のJIT（コンパイラ）実装で、公開APIの変更や互換性への影響の記載はなし

パフォーマンスへの影響

SPMI（生成コードサイズ）:

  • 差分: -549,758/+1,245 バイト（16,424件でサイズ改善、205件で悪化）
  • 合計: -548,513 バイト（ベースの -6.41%）

ローカルベンチマーク（CoreCLR composite R2R、ベースライン比）:

  • モバイル コールドスタートアップ: 7,228 ms → 6,539 ms（9.5% 高速化）
  • デスクトップ ウォークスルー: 5.95 s → 5.56 s（6.6% 高速化）
  • デスクトップ コールドダウンロード: 10.323 MB → 10.138 MB（1.8% 縮小）
  • アプリ publish: 151.89 s → 147.84 s（2.7% 高速化）

なお、Mono（インタプリタ）ベースラインとの比較では、スタートアップや publish は依然として遅い／大きい結果です。

関連Issue

なし

その他

  • 検証: 新規の WasmGCLiveness テストは通過。ただし、GCにオブジェクトを移動させて不具合を検出するのは難しく、Wasm向けGC Stressがあれば有用になりうると作成者は述べています。一部のケース（finally/EH をまたぐ生存、スタック/レジスタホーム混在など）は、JITダンプを手動で確認し、パスが期待どおり動作することを確認済みです
  • Copilotレビューの指摘（未解決3件）:
    • 中: テストが「対象の参照が実際にWasm localホームに割り当てられた」ことを自動検証していないため、コード生成に関するアサーションの追加が推奨されている
    • 低: コメント中の「liveness」のスペル修正
    • 低: ビルドコマンド内の WasmGcLiveness のパスの大文字小文字の修正

#135438 [mono][aot] Fix recursive struct wrapper normalization

概要

Mono AOT（mono-aot-cross）が gsharedvt ラッパーのシグネチャを構築する際、値型フィールドやジェネリック型引数を再帰的に正規化します。get_wrapper_shared_vtype() と get_wrapper_shared_type_full() が相互に呼び合い、自己再帰的なジェネリック値型でネイティブスタックオーバーフローが発生する問題を修正します。#135029 を #135371 でリバートした後の再導入で、回帰テストを修正しています。

問題となる有効な型の例:

struct GenericFieldBox<T>
{
    public object Value;
}

struct SelfRecursive
{
    public GenericFieldBox<SelfRecursive> Value;
}

修正では、正規化中の値型をスタック上のチェーンとして保持します。同じ型への再入、または各レベルで形状が成長するジェネリックで深さ上限に達した場合は、既存の「元の型を維持する」フォールバックを使います。

変更内容

  • src/mono/mono/mini/mini-generic-sharing.c（+39/-10）: 正規化中の値型チェーンを持ち回り、再入・深さ上限でフォールバックさせる再帰防止の修正。
  • src/libraries/System.Runtime/tests/System.Runtime.Tests/System/ValueTypeTests.cs（+23/-0）: 自己再帰的ジェネリック値型の回帰テストを追加（ヘルパー型は private）。
    • 前回のテストは A/B が GenericFieldBox<B>/GenericFieldBox<A> を相互参照する形でした。CoreCLR がこのメタデータを TypeLoadException で拒否し、WASI・Firefox・Android・iOS で #135348 が発生していました。今回はこの無効な相互再帰形を削除し、Mono AOT の失敗を再現する有効な自己再帰形のみを使用します。
  • 影響範囲: Mono AOT コンパイラの内部実装（公開APIの変更なし）。

パフォーマンスへの影響

影響なし（実行時パフォーマンスに関する変更や計測は記載なし）。

関連Issue

  • Resolves #132071
  • 関連: #135029（元の修正）、#135371（リバート）、#135348（CoreCLR の TypeLoadException による CI 失敗）

その他

検証結果（PR記載の内容）:

  • リバート後の main の mono-aot-cross では、変更後の System.Runtime.Tests.dll のコンパイルが 0xC00000FD（スタックオーバーフロー）で失敗し、パッチ適用後は成功（28,452/29,246 メソッドをコンパイル）。
  • Mono browser のインタープリタおよび AOT（Chrome）で System.Tests.ValueTypeTests が 23/23 パス。
  • #132071 の Blazor 再現ケースも、アプリアセンブリと dedup aot-instances.dll の両方でコンパイル成功。

#135296 [wasm] [spmi] Collect SPMI contexts from libraries via crossgen2

概要

WASM向けのSuperPMIコレクションを、従来のCoreLibのみから、ライブラリアセンブリ全体のcomposite crossgen2コンパイルへ拡張するPRです。#132538（@AndyAyersMS）の継続で、主な変更はレビュー指摘への対応とのことです。これによりWasm向けのメソッドコンテキスト数を大幅に増やすことを狙っています。JIT-EEのGUIDを更新し、旧corelibコレクションではなく新しいコレクションが使われるようにしています。

変更内容

  • src/coreclr/scripts/superpmi.py（+182/-17）: composite crossgen2コンパイルによるコレクションを実装
  • src/coreclr/scripts/superpmi_collect_setup.py（+80/-23）: WASMのランタイムパックのアセンブリをステージング・分割
  • src/coreclr/scripts/superpmi-collect.proj（+18/-0）: composite関連オプションとターゲット参照を渡す設定を追加
  • src/coreclr/scripts/superpmi-replay.proj: WASMのコレクション参照を更新
  • src/coreclr/inc/jiteeversionguid.h: JIT-EE GUIDを更新
  • eng/pipelines/coreclr/templates/ 配下4ファイル（run-superpmi-collect-job.yml、superpmi-collect-job.yml、superpmi-collect-pipeline.yml、superpmi-send-to-helix.yml）: WASMランタイムパックのビルドとコレクション、アーティファクト依存関係、命名、タイムアウト、新しい設定のHelixへの転送を更新

検証状況（作成者のチェックリストより）:

  • 新しいコレクションが適切なサイズで、ローカルのsuperpmi.py replayでクリーンにリプレイされる
  • FullOptsの変更を含むJITに対して実行した際に、適切なasmdiffsが得られる

パフォーマンスへの影響

影響なし（SuperPMIの収集・リプレイ基盤の変更であり、ランタイムの実行性能に関する変更は提供情報にありません）。ベンチマーク結果の記載もありません。

関連Issue

  • #132538（本PRの前身となるPull Request）

その他

  • 公開APIや互換性への影響に関する記載はなく、変更はテスト/ツーリング基盤（スクリプトとパイプライン）が中心です。
  • JIT-EEバージョンGUIDの更新により、旧corelibコレクションから新しいコレクションへ切り替わります。
  • Copilotのレビューでは、削除済みのJitWasmNyiToR2RUnsupportedオプションが復活しており、現在のWASM JITの挙動と矛盾し機能しない、という低重大度の指摘（"Remove obsolete JIT WASM NYI fallback options"）が1件出ています（要修正）。

#135291 [wasm][R2R] Skip methods with explicit tail calls in crossgen2

概要

WebAssembly (wasm) の R2R コードでは、明示的な tail. 呼び出しが return_call になります。しかし R2R とインタプリタ間の遷移は通常の呼び出しを使うため、フレームが蓄積され、これらをまたぐ深い末尾再帰でスタックオーバーフローが発生します。

この PR では、crossgen2 が明示的な tail call を含む wasm メソッドを拒否するようにしました。reportTailCallDecision から RequiresRuntimeJitException を送出します（R2R のみ）。該当メソッドは、tail call を扱えるインタプリタに任されます。

変更内容

  • src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs: wasm R2R で明示的 tail call を含むメソッドを拒否する処理を追加（+8/-0）
  • src/tests/JIT/Directed/tailcall/more_tailcalls.ilproj: R2R 非互換マーカーを削除（+0/-2）
  • src/tests/JIT/Directed/tailcall/mutual_recursion.fs: wasm R2R のテスト除外を解除（+0/-1）
  • src/tests/JIT/Regression_3/devdiv_902271/DevDiv_902271.il: 解決済みのテスト除外を削除（+0/-5）
  • これにより DevDiv_902271、more_tailcalls、mutual_recursion が再度有効化されます。

パフォーマンスへの影響

R2R のカバレッジが低下します。FSharp.Core のメソッドの約 11%（約 12.1k 中 1,324）がインタプリタで実行されることになります。実行速度への定量的な影響（ベンチマーク）は提供されていません。

根本的な修正には、tail call を保持する遷移が必要とのことです。thunk のみの変更では不十分で、SP の復元と戻り値のロードのために thunk がスタック上に残る必要があるためです。

関連Issue

  • #133467（この PR で解決）
  • #135292（NativeAOT の regalloc assert。本 PR の対象外）
  • #135293（上記の修正 PR）

その他

  • NativeAOT は今回のバイルアウトの対象外です。
  • Copilot のレビューでは、指摘事項なし（承認推奨）とされています。

#130935 Remove target and target-dependent ifdefs from dbi

  • 作成者: @rcj1
  • 作成日時: 2026年07月17日 00:07:17(UTC)
  • マージ日時: 2026年10月21日 18:17:13(UTC)
  • ラベル: area-Diagnostics-coreclr

概要

DBI（Debugger Interface）に残っていた TARGET_* ifdef を除去する変更です。ifdef は次の4種類に分類されています。

  • 本来はホスト側の条件であるもの：HOST_* に変更
  • 実際にターゲット情報を表すもの：新規 DacDbi API GetTargetInfo で実行時に取得
  • ライブデバッグ（ホストとターゲットが同一）：HOST_* に変更
  • レジスタ／コンテキスト関連：別PR #130367 で対応

IDacDbiInterface::GetTargetInfo（アーキテクチャ・OS・ポインタサイズ）を IDL／ヘッダ／DAC 実装／cDAC Legacy のマネージド実装に追加し、RS/shim 側でこれを使って分岐するようになります。

変更内容

  • API 追加: dacdbi.idl、dacdbiinterface.h、dacdbiimpl.cpp/.h に TargetInfo 構造体（arch/os/pointerSize）と GetTargetInfo を追加。cDAC 側は DacDbiImpl.cs / IDacDbiInterface.cs で IRuntimeInfo を用いて実装し、DacDbiImplTests.cs にテストを追加。
  • process.cpp: CordbProcess::GetTargetInfo（結果をキャッシュし DAC を呼び出す）を追加。一部 TARGET_* を HOST_* に変更。
  • rsthread.cpp（最大の変更）: フレーム照合、ハイジャック、FP レジスタ、引数ウォークなど多数の TARGET_* ifdef を、ターゲット情報に基づく実行時分岐に置換。
  • valuehome.cpp / shimstackwalk.cpp: TARGET_64BIT・TARGET_ARM* の条件を実行時のターゲット情報による判定に置換。
  • shimlocaldatatarget.cpp / module.cpp / rsmain.cpp / cordb.cpp / platformspecific.cpp: TARGET_* を HOST_* に変更。
  • shimremotedatatarget.cpp / shimdatatarget.h / shimprocess.cpp / shimpriv.h: ShimProcess へのバックポインタを追加。GetPlatform をターゲット情報ベースに変更（Copilot の指摘によると最新版では E_NOTIMPL を返す）。ARM64 の proc-mem 回避策は HOST_ARM64 に変更。
  • rstype.cpp / rspriv.h: CordbType::RequiresAlign8 を FEATURE_64BIT_ALIGNMENT ガードなしにし、AlignAddressForType も無条件に呼び出す形に変更。
  • daccess.cpp: ICorDebugDataTarget::GetPlatform と DAC ビルドのプラットフォームを比較する不一致チェックを削除。
  • ビルド／エクスポート: clrfeatures.cmake、mscordbi.src を変更。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載もありません）。GetTargetInfo の結果は CordbProcess にキャッシュされるため、DAC 呼び出しは毎回発生しない設計です。

関連Issue

関連PR: #130367（レジスタ／コンテキスト関連の ifdef 対応）。関連Issueの記載はなし。

その他

Copilot レビューで、未解決の指摘が7件（いずれも High）残っています。

  • 転送（transport）関連の宣言・実装・通知検証の条件が、ホスト／ターゲットのどちら側向けかという区別を失っている。クロスビルド向けの左側（left-side）宣言や実装ガードの維持が必要。
  • タグ付きポインタの除去は、ホストではなくターゲットアーキテクチャに基づくべき。
  • ブレークポイント命令は、クロスアーキテクチャのデバッグに備えてターゲット固有のオペコードを使うべき。

その他の懸念点（レビュー中に指摘された内容。後続コミットで対応済みかは未確認）:

  • daccess.cpp の不一致チェック削除により、DAC とターゲットの不整合が明確なエラーではなく、後で分かりにくいメモリ読み取り失敗として現れる可能性。
  • ShimRemoteDataTarget::GetPlatform が E_NOTIMPL を返す場合、GetPlatform に依存するリモート側のポインタサイズ取得が失敗する可能性。
  • RestoreLeafSeh は x86 ターゲット向けの処理だが、ホストのポインタ幅（REMOTE_PTR）で書き込むため、ポインタサイズのガードが必要。
  • AlignAddressForType が RequiresAlign8 を無条件に呼ぶため、FEATURE_64BIT_ALIGNMENT 非対応のターゲットでは DAC 側が E_NOTIMPL を投げ、IfFailThrow で意図しない例外になる恐れ。
  • cDAC の GetTargetInfo は、途中で例外が発生すると出力構造体が部分的に更新されたままになる可能性。

#130717 JIT: Materialize partially-constant Vector.Create as CNS_VEC + inserts

概要

JITのlowering（LowerHWIntrinsicCreate）において、一部の要素のみが定数である Vector*.Create(...) を、従来の「CreateScalarUnsafe から始まる insert の連鎖」ではなく、CNS_VEC（定数ベクタ）＋非定数要素の WithElement 挿入として具体化するよう変更しています。 例えば Vector128.Create(1, 2, 3, x) は、従来は4回の insert でしたが、変更後は CNS_VEC と x 用の WithElement 1回になります。

// 変更後: 定数部分は CNS_VEC、x のみ WithElement で挿入される
Vector128<int> v = Vector128.Create(1, 2, 3, x);

変更内容

  • src/coreclr/jit/gentree.h: GenTreeVecCon::IsHWIntrinsicCreateConstant が、どの要素が定数かを simdmask_t で任意に返せるよう拡張
  • src/coreclr/jit/lower.cpp: 共有ヘルパー NonZeroConstantElementCount（非ゼロ定数の個数の判定）と LowerHWIntrinsicCreateWithInserts（CNS_VEC を作り、非定数オペランドのみ WithElement/プラットフォーム固有の insert で埋める処理）を追加
  • src/coreclr/jit/lower.h: 上記メソッドの宣言を追加
  • src/coreclr/jit/lowerxarch.cpp / lowerarmarch.cpp: 128ビットレーン向けの LowerHWIntrinsicCreate に新パスを組み込み

適用条件・設計上のポイント

  • 非ゼロ定数のオペランドが2つ以上ある場合のみ適用。ゼロのレーンは既存の insert パス（insertps のゼロマスク、CreateScalarUnsafe のゼロ拡張）で無償で生成できるため、定数化するとかえって命令が増えるためです（例: Vector4.Create(a, b, 0, 0) は従来どおり insertps 2回のままで退行なし）。
  • より大きなベクタは、ベースケースに到達する前に128ビットレーン単位の Create に分割されるため、レーンごとに適用されます。全て定数のレーンは CNS_VEC になり、WithUpper/WithLower で結合されます。

パフォーマンスへの影響

SuperPMI asmdiffs（windows x64、2,596,354 コンテキスト）で、全体で -806 バイト、退行なし。

コレクション 差分
benchmarks.run_pgo -327
coreclr_tests.run -456
libraries.crossgen2 -12
libraries_tests_no_tiered_compilation -11

主な改善:

  • System.Buffers.Text.Base64Helper:Avx2Encode: -290 バイト（-25.33%）
  • GitHub_43569.Program:Vector128_Create_byte: -155 バイト（-42.12%）
  • GitHub_43569.Program:Vector256_Create_float / Vector128_Create_float: 各 -21 バイト

コードサイズ（生成命令の削減）の改善であり、実行速度やスループットのベンチマーク結果は提示されていません。

関連Issue

なし

その他

  • 正当性は、全ての基本型・ベクタサイズ、非定数要素の位置を変えたケースで、Checked アサート有効、ISA 構成（AVX512/AVX2/AVX 無効）、JitStress=2 の条件下で検証されたとのことです。
  • Copilot によるレビューでは、5ファイルすべてが確認され、指摘コメントが生成されています（具体的な内容は提供情報に含まれていません）。
  • PR説明は GitHub Copilot の支援で作成されたと記載されています。
目次