Pull Request on 2026年01月13日

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

注意点

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


目次

  1. #123150 Merging internal commits for release/8.0
  2. #123149 Merging internal commits for release/9.0
  3. #123134 Add null validation for relativeUri in Uri(Uri, Uri) constructor
  4. #123128 JIT: Fix build after two conflicting changes
  5. #123114 [manual] Merge release/8.0-staging into release/8.0
  6. #123113 [manual] Merge release/9.0-staging into release/9.0
  7. #123107 [release/10.0] Source code updates from dotnet/dotnet
  8. #123106 Update to draft 14 of Composite ML-DSA
  9. #123100 [main] Source code updates from dotnet/dotnet
  10. #123099 [RyuJit/WASM] Add stackification algorithm skeleton
  11. #123088 Fix Regex.Escape to not escape vertical tab and add comprehensive tests
  12. #123060 Use System.Runtime.InteropServices.Marshalling.ComVariant instead of custom VARIANT types in libraries
  13. #123057 Fix up hijacking on arm32 (preserve async continuation register)
  14. #123055 fix ntlm tests on platforms with broken gssapi
  15. #123052 Implement support for ExtendedLayoutKind.CUnion
  16. #123046 [clr-interp] Async Resume stubs are exclusive to the JIT as they use a set of intrinsics that are JIT specific
  17. #122841 Fix JsonNode.GetPath() to properly escape characters in property names
  18. #122838 Fix JsonSerializer.Serialize producing invalid JSON for [JsonExtensionData] with JsonObject
  19. #122746 [release/8.0] Update dependencies from dotnet/emsdk
  20. #122698 [main] Update dependencies from dotnet/xharness
  21. #122668 Fix CharSearchValuesPolyfill._ascii array size from 8 to 4 elements
  22. #122639 Generate calls to interface methods through resolve helper
  23. #122569 Handle OpenSSL config errors gracefully in DetectCiphersuiteConfiguration
  24. #122406 Fix GetFileAccessFromRights bitwise logic for compound FileSystemRights flags
  25. #122381 Fix impGetNodeAddr flag handling for volatile, unaligned, and initclass accesses
  26. #122268 [automated] Merge branch 'release/9.0' => 'release/9.0-staging'
  27. #122263 Optimize more bound checks around logical operators
  28. #122023 JIT: Devirtualize non-shared generic virtual methods
  29. #121527 [Bounds checks] Merge inter-block assertions in RangeCheck::MergeAssertion
  30. #120910 Fix KeyValuePair nullability detection on Mono

#123150 Merging internal commits for release/8.0

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年01月13日 19:50:58(UTC)
  • マージ日時: 2026年01月13日 21:31:19(UTC)
  • ラベル: NO-SQUASH Servicing-approved area-codeflow

概要

このPull Requestは、release/8.0ブランチへの内部コミットのマージ作業です。具体的な変更ファイルや詳細情報が提供されていないため、リリース準備に関連する内部的なメンテナンス作業と考えられます。

変更内容

変更ファイルの情報が利用できません。

パフォーマンスへの影響

情報不足のため判断不可

関連Issue

なし

その他

  • 作成者による概要説明がないため、詳細な背景は不明
  • Copilotによるファイルレビューも実施されていない状態
  • 詳細な変更内容を確認するには、Pull Request自体の詳細ページを参照する必要があります

#123149 Merging internal commits for release/9.0

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年01月13日 19:38:39(UTC)
  • マージ日時: 2026年01月13日 21:35:04(UTC)
  • ラベル: NO-SQUASH Servicing-approved area-codeflow

概要

このPull Requestは、dotnet/runtime リポジトリの release/9.0 ブランチ向けの内部コミットのマージです。ただし、詳細な変更内容は提供されていません。

変更内容

変更されたファイルの情報が利用できません。Copilotが分析可能なファイルがなかったため、具体的な変更内容を特定できません。

パフォーマンスへの影響

不明(変更内容が未提供のため判定不可)

関連Issue

なし

その他

  • 本PR は内部コミットのマージ目的であり、詳細情報が限定的です
  • レビュアーはcopilot-pull-request-reviewer[bot]およびjeffhandleyです
  • 変更ファイルの情報が記載されていないため、具体的な影響範囲を判断できません

#123134 Add null validation for relativeUri in Uri(Uri, Uri) constructor

  • 作成者: @Copilot
  • 作成日時: 2026年01月13日 15:43:07(UTC)
  • マージ日時: 2026年01月13日 19:07:24(UTC)
  • ラベル: area-System.Net

概要

Uri(Uri, Uri) コンストラクタが null の relativeUri パラメータを渡された際に NullReferenceException を投げる代わりに、適切に ArgumentNullException を投げるようにバグを修正しました。パラメータ検証時に例外が発生するようになり、デバッグ体験が向上します。

// 修正後: ArgumentNullException が即座に投げられる
Uri baseUri = new Uri("http://localhost/");
Uri result = new Uri(baseUri, (Uri)null);  // ArgumentNullException with parameter name "relativeUri"

変更内容

  • Uri.cs (Line 598): relativeUri パラメータに対して ArgumentNullException.ThrowIfNull(relativeUri) を追加。既存の baseUri パラメータ検証の直後に配置
  • UriParameterValidationTest.cs: テストケース Uri_Ctor_NullRelativeUri_ThrowsArgumentNullException を追加。AssertExtensions.Throws を使用して例外型とパラメータ名の両方を検証

パフォーマンスへの影響

影響なし。単一行の null チェック(パラメータ検証)がコンストラクタ入口時に追加されるだけです。有効な入力に対する動作変更はありません。

関連Issue

なし

その他

  • 互換性への懸念点: 既存コードが誤って NullReferenceException をキャッチしている場合、例外型が変わるため影響を受ける可能性があります。ただし、正当なエラー処理では ArgumentNullException を予期すべき箇所なため、これは潜在的なバグの発見につながります。
  • テスト戦略: 他のテストファイル(UriBuilderTests.cs、UriEscapingTest.cs など)と同じパターンに従い、強力な検証を実現しています。

#123128 JIT: Fix build after two conflicting changes

  • 作成者: @jakobbotsch
  • 作成日時: 2026年01月13日 15:01:31(UTC)
  • マージ日時: 2026年01月13日 15:25:46(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT コンパイラの関数シグネチャ変更に伴う呼び出し側の不整合を修正するパッチです。impGetNodeAddr 関数のシグネチャが #122381 で変更されましたが、#122167 で導入された呼び出しサイト impImportAndPushBoxForNullable が更新されていなかったため、ビルドが失敗していました。新しい allowedMustPreserveIndirFlags パラメータに GTF_IND_INITCLASS フラグを指定することで、nullable 型のボックス化時に initclass フラグの保持を許可するよう修正されました。

変更内容

  • src/coreclr/jit/importer.cpp: impImportAndPushBoxForNullable 内の impGetNodeAddr 呼び出しに allowedMustPreserveIndirFlags パラメータ (GTF_IND_INITCLASS) を追加
  • ボックス化処理では initclass フラグを保持できるが、volatile/unaligned フラグは保持できないことを説明するコメントを追加

パフォーマンスへの影響

影響なし。本変更はビルド エラーの修正であり、既存の機能を調整するものです。

関連Issue

  • #122381(関連:impGetNodeAddr シグネチャ変更)
  • #122167(関連:新しい呼び出しサイト導入)

その他

なし


#123114 [manual] Merge release/8.0-staging into release/8.0

  • 作成者: @jeffhandley
  • 作成日時: 2026年01月13日 01:50:04(UTC)
  • マージ日時: 2026年01月13日 23:00:57(UTC)
  • ラベル: NO-SQUASH Servicing-approved area-Infrastructure linkable-framework

概要

release/8.0-stagingをrelease/8.0にマージするメンテナンスPRです。主にバージョン情報、ビルドスクリプト、パイプライン設定、およびSystem.Net.HttpストレステストのDockerfile関連の更新が含まれています。OOB(Out-of-Band)パッケージの<GeneratePackageOnBuild>フラグのリセットは不要でした。

変更内容

  • バージョン管理: eng/Version.Details.xmlおよびeng/Versions.propsの更新(依存関係やバージョン番号の同期)
  • Dockerビルドスクリプト: build-docker-sdk.ps1/sh、各Dockerfile(Linux/Windows SDK)の改善
  • ビルドパイプライン: 複数のYAML設定ファイル(evaluate-paths-job.yml、global-build-job.yml、xplat-setup.yml等)の調整
  • Helix キュー設定: coreclr/librariesの両方で設定更新
  • System.Net.Httpストレステスト:
    • Docker Compose対応スクリプト追加(build-local.ps1/sh、run-docker-compose.ps1/sh)
    • HttpStress設定・Dockerfile・csprojの更新
    • Program.csの大幅変更(113行追加/77行削除)
  • JIT ヘルパー: amd64/jithelpers_fastwritebarriers.Sのアセンブリコード(行番号変更のみ)
  • ランタイム依存関係: openSUSE/SLES向けインストーラー設定の微調整

パフォーマンスへの影響

影響なし。本PRはメンテナンス・同期目的であり、パフォーマンス最適化やアルゴリズム変更は含まれていません。ストレステスト基盤の改善(Docker Compose対応)により、テスト環境のセットアップが効率化される可能性があります。

関連Issue

なし

その他

  • 性質: release branchのマージであるため、審査目的の自動化PR(copilot-pull-request-reviewerが関与)
  • 互換性: 破壊的変更なし。主にビルドチェーン・テストインフラの更新
  • 含まれる変更ファイル総数: 41ファイル

#123113 [manual] Merge release/9.0-staging into release/9.0

  • 作成者: @jeffhandley
  • 作成日時: 2026年01月13日 01:41:57(UTC)
  • マージ日時: 2026年01月13日 20:25:41(UTC)
  • ラベル: NO-SQUASH Servicing-approved area-Infrastructure linkable-framework

概要

このプルリクエストは、dotnet/runtimeのrelease/9.0-stagingブランチをrelease/9.0ブランチへマージする定期的なリリース統合です。バージョン番号の更新、ビルド設定の調整、およびいくつかの技術的改善が含まれています。主な変更はバージョン管理ファイルとビルドパイプライン設定の更新です。

変更内容

バージョン・依存関係の更新:

  • eng/Version.Details.xml:NuGetパッケージ依存関係の更新(88行)
  • eng/Versions.props:バージョン管理の同期(39行)
  • global.json:.NET SDKバージョンの更新

パイプライン・ビルド構成の改善:

  • eng/pipelines/coreclr/templates/helix-queues-setup.yml:テストキュー設定の更新
  • eng/common/tools.ps1:ツール初期化スクリプトの改善
  • 複数のパイプラインテンプレートにおけるCI/CDワークフロー調整

ランタイム関連の修正:

  • src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEngine.Unix.cs:Unix環境でのソケット非同期処理の最適化(38行追加)
  • src/libraries/System.Private.CoreLib/src/System/Threading/ThreadPoolWorkQueue.cs:スレッドプール作業キューの実装改善(77行追加、226行削除)
  • src/coreclr/tools/aot/ILCompiler.Trimming.Tests/TestCasesRunner/ResultChecker.cs:AOTコンパイラテスト検証ロジックの強化

パフォーマンスへの影響

スレッドプール関連の改善: ThreadPoolWorkQueue.csにおける大幅な実装変更(149行の削減)により、スレッドプール管理の効率化が期待されます。これは作業キューの処理オーバーヘッド削減につながる可能性があります。

ソケット非同期処理の最適化: SocketAsyncEngine.Unix.csへの変更により、Unix/Linux環境でのネットワークI/O操作のパフォーマンス改善が見込まれます。

具体的なベンチマーク結果は提供されていないため、影響の詳細は不明です。

関連Issue

なし

その他

  • このマージはリリースブランチ間の定期的な統合のため、互換性に関わる破壊的変更は含まれていないと考えられます
  • libunwindの新しいバージョンファイルが追加されており、アンワインド機能の更新が実施されています
  • AOTコンパイラのテストロジック強化により、トリミング動作の検証がより堅牢になります

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月12日 22:54:35(UTC)
  • マージ日時: 2026年01月13日 02:20:50(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPRはdotnet/dotnetのVMR(Virtual Mono Repository)からdotnet/runtimeへのコードフロー更新です。.NET 10.0.1xxのrelease ブランチから複数の依存パッケージが更新されており、主にMicrosoft.CodeAnalysis(Roslyn)、ビルドツール、テストフレームワークなどが対象となっています。破壊的変更やAPIの非互換性は含まれていません。

変更内容

  • NuGet.config: フィード設定の軽微な変更
  • eng/Version.Details.props、eng/Version.Details.xml: 依存パッケージバージョンの更新(37行追加/37行削除)
  • global.json: .NET SDKとツールチェーンバージョンの更新
  • eng/common/tools.ps1: ツール初期化スクリプトの更新

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

  • Microsoft.CodeAnalysis関連: 5.0.0-2.25622.101 → 5.0.0-2.26057.111
  • Microsoft.DotNet.Arcade.Sdk他ビルドツール: 10.0.0-beta.25622.101 → 10.0.0-beta.26057.111
  • NuGet.Frameworks/Packaging/ProjectModel/Versioning: 7.0.2-rc.12301 → 7.0.2-rc.5811
  • Wasm.Node.Transport(複数プラットフォーム): 10.0.0-alpha.1.25602.8 → 10.0.0-alpha.1.25631.1

パフォーマンスへの影響

影響なし。本PRは依存パッケージの定期的な同期更新であり、ランタイム動作やコンパイラの性能に関する直接的な変更は含まれていません。

関連Issue

なし

その他

  • このPRはCodeflow自動化を通じた継続的な統合メカニズムの一部です
  • 関連する変更はarcade、aspnetcore、efcore、msbuild、roslyn、sdk、source-build-reference-packages、templating、windowsdesktop、winforms、wpfの複数リポジトリで発生しています
  • NuGet互換性に関連するバージョン更新(NuGet.Frameworks等)が含まれており、パッケージ復元機能に影響する可能性がありますが、既存コードとの互換性は保持されています

#123106 Update to draft 14 of Composite ML-DSA

  • 作成者: @PranavSenthilnathan
  • 作成日時: 2026年01月12日 22:36:32(UTC)
  • マージ日時: 2026年01月13日 17:16:28(UTC)
  • ラベル: area-System.Security

概要

Composite ML-DSA仕様のdraft 14への対応により、コンテキスト認識署名のサポートを追加しました。テストベクトルが更新され、コンテキスト有無両方の署名検証シナリオをカバーするようになります。

変更内容

  • CompositeMLDsaTestData.Raw.cs: テストベクトルを拡張し、コンテキストデータとコンテキスト認識署名フィールドを追加(+144/-108行)
  • CompositeMLDsaTestData.cs: テストデータ構造を更新(+5/-1行)
  • CompositeMLDsaTestsBase.cs: 既存テストをパラメータ化し、コンテキスト有無両方の署名検証パスをテスト(+26/-11行)

パフォーマンスへの影響

影響なし

関連Issue

#123097

その他

  • IETF参照ベクトルからテストベクトル再生成用のコードが提供されています(Gist参照)
  • draft 14仕様準拠により、将来のML-DSA標準化に対応

#123100 [main] Source code updates from dotnet/dotnet

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月12日 20:59:17(UTC)
  • マージ日時: 2026年01月13日 23:48:08(UTC)
  • ラベル: linkable-framework area-codeflow

概要

このPull Requestは、dotnet/dotnetリポジトリからのソースコード更新とビルド依存関係の一括更新です。Maestroによる自動コードフロー更新で、Microsoft.CodeAnalysis(5.3.0から5.4.0へ)、Roslyn関連ツール、ランタイムコンポーネント、Mono LLVM関連パッケージなど複数の主要な依存関係が更新されています。新たにMicrosoft.DotnetFuzzing.TestDataが追加されました。

変更内容

依存関係の更新:

  • Microsoft.CodeAnalysis系:5.3.0-1.25619.109 → 5.4.0-2.26062.101(新しいメジャーバージョンへ)
  • Microsoft.DotNet.Arcade.Sdk、Build.Tasks系:11.0.0-beta.25619.109 → 11.0.0-beta.26062.101
  • System.Reflection.Metadata、System.Text.Json、NETCore.App.Ref等:11.0.0-alpha.1.25619.109 → 11.0.0-alpha.1.26062.101
  • NuGet関連パッケージ:7.3.0-preview.1.12009 → 7.3.0-preview.1.6301
  • Mono LLVM Tools/Libclang関連:19.1.0-alpha.1.25574.1 → 19.1.0-alpha.1.25625.2
  • Wasm.Node.Transport:11.0.0-alpha.1.25607.1 → 11.0.0-alpha.1.25628.1

新規追加:

  • Microsoft.DotnetFuzzing.TestData 11.0.0-beta.25574.4

設定ファイルの変更:

  • Directory.Build.props、Directory.Build.targets、global.jsonの更新
  • eng/Version.Details.props、eng/Version.Details.xmlの大幅更新(各153行)
  • src/libraries/System.Numerics.Tensors/Directory.Build.propsに8行追加
  • src/coreclr/、src/mono/、src/tasks/配下の複数のプロジェクトファイル更新
  • src/libraries/System.Private.CoreLib/src/System/IO/SharedMemoryManager.Unix.csの修正(16行追加、12行削除)

パフォーマンスへの影響

影響なし。本PRは依存関係の更新とビルド構成の変更のみで、ランタイムパフォーマンスやメモリ使用量に直接的な影響を与える機能変更は含まれていません。

関連Issue

なし

その他

  • 本PRはdotnet-maestro[bot]による自動コードフロー更新です
  • 複数の関連リポジトリ(arcade、aspnetcore、efcore、roslyn、msbuild、runtime等)から同期されたコミットが含まれています
  • Microsoft.CodeAnalysis 5.4.0への更新は、Roslyn分析ツール機能の改善を意味する可能性があります
  • NuGet パッケージの変更(7.3.0-preview.1.12009 → 7.3.0-preview.1.6301)は異なるビルドバージョンへの変更です

#123099 [RyuJit/WASM] Add stackification algorithm skeleton

  • 作成者: @SingleAccretion
  • 作成日時: 2026年01月12日 20:50:10(UTC)
  • マージ日時: 2026年01月13日 17:53:23(UTC)
  • ラベル: area-CodeGen-coreclr community-contribution

概要

WebAssembly (WASM) JIT コンパイラに stackification アルゴリズムの検証部分を追加しました。Stackification は WASM の stack-based アーキテクチャに最適化するための中核となるアルゴリズムです。現在は検証機能のみの実装であり、最適化ロジックは今後段階的に追加される予定です。また、呼び出し関連の軽微なバグ修正も含まれています。

変更内容

  • compmemkind.h: メモリ管理タイプに新規カテゴリを1つ追加
  • gentree.cpp/h: AST ノード関連の定義を調整(18行追加)
  • lower.h: lower.cpp の インターフェイスを拡張(9行追加)
  • lower.cpp: 呼び出し処理の軽微なバグ修正(10行追加)
  • lowerwasm.cpp: stackification 検証ロジックの実装(90行追加)

パフォーマンスへの影響

現段階では検証機能のみのため、直接的なパフォーマンス改善はありません。ただし、今後の stackification 最適化の導入により、WASM コード生成の効率が向上する可能性があります。検証フェーズでの追加オーバーヘッドは最小限に設計されています。

関連Issue

なし

その他

  • PR タイトルに "[RyuJit/WASM]" プレフィックスがあり、RyuJIT (CLR のJIT コンパイラ) の WASM バックエンド実装であることが明確です
  • Stackification は WASM の値スタック型の中間表現(IR)に対応させるための重要な変換アルゴリズムであり、この骨組み実装により将来の機能追加がスムーズになります
  • 複数のレビュワーが関与しており、特に AndyAyersMS による複数回のレビューが行われています

#123088 Fix Regex.Escape to not escape vertical tab and add comprehensive tests

  • 作成者: @Copilot
  • 作成日時: 2026年01月12日 14:42:26(UTC)
  • マージ日時: 2026年01月13日 04:43:08(UTC)
  • ラベル: 指定なし

概要

PR #120625で導入されたリグレッションを修正します。垂直タブ(\v)がメタキャラクターリストに誤って追加され、Regex.Escape()が垂直タブをエスケープしていた問題を解決。垂直タブは正規表現のメタキャラクターではないため、エスケープされるべきではありません。修正はs_metacharsから\vを削除するだけで、IgnorePatternWhitespaceの正常な動作は保持されます。

// 修正前
SearchValues.Create("\t\n\v\f\r #$()*+.?[\\^{|");

// 修正後
SearchValues.Create("\t\n\f\r #$()*+.?[\\^{|");

変更内容

  • RegexParser.cs: s_metachars定数から\vを削除(1文字削除)
  • Regex.EscapeUnescape.Tests.cs: メタキャラクター個別テスト、非エスケープ文字テスト(垂直タブ含む)、混合コンテンツテストなど109新規テストケース追加
  • Regex.Match.Tests.cs: IgnorePatternWhitespace用に全ホワイトスペース文字、エスケープされたホワイトスペース、コメント、文字クラス動作をカバーする40新規テストケース追加

パフォーマンスへの影響

影響なし。単純な文字定数からの1文字削除のため、実行時のパフォーマンスへの影響はありません。

関連Issue

  • PR #120625(リグレッションの原因となったPR)

その他

  • テスト結果: 30,658機能テスト合格、1,001ユニットテスト合格
  • リスク評価: 。定数文字列からの単一文字削除という最小限の変更
  • リグレッション: はい(PR #120625で導入)
  • .NET 8以前ではパッケージ作成が必要ですが、.NET 9以降は不要

#123060 Use System.Runtime.InteropServices.Marshalling.ComVariant instead of custom VARIANT types in libraries

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年01月10日 01:49:59(UTC)
  • マージ日時: 2026年01月13日 01:22:04(UTC)
  • ラベル: area-System.Runtime.InteropServices

概要

System.DirectoryServices と System.Data.OleDb ライブラリで使用されていたカスタムの VARIANT および PROPVARIANT 型定義を、System.Runtime.InteropServices.Marshalling の標準 ComVariant 型に統一しました。Win32 VARIANT 型へのインターオップをベストプラクティスに従う形で実装し、コード重複を削減します。

// 変更前
Variant v = new Variant();
VariantInit(ref v);

// 変更後
ComVariant v = ComVariant.Create(true);
// ... 使用後 ...
v.Dispose();

変更内容

  • System.DirectoryServices: カスタム Variant 構造体を削除し、ComVariant.Create()ComVariant.Dispose() を使用するよう更新(DirectoryEntry.cs、UnsafeNativeMethods.cs、EnumVariant.cs)
  • System.Data.OleDb: PROPVARIANT 構造体定義(483行)を削除し、VARIANT と PROPVARIANT の処理を ComVariant に統一(SafeHandles.cs、RowBinding.cs、PropertyInfoSet.cs、DbPropSet.cs)
  • サイズ計算の更新: Unsafe.SizeOf<ComVariant>()sizeof(ComVariant) でサイズ取得を標準化
  • 相互運用ファイル削除: VariantInit、VariantClear、PropVariantClear の P/Invoke 定義を不要化

パフォーマンスへの影響

影響なし。ComVariant はネイティブ VARIANT 構造と同一レイアウトを持つため、メモリレイアウトと実行速度に変化はありません。ただし統一化により、メンテナンスコストが削減され、将来のコンパイラ最適化の恩恵を受けやすくなります。

関連Issue

なし

その他

  • 互換性: この変更は内部実装の統一であり、パブリック API の変更ではないため、既存のユーザーコードへの影響はありません
  • 削除コード量: 合計 545 行のカスタム型定義とインターオップコードが削除され、標準実装に一本化されました
  • コード品質向上: ComVariant の使用により、セキュリティと正確性に関連するリソース管理が標準ライブラリに委譲されます

#123057 Fix up hijacking on arm32 (preserve async continuation register)

  • 作成者: @eduardo-vp
  • 作成日時: 2026年01月10日 00:14:37(UTC)
  • マージ日時: 2026年01月13日 22:04:03(UTC)
  • ラベル: area-NativeAOT-coreclr runtime-async

概要

ARM32プラットフォームで非同期継続オブジェクト参照を保持するr2レジスタをGC中に保護するための修正です。AMD64(rcx)とARM64(x2)の動作に合わせることで、hijack固定処理の正確性を確保します。

変更内容

  • src/coreclr/nativeaot/Runtime/unix/unixasmmacrosarm.inc

    • PTFF_SAVE_R2フラグ定数(0x00000800)を追加してr2の保存/復元を有効化
  • src/coreclr/nativeaot/Runtime/arm/GcProbe.S

    • PUSH_PROBE_FRAME/POP_PROBE_FRAMEマクロを更新してr2を保存・復元
    • FixupHijackedCallstackで非同期継続を含むr2をhijack固定時に保護
    • スタックオフセット計算を144から154に調整(追加レジスタ対応)

パフォーマンスへの影響

GC probe処理でr2レジスタの保存・復元が追加されることで、ARM32プラットフォームでのスタック操作が若干増加しますが、機能正確性の確保が優先され、実質的なパフォーマンス低下は最小限と考えられます。

関連Issue

https://github.com/dotnet/runtime/issues/122492

その他

  • 非同期呼び出し規約(async calling convention)に準拠
  • ARM32、AMD64、ARM64間での一貫性を確保するための統一的な修正

#123055 fix ntlm tests on platforms with broken gssapi

  • 作成者: @wfurt
  • 作成日時: 2026年01月09日 23:22:07(UTC)
  • マージ日時: 2026年01月13日 09:17:42(UTC)
  • ラベル: area-System.Net.Security

概要

Ubuntu 24など、破損したGSSAPI実装を持つプラットフォーム上でNTLM認証テストを修正するPRです。ネイティブGSSAPIに頼らず、マネージド実装を使用することで、以前にスキップされていたテストが正常に実行されるようになります。

変更内容

  • PlatformDetection.Unix.cs: Ubuntu 24向けのプラットフォーム固有フラグを追加し、マネージドNTLM実装を有効化
  • NegotiateAuthenticationTests.cs: Ubuntu 24以降でテストをスキップしていたActiveIssue属性を削除し、NTLM可用性検出ロジックをマネージド実装に対応

パフォーマンスへの影響

影響なし(テストの修正であり、本体コードの性能には関わりません)

関連Issue

  • Fixes: #111639
  • Contributes to: #122371

その他

このPRは、特定プラットフォーム(Ubuntu 24)でのGSSAPI実装の問題に対応するもので、マネージド実装へのフォールバック戦略を実装しています。テスト可用性の改善であり、ランタイムの安定性向上につながります。


#123052 Implement support for ExtendedLayoutKind.CUnion

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年01月09日 23:08:33(UTC)
  • マージ日時: 2026年01月13日 21:03:43(UTC)
  • ラベル: area-Interop-coreclr

概要

C言語のunion型のセマンティクスをサポートするExtendedLayoutKind.CUnionを実装しました。すべてのフィールドをオフセット0に配置し、型のサイズは最大フィールドのサイズで決定されます。CStructと同様にアンマネージドフィールドのみサポートし、auto layoutは非対応です。

// CUnion型の定義例
[StructLayout(LayoutKind.Explicit, Extended = ExtendedLayoutKind.CUnion)]
public struct MyCUnion
{
    public int IntField;      // offset 0
    public long LongField;    // offset 0 (サイズは8)
    public float FloatField;  // offset 0
}

変更内容

  • ExtendedLayoutKind enum: CUnion = 1を追加(System.Runtime.InteropServices)
  • CoreCLR実装: methodtablebuilder.cppclasslayoutinfo.cppにフィールドレイアウト検証ロジック実装
  • Mono実装: class-init.cにCUnionレイアウト処理を追加
  • TypeSystem: MetadataFieldLayoutAlgorithm.csにフィールド計算ロジック実装
  • AOT対応: ILCompilerの複数モジュールにCUnionケース追加
  • 検証機能: GCポインタ、auto layoutフィールド、空union、インラインアレイのチェック
  • テスト: IL型定義とC#テストケース142行を新規追加

パフォーマンスへの影響

影響なし。CUnionは型定義時のメタデータ処理のみで、ランタイムパフォーマンスへの直接的な影響はありません。フィールドレイアウト検証はロード時に実行されます。

関連Issue

#100896

その他

  • 破壊的変更なし(新機能追加)
  • CoreCLR、Mono、TypeSystemの3つのランタイム実装に対応
  • 公開API(ExtendedLayoutKind)に新しい列挙値を追加

#123046 [clr-interp] Async Resume stubs are exclusive to the JIT as they use a set of intrinsics that are JIT specific

  • 作成者: @davidwrighton
  • 作成日時: 2026年01月09日 21:38:53(UTC)
  • マージ日時: 2026年01月13日 19:58:42(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr runtime-async

概要

このPRは、インタープリタが非同期再開スタブ(Async Resume Stub)をコンパイルしようとするのを防止します。これらのスタブはJIT固有の組み込み関数を使用しており、インタープリタは処理できません。代わりにJITまたはR2Rコンパイラによって生成されます。

// IsAsyncResumeStub() メソッドが DynamicMethodDesc に追加される
if (method->IsAsyncResumeStub())
{
    // インタープリタでのコンパイルをスキップ
}

変更内容

  • src/coreclr/vm/method.hpp: DynamicMethodDescクラスにIsAsyncResumeStub()ヘルパーメソッドを追加。既存のスタブ型チェックメソッドと同じパターンで実装
  • src/coreclr/vm/jitinterface.cpp: UnsafeJitFunction()内のインタープリタロード条件を修正し、非同期再開スタブをインタープリタコンパイルの対象外に
  • src/coreclr/interpreter/compiler.cpp: インタープリタコンパイラの処理ロジックを更新(+12/-2行)

パフォーマンスへの影響

影響なし。この変更は非同期再開スタブの処理経路を最適化するもので、実行時パフォーマンスには直接的な影響を与えません。むしろ、インタープリタが処理できない複雑なJIT固有組み込み関数の処理を回避することで、ランタイムエラーを防止します。

関連Issue

なし

その他

このPRはテストモードで重要です。ランタイムが非同期メソッドをJITコンパイルし、関連する非同期再開スタブをインタープリタで処理する必要がある場合、このPRによってそのシナリオが正しく機能するようになります。インタープリタ自体は異なる経路で非同期再開スタブを呼び出すため、このスタブは実際には使用されません。


#122841 Fix JsonNode.GetPath() to properly escape characters in property names

  • 作成者: @Copilot
  • 作成日時: 2026年01月03日 21:52:46(UTC)
  • マージ日時: 2026年01月13日 15:50:22(UTC)
  • ラベル: area-System.Text.Json

概要

JsonNode.GetPath() が特殊文字を含むプロパティ名に対して、仕様に準拠した有効なJSON Path構文を生成していなかった問題を修正。プロパティ名が $ で始まる場合はドット記法ではなくブラケット記法を使用し、ブラケット記法内ではシングルクォートとバックスラッシュを適切にエスケープするようになります。

// Before: Invalid JSON Path returned
JsonNode.Parse("""{"$defs":{"foo['bar":"baz"}}""")["$defs"]["foo['bar"].GetPath();
// Returns: $.$defs['foo['bar']  

// After: Valid JSON Path returned
// Returns: $['$defs']['foo[\'bar']

変更内容

  • JsonReaderHelper.cs: $ を特殊文字セットに追加し、AppendEscapedPropertyName ヘルパーメソッド(2つのオーバーロード)を実装。シングルクォート→\'、バックスラッシュ→\\ のエスケープ処理を最適化(IndexOfAny で前置スライスを直接追加)
  • StringBuilderExtensions.cs: .NET Standard 2.0 および .NET Framework サポートのための StringBuilder.Append(ReadOnlySpan<char>) ポリフィル追加
  • JsonObject.cs、WriteStack.cs、ReadStack.cs: JSON Path生成箇所でエスケープ処理を呼び出すよう更新
  • テストファイル: ドット記法からブラケット記法への期待値の更新、$ プレフィックス名・シングルクォート・バックスラッシュ・組み合わせケースの新テストケース追加

パフォーマンスへの影響

改善あり。IndexOfAny を使用して特殊文字の位置を一度に検出し、文字列のスライスを StringBuilder に直接追加することで、従来の文字単位イテレーション処理を削減。メモリ割り当てと処理回数が最小化されます。

関連Issue

dotnet/runtime#83547(gregsdennis による報告)

その他

  • 互換性: 既存コードが無効なJSON Path形式を想定している場合は調整が必要ですが、この修正は仕様準拠の改善です
  • テスト: 49,808個のSystem.Text.Jsonテストすべてがパスしており、低リスク
  • .NET 9以降ではNuGetパッケージのバージョン編集が不要になるため、記載の必要なし

#122838 Fix JsonSerializer.Serialize producing invalid JSON for [JsonExtensionData] with JsonObject

  • 作成者: @Copilot
  • 作成日時: 2026年01月03日 21:08:44(UTC)
  • マージ日時: 2026年01月13日 12:06:08(UTC)
  • ラベル: area-System.Text.Json

概要

JsonSerializer.Serialize[JsonExtensionData]属性を持つJsonObject型のプロパティをシリアライズする際、無効なJSONを生成していたバグを修正します。

var mix = new Mix { Id = 1, Extra = new JsonObject { ["nested"] = true } };
JsonSerializer.Serialize(mix);
// 修正前: {"Id":1,{"nested":true}}  ← 無効なJSON
// 修正後: {"Id":1,"nested":true}    ← 正常

変更内容

  • JsonObject.cs: WriteContentsTo内部メソッドを追加。拡張データの内容をブレースなしで書き込み(辞書バック及びJsonElementバック両対応)
  • JsonObjectConverter.cs: WriteExtensionDataValue仮想メソッドをオーバーライド。WriteContentsToを呼び出す処理を実装
  • JsonConverterOfT.cs: TryWriteDataExtensionPropertyを修正。JsonObjectに対して新規の仮想メソッドを呼び出すよう変更
  • ExtensionDataTests.cs: 有効なJSON出力、ラウンドトリップ、空のJsonObject、null JsonObjectをカバーする4つのテストを追加

パフォーマンスへの影響

影響なし。変更はJsonObjectの拡張データシリアライズパスに限定。辞書型の拡張データパスは変更なし。仮想メソッドパターンはトリミング対応を維持(リリースビルドでは直接型参照を含まない)。

関連Issue

#97225(dotnet/runtime)

その他

  • .NET 6以降の回帰: .NET 6~8で再現可能。デシリアライズは正常に動作(シリアライズのみが影響)
  • テスト範囲: 既存49,808テスト全パス、ソース生成関連7,626テスト全パス
  • リスク評価: 低。変更は最小限でJsonObject分岐に限定。互換性に破壊的変更なし

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2025年12月26日 18:34:59(UTC)
  • マージ日時: 2026年01月13日 18:20:44(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPull Requestは、dotnet/emsdkリポジトリからの依存関係を更新するものです。Emscripten Workloadに関連する2つのNuGetパッケージが更新されており、WebAssembly (WASM)開発環境のサポート向上が目的と考えられます。

変更内容

  • NuGet.config (+1/-1): NuGetソース構成の更新
  • eng/Version.Details.xml (+3/-3): 依存関係バージョン情報の更新
    • Microsoft.SourceBuild.Intermediate.emsdk: 8.0.23-servicing.25612.6 → 8.0.23-servicing.25626.3
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: 8.0.23 → 8.0.23(パッチレベル更新)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPRは自動生成(dotnet-maestro[bot]による)の依存関係更新です
  • release/8.0ブランチ向けの更新であり、.NET 8.0の保守リリースに対応しています
  • Emscripten SDKは.NETアプリケーションをWebAssemblyにコンパイルするためのツールチェーンであり、クロスプラットフォーム開発を支援します

#122698 [main] Update dependencies from dotnet/xharness

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2025年12月22日 05:01:54(UTC)
  • マージ日時: 2026年01月13日 10:44:11(UTC)
  • ラベル: area-Infrastructure-mono

概要

dotnet/xharnessの依存パッケージを更新するPull Requestです。Microsoft.DotNet.XHarness.CLI、Microsoft.DotNet.XHarness.TestRunners.Common、Microsoft.DotNet.XHarness.TestRunners.Xunitの3つのパッケージをバージョン11.0.0-prerelease.25603.1から11.0.0-prerelease.26058.2に更新しています。

変更内容

  • eng/Version.Details.xml: xharnessの参照バージョンを11.0.0-prerelease.25603.1から11.0.0-prerelease.26058.2に更新(6行変更)
  • eng/Version.Details.props: バージョン情報を同期更新(3行変更)
  • .config/dotnet-tools.json: ツール設定ファイルの更新(1行変更)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 依存関係の更新はdotnet-maestro[bot]による自動更新です
  • xharnessビルド日時: 2026年1月8日 UTC
  • 参照コミット: 799df8d4c86ff50c83b7a57df9e3691eeab813ec

#122668 Fix CharSearchValuesPolyfill._ascii array size from 8 to 4 elements

  • 作成者: @Copilot
  • 作成日時: 2025年12月19日 18:25:16(UTC)
  • マージ日時: 2026年01月13日 13:15:28(UTC)
  • ラベル: 指定なし

概要

CharSearchValuesPolyfill._ascii 配列のサイズが誤って uint[8] になっていたのを uint[4] に修正しました。ASCII文字(0-127)のビットマップ検索は c >> 5 によるオフセット(0-3)を使用するため、4要素が必要です。このバグにより、非ASCII文字(オフセット4-7)が誤ってバウンズチェックを通過し、NonAsciiContains() にフォールスルーせず、不正な検索結果が返されていました。

// 修正前: 非ASCII文字 char(200) が誤って _ascii[6] を検索
private readonly uint[] _ascii = new uint[8];

// 修正後: 非ASCII文字 char(200) が正しく NonAsciiContains に処理される
private readonly uint[] _ascii = new uint[4];

変更内容

  • SearchValuesPolyfills.cs: _ascii 配列サイズを8から4に修正(1行変更)
  • SearchValuesPolyfillTests.cs: バウンダリ条件テスト追加(char.MinValue、'a'(97)、127、128、char.MaxValue)
  • Common.Tests.csproj: テスト用に IncludeSpanPolyfills=true を追加

パフォーマンスへの影響

影響なし

メモリ使用量が削減(uint[8]uint[4]、32バイト削減)されますが、実行速度には変化なし。ポリフィル機能自体は .NET Standard 2.0 および .NET Framework の下位レベルターゲット環境でのみ使用される機能です。

関連Issue

  • Issue #122667: CharSearchValuesPolyfill._ascii should be 128 bits length

その他

  • 互換性: 破壊的変更なし。このバグ修正により、.NET Standard 2.0 および .NET Framework をターゲットとするアプリケーションで、非ASCII文字を含む SearchValues.Create()Contains() メソッドが正しく動作するようになります。
  • 回帰リスク: 低い。ワンライン修正で、アルゴリズム要件に合致させただけです。メイン .NET ランタイムの SearchValues 実装は別コードパスで、この変更の影響を受けません。

#122639 Generate calls to interface methods through resolve helper

  • 作成者: @MichalStrehovsky
  • 作成日時: 2025年12月18日 13:45:22(UTC)
  • マージ日時: 2026年01月13日 23:53:37(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

このPRはControl Flow Guard (CFG)が有効な場合のインターフェースメソッド呼び出しを、スタブディスパッチャーから高速解決ヘルパー(RhpResolveInterfaceMethodFast)経由に変更します。JIT下位化時にVSD呼び出しをリゾルバー呼び出しに変換し、二重間接参照を排除してパフォーマンスを改善します。

// インターフェースメソッド呼び出し
static int Call(IFoo f, int x, int y) => f.Call(x, y);

変更内容

JIT/コンパイラ側の変更:

  • lower.cpp: CFG有効時にVSD呼び出しをリゾルバー呼び出しに変換(CORINFO_HELP_INTERFACELOOKUP_FOR_SLOTヘルパー追加)
  • morph.cpp: CFGハンドリングを全仮想呼び出しに拡張
  • targetamd64.h, targetarm64.h: インターフェース検索ヘルパーのレジスタ破壊マスク定義
  • codegencommon.cpp, emit.cpp: ヘルパー呼び出し時の引数レジスタ保護実装

CoreCLR側(Windows AMD64/ARM64):

  • VirtualCallStubAMD64.asm: JIT_InterfaceLookupForSlot アセンブリスタブ実装
  • cgenamd64.cpp: スタックウォーク用のUpdateRegDisplayFromArgumentRegisters追加

NativeAOT側:

  • amd64/DispatchResolve.asm, arm64/DispatchResolve.asm: キャッシュ参照機能付きの高速インターフェース解決実装
  • UniversalTransition.asm: テール呼び出しと結果リターンの両方のモード対応
  • EHHelpers.cpp: 例外ハンドリング対応

テスト:

  • ControlFlowGuard.cs: ジェネリック/非ジェネリックインターフェース、複数実装、例外シナリオをカバー

パフォーマンスへの影響

改善点:

  • レジスタ使用量削減:push rbxsub rsp,20hsub rsp,28h に削減
  • アセンブリコード長短縮:17命令 → 6命令へ削減(約65%短縮)
  • 二重間接参照排除:スタブディスパッチャーを経由せず直接リゾルバーへ
  • インラインキャッシュルックアップにより、頻繁に呼び出されるインターフェースメソッドの高速化

CFGセキュリティ保証維持:

  • Guard dispatch用の関数ポインターチェック(__guard_dispatch_icall_fptr)は継続実装
  • セキュリティレベルの低下なし

関連Issue

#112406(前回のPRで多数のマージコンフリクトが発生したため新規作成)

その他

  • CoreCLR(JIT)とNativeAOT両ランタイムに対応
  • ARM64アーキテクチャにも拡張実装
  • JIT/EEバージョンGUID更新により互換性管理を実施
  • Coptilot指摘の潜在的なコード重複あり(lower.cpp:3759cloneUse

#122569 Handle OpenSSL config errors gracefully in DetectCiphersuiteConfiguration

  • 作成者: @Copilot
  • 作成日時: 2025年12月15日 21:00:34(UTC)
  • マージ日時: 2026年01月13日 16:06:38(UTC)
  • ラベル: 指定なし

概要

このPRはOpenSSL設定が不正な場合にセグメンテーション違反で.NETアプリケーションがクラッシュする問題を修正します。リリースビルドでassert()がコンパイルされて削除されることが原因で、DetectCiphersuiteConfiguration()関数内のエラーチェックが機能していません。修正により、不正なOpenSSL設定時にはデフォルトの暗号スイートへ自動的にフォールバックし、正常に動作継続します。

// 修正前(リリースビルドで assert() が削除される)
int rv = SSL_CTX_set_cipher_list(ctx, "ALL");
assert(rv);  // コンパイルされない!

// 修正後(実行時エラーハンドリング)
int rv = SSL_CTX_set_cipher_list(ctx, "ALL");
if (!rv) {
    ERR_clear_error();
    SSL_CTX_free(ctx);
    return;  // デフォルト設定で続行
}

変更内容

src/native/libs/System.Security.Cryptography.Native/pal_ssl.c

  • assert(ctx != NULL)assert(rv)を実行時チェックに置換
  • SSL_CTX_set_cipher_list()失敗時にERR_clear_error()で OpenSSL エラースタックをクリア
  • エラー時はSSL_CTX_free()でリソース解放後に早期リターン
  • g_config_specified_ciphersuitesは0のまま残存(デフォルト暗号スイート使用)

src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamRemoteExecutorTests.cs

  • MalformedOpenSslConfig_DoesNotCrashテストケース追加
  • RemoteExecutor.Invokeで別プロセス実行時にOPENSSL_CONF環境変数を設定
  • 不正なOpenSSL設定下でもSSLハンドシェイクが完了し、クラッシュしないことを検証

パフォーマンスへの影響

影響なし。変更は暗号スイート検出(オプション処理)のエラーハンドリング部分に限定されており、正常系の処理パスには変更なし。

関連Issue

Issue #122538: ".NET segfaults instead of showing error when OpenSSL config is invalid"

その他

セキュリティ・堅牢性

  • 破壊的変更なし。エラー時の動作が「クラッシュ」から「デフォルト設定へフォールバック」に改善
  • 重要なメモリ割り当て失敗(SSL_CTX_new)は引き続きassert()で検証(基盤的なエラー)
  • リスク評価:低。暗号検出機能はオプション性質で、フェイルセーフ動作はより安全

テスト戦略

  • RemoteExecutor使用により、悪い設定ファイルを本番環境に影響させないよう隔離実行
  • 実装確認済み:dotnet test --filter "FullyQualifiedName~MalformedOpenSslConfig_DoesNotCrash"で合格

#122406 Fix GetFileAccessFromRights bitwise logic for compound FileSystemRights flags

  • 作成者: @Copilot
  • 作成日時: 2025年12月10日 21:05:46(UTC)
  • マージ日時: 2026年01月13日 18:35:21(UTC)
  • ラベル: area-System.IO

概要

FileInfo.Create()FileSystemRights.Read を指定した際に、返された FileStreamCanWrite プロパティが誤って true になる不具合を修正しました。根本原因は GetFileAccessFromRights メソッドのビット演算ロジックの誤りで、複合フラグ(FullControlModify)に対して「ビットが1つでも重なっているか」を確認していました。

修正前後の比較:

// 修正前(誤り)
if ((rights & FileSystemRights.FullControl) != 0)
    return FileAccess.ReadWrite;

// 修正後(正)
if ((rights & FileSystemRights.FullControl) == FileSystemRights.FullControl)
    return FileAccess.ReadWrite;

変更内容

  • FileSystemAclExtensions.csGetFileAccessFromRights メソッドのビット比較ロジックを修正。複合フラグに対して部分的な重なりではなく、フラグのすべてのビットが存在することを確認するように変更
  • FileSystemAclExtensionsTests.csFileSystemRights.Read で開いた FileStreamCanWritefalse であることを検証する回帰テストを追加(36行)

パフォーマンスへの影響

影響なし。ビット演算ロジックの正確化であり、パフォーマンス上の差異はありません。

関連Issue

#111540(dotnet/runtime) 回帰は PR #61297 で導入されたもの(.NET 6.0では正常に動作)

その他

  • .NET 7.0.203 以降の System.IO.FileSystem.AccessControl パッケージで発生
  • 修正後のマッピング:
    • ReadFileAccess.Read(修正前は ReadWrite
    • WriteFileAccess.Write(修正前は ReadWrite
    • ReadAndExecuteFileAccess.Read(修正前は ReadWrite
    • ModifyFullControlFileAccess.ReadWrite(変更なし)

#122381 Fix impGetNodeAddr flag handling for volatile, unaligned, and initclass accesses

  • 作成者: @Copilot
  • 作成日時: 2025年12月10日 11:27:38(UTC)
  • マージ日時: 2026年01月13日 14:01:36(UTC)
  • ラベル: area-CodeGen-coreclr

概要

impGetNodeAddrが返すフラグ(volatile、unaligned、initclass)を5つのコールサイトが無視していた問題を修正します。allowConfiguredDerefsパラメータを追加し、volatile/unaligned/initclassフラグを含む間接参照をサポートできないコンテキスト(VMヘルパーへのアドレス渡し)では、フラグを保持するテンポラリ作成にフォールスルーするようにしました。

変更内容

  • src/coreclr/jit/gentree.h: GTF_IND_MUST_PRESERVE_FLAGS定数を追加(volatile、unaligned、initclass)
  • src/coreclr/jit/compiler.h: impGetNodeAddrallowConfiguredDerefsパラメータを追加
  • src/coreclr/jit/importer.cpp:
    • impGetNodeAddrの実装を変更。allowConfiguredDerefs=false時はフラグ付き間接参照をテンポラリにコピー
    • リターンバッファ(3箇所)でallowConfiguredDerefs=falseを指定
    • 構造体フィールドアクセスとbox-isinst最適化で返却フラグを間接参照に結合
    • GT_COMMA再帰呼び出しでallowConfiguredDerefsを保持
  • src/coreclr/jit/importercalls.cpp: SRCSUnsafeIntrinsicコールサイトを更新

パフォーマンスへの影響

影響なし。本修正は意味論的正確性の確保であり、パフォーマンスクリティカルなパスには変更なし。一部コンテキストでテンポラリ作成が増加する可能性がありますが、これはVMヘルパーの制約によるもので、他の選択肢はありません。

関連Issue

dotnet/runtime#89372、dotnet/runtime#85562

その他

PR作成者はCopilot(AI)です。全5つの「TODO-Bug?: verify if flags matter here」コメントが解決されました。これはコンパイラの正確性向上に関わる重要な修正で、volatile/unalignedメモリアクセスの意味論が正しく保持されます。


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

  • 作成者: @github-actions[bot]
  • 作成日時: 2025年12月06日 21:58:37(UTC)
  • マージ日時: 2026年01月13日 21:59:35(UTC)
  • ラベル: NO-SQUASH Servicing-approved

概要

release/9.0ブランチからrelease/9.0-stagingブランチへの自動マージPRです。jeffhandleyとdotnet-maestro[bot]による変更をrelease/9.0-stagingに統合します。このPRは自動マージされず、チェック完了後に手動でマージコミット(squashやrebaseではなく)を作成する必要があります。

変更内容

  • NuGet.config (+1行):NuGetの設定情報を追加
  • eng/Version.Details.xml (+50/-50行):依存ライブラリのバージョン情報を更新
  • eng/Versions.props (+24/-24行):プロジェクトのバージョン定義を更新

パフォーマンスへの影響

影響なし(ビルド時の依存関係バージョン更新のため)

関連Issue

なし

その他

  • マージ時の指示:マージコミットの作成が必須(squashやrebaseは使用禁止)
  • コマンドラインマージ時は git merge --no-ff release/9.0 を使用してください
  • マージコンフリクト発生時は手動解決が必要です
  • 詳細なマージ手順はPR内に記載されています

#122263 Optimize more bound checks around logical operators

  • 作成者: @EgorBo
  • 作成日時: 2025年12月06日 18:28:00(UTC)
  • マージ日時: 2026年01月13日 16:25:51(UTC)
  • ラベル: area-CodeGen-coreclr reduce-unsafe

概要

JITコンパイラのRange Check Analysis(境界値チェック最適化)を強化し、ビット演算(AND、OR、シフト、MOD)を含む式の値範囲を正確に計算できるようにしました。これにより、Base64エンコーディングなどのビット演算パターンで不要な境界チェックが自動的に削除されます。

サンプル:

int Test(byte inData)
{
    ReadOnlySpan<byte> base64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="u8;
    return base64[((inData & 0x03) << 4) | ((inData & 0xf0) >> 4)];
}

最適化により、生成されるアセンブリのコードサイズが55バイトから36バイトに削減されました。

変更内容

  • rangecheck.h: ShiftLeft、And、Or、UnsignedMod操作のRange計算ロジックを追加
  • rangecheck.cpp: ComputeRangeForBinOpをSwitch文ベースのディスパッチにリファクタリング(82行削除、60行追加)
  • Convert.cs: ConvertToBase64ArrayをFixed PointerからReadOnlySpanに変更し、強化されたRange Check Eliminationに依存
  • clrjit.natvis: デバッグ用のLimitおよびRange型のVisualizer追加

パフォーマンスへの影響

改善点:

  • Base64変換処理で境界チェック完全削除(CORINFO_HELP_RNGCHKFAIL呼び出し削除)
  • コード生成サイズ削減:55バイト → 36バイト(35%削減)
  • sub rsp, 40add rsp, 40のスタック操作削減

関連Issue

#122150

その他

破壊的変更なし。ConvertToBase64Array内のロジックは実質変更されず、ポインタ方式からSpan方式への移行のみ(安全性向上)。


#122023 JIT: Devirtualize non-shared generic virtual methods

  • 作成者: @hez2010
  • 作成日時: 2025年11月27日 17:12:36(UTC)
  • マージ日時: 2026年01月13日 13:11:10(UTC)
  • ラベル: area-CodeGen-coreclr community-contribution

概要

JITコンパイラにジェネリック仮想メソッドのdevirtualization(仮想化解除)機能を追加しました。実行時に正確な型が判明している場合、仮想メソッドの呼び出しを直接呼び出しに最適化できるようになります。これにより仮想ディスパッチのオーバーヘッドを削減し、インライン化などの後続最適化が可能になります。

public class IntProcessor : VirtualGenericClass
{
    public override void Process<T>(T item)
    {
        Console.WriteLine(item.ToString());
    }
}

// 以前は仮想ディスパッチが必須でしたが、
// 今後は型が判明していればdevirtualizeされます
VirtualGenericClass c = new IntProcessor();
c.Process(42);

変更内容

コア変更:

  • src/coreclr/vm/jitinterface.cpp: ジェネリックメソッドのdevirtualization処理を実装、FindOrCreateAssociatedMethodDescを使用して具体的なメソッドディスクリプタを取得
  • src/coreclr/jit/gentree.cpp/h: IsGenericVirtual()ヘルパーメソッドを追加、devirtualization対象の判定ロジックをジェネリック仮想メソッドに対応
  • src/coreclr/jit/importercalls.cpp: ジェネリック仮想メソッドのdevirtualization実装(ランタイムルックアップ対応)
  • src/coreclr/inc/corinfo.h: wasArrayInterfaceDevirtneedsMethodContextに名称変更(汎用化)
  • src/coreclr/jit/jitconfigvalues.h: JitEnableGenericVirtualDevirtualizationフラグを追加(制御可能)
  • テスト追加: generic_virtual_methods.csにジェネリック仮想メソッドの包括的なテストスイート(706行)

パフォーマンスへの影響

改善点:

  • コード例のcodegen diffより、スタック領域を40バイトから32バイトに削減(16%削減)
  • 仮想関数ポインタ取得(CORINFO_HELP_VIRTUAL_FUNC_PTR)の呼び出しが不要に
  • 生成コードサイズが109バイトから69バイトに削減(37%削減)
  • レジスタ保存(rsi)が不要になり、プロローグ/エピローグも縮小

制限事項:

  • AOT(Ahead-of-Time)コンパイルは未対応(マネージ型システムの追加作業が必要)
  • 共有ジェネリックメソッドで実行時ルックアップが必要な場合はbail out(ジェネリックコンテキスト不足)

関連Issue

#112596

その他

  • 非破壊的な互換性: 既存の仮想化解除ロジックを拡張する形で、破壊的変更なし
  • JITナブで有効/無効を制御可能(JitEnableGenericVirtualDevirtualization
  • SuperPMI対応: データ構造と記録/リプレイロジックを更新
  • マネージインターフェース対応: CoreInfoTypes.cs/CorInfoImpl.csも同期更新完了

#121527 [Bounds checks] Merge inter-block assertions in RangeCheck::MergeAssertion

  • 作成者: @EgorBo
  • 作成日時: 2025年11月11日 18:11:59(UTC)
  • マージ日時: 2026年01月13日 02:24:58(UTC)
  • ラベル: area-CodeGen-coreclr reduce-unsafe

概要

RangeCheckの最適化により、同じブロック内で先行して生成された境界チェックアサーションを活用できるようになりました。従来は保守的にbbAssertionInのみを使用していましたが、本変更でブロック内部(inter-block)のアサーションも累積することで、冗長な境界チェックを削除可能になります。提供されたコード例では、i++後のarr[i] = 0での境界チェックが不要と判定され、5バイトのコード削減を実現しています。

変更内容

  • src/coreclr/jit/rangecheck.cpp (+76/-1)
    • RangeCheck::MergeAssertionメソッドの強化
    • アサーション不在時の早期終了処理を追加
    • TreeAssertionVisitorクラスを導入し、ブロック内の先行ステートメントから境界チェックアサーションを収集
    • BBF_MAY_HAVE_BOUNDS_CHECKSフラグを持つブロックのみに検索範囲を限定してオーバーヘッド削減

パフォーマンスへの影響

改善あり:

  • 冗長な境界チェック命令の削除により、コードサイズが削減(示例では56バイト→51バイト、約9%削減)
  • TreeAssertionVisitorによる検索がフラグチェック経由で限定されるため、追加のオーバーヘッドは最小限
  • JIT時間への影響を考慮し、アサーション存在時のみの処理に設計
// 改善前:arr[i] = 0の後の arr[i] = 0 でも境界チェックが残される
void Test(int[] arr, int i)
{
    arr[i] = 0;        // i >= 0 && i < arr.Length アサーション生成
    i++;               // 同一ブロック
    if (i < arr.Length)
        arr[i] = 0;    // 改善前:冗長な境界チェック実行
}

// 改善後:先行アサーションを活用して冗長なチェックを削除

関連Issue

なし

その他

  • レビュアーAndyAyersMS提案のアイデアを実装(inter-blockアサーション累積の最適化アプローチ)
  • テスト再現ケース提供者BoyBaikiller氏に謝辞

#120910 Fix KeyValuePair nullability detection on Mono

  • 作成者: @medhatiwari
  • 作成日時: 2025年10月20日 17:14:23(UTC)
  • マージ日時: 2026年01月13日 06:20:38(UTC)
  • ラベル: area-VM-meta-mono community-contribution

概要

Mono ランタイムにおいて、ジェネリック型パラメータの NullableAttribute メタデータが失われていた問題を修正しました。KeyValuePair<TKey, TValue> の nullability 検出が正常に機能していなかったため、ASP.NET Core の DataAnnotations テストで不正な NotNull 判定が発生していました。

// 修正前: Mono で Nullable が正しく検出されない
var kvpType = typeof(KeyValuePair<string, object>);
var keyProperty = kvpType.GetProperty("Key");
var nullabilityContext = new NullabilityInfoContext();
var result = nullabilityContext.Create(keyProperty);
// 期待値: Nullable
// 実際: NotNull(修正前)

変更内容

  • ファイル: src/mono/mono/metadata/class-init.c
  • 変更内容: mono_class_layout_fields() 関数を修正し、ジェネリック型パラメータ(MONO_TYPE_VAR および MONO_TYPE_MVAR)に対して class_size の割り当てをスキップ

パフォーマンスへの影響

影響なし

関連Issue

#120910

その他

根本原因: MonoClass 構造体の MonoClassSizes が union として実装されており、class_sizegeneric_param_token が同じメモリ領域を共有していました。mono_class_layout_fields()class_size = 0 が明示的に割り当てられる際、union のため generic_param_token が 0x0 に上書きされ、後の反射処理で カスタム属性の検出が失敗していました。

テスト結果:

  • 修正前: 361 pass、3 fail
  • 修正後: 363 pass、1 fail
  • キーバリューペアの nullability 検出テスト 2 件が修正され、回帰なし