Pull Request on 2026年02月05日

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

注意点

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



#124054 Add tests for NumberStyles.AllowTrailingInvalidCharacters

  • 作成者: @Copilot
  • 作成日時: 2026年02月05日 18:02:46(UTC)
  • マージ日時: 2026年02月05日 18:59:03(UTC)
  • ラベル: 指定なし

概要

NumberStyles.AllowTrailingInvalidCharacters モードの包括的なテストカバレッジを追加するPRです。このスタイルは Parse/TryParse API が最初の無効な文字までを解析し、消費した文字数を返すことを可能にします(Utf8Parser の動作に類似)。すべての整数型、浮動小数点型、BigInteger を対象とした計1,152行のテストが追加されました。

// 例: "123abc" を解析する場合
// 値: 123, 消費文字数: 3
if (int.TryParse("123abc", 
    NumberStyles.AllowTrailingInvalidCharacters, 
    CultureInfo.InvariantCulture, 
    out var result))
{
    // result = 123
}

変更内容

テストファイル追加(13ファイル、合計1,152行):

  • 整数型: Int32Tests.cs (+158)、Int64Tests.cs (+91)、Int16Tests.cs (+36)、SByteTests.cs (+36)、UInt32Tests.cs (+85)、UInt64Tests.cs (+85)、UInt16Tests.cs (+35)、ByteTests.cs (+36)
  • 浮動小数点型: DoubleTests.cs (+115)、SingleTests.cs (+105)、HalfTests.cs (+104)、DecimalTests.cs (+88)
  • 任意精度: BigInteger/parse.cs (+86)

テストシナリオ:

  • 末尾の無効文字を含む基本的な解析
  • NumberStyles との組み合わせ(Integer、HexNumber、BinaryNumber、Currency、Float)
  • エッジケース(最大値/最小値、空文字列、オーバーフロー、特殊値)
  • すべての API surface(string、ReadOnlySpan<char>、ReadOnlySpan<byte> オーバーロード)
  • 成功/失敗パスの両方で消費文字数/バイト数の検証

パフォーマンスへの影響

影響なし(テストコードの追加のため、実行時のパフォーマンスへの影響なし)

関連Issue

なし

その他

  • テストは System.Runtime.Tests の既存パターンに従い、System.Memory の Utf8Parser テストで使用されている ValidateParser アプローチをミラーリング
  • ビルドは成功するが、テスト実行の完全なベースラインビルドは時間制約により実施されていない

#124030 Introduce OAK_relops

  • 作成者: @EgorBo
  • 作成日時: 2026年02月05日 03:46:44(UTC)
  • マージ日時: 2026年02月05日 23:00:24(UTC)
  • ラベル: area-CodeGen-coreclr

概要

このPRは、JITコンパイラの値番号付け(VN)ベースのアサーション表現を簡潔にするものです。従来の relopVN OAK_[NOT]_EQUAL 0 という表現から、op1VN OAK_<relop> op2VN という直接的な表現に統一することで、アサーション処理を効率化し、将来の最適化を可能にしています。

// Before: assertion consumers had to call GetVNFunc to extract operands
relopVN OAK_NOT_EQUAL 0

// After: direct relational assertion
op1VN OAK_LE op2VN

変更内容

  • compiler.h: OAK_relops の新しい定義を追加(OAK_LT, OAK_LE, OAK_GT, OAK_GE など)。既存の OAK_CONSTANT_LOOP_BND, OAK_ARR_BND, OAK_NO_THROW などを削除
  • assertionprop.cpp: アサーション生成・検証ロジックを新しい relop ベースの表現に対応させるように更新
  • rangecheck.cpp: 範囲チェック最適化ロジックを新表現に適応
  • valuenum.cpp/valuenum.h: 不要なVN関連の定義を削除

パフォーマンスへの影響

改善: バイナリサイズとスループット(TP)で軽微な改善を確認。アサーション消費者は GetVNFunc の呼び出しが不要になり、ルックアップが効率化されます。これにより、VN マップ化されたハッシュセットによる高速なアサーション検証が実現可能に。

関連Issue

#124030

その他

  • このリファクタリングは、64ビット整数と浮動小数点数への既存操作の拡張と、新しい最適化手法の実装基盤となります
  • 後続のPRで OAK_BOUND_LOOP_BNDOAK_BOUND_OPER_BND が削除予定
  • OAK_NO_THROWop1VN (idx) OAK_LT_UN op2VN (len) の標準的な関係表現に統一

#124011 Remove unused method signatures from corelib and metasig headers

  • 作成者: @AaronRobinsonMSFT
  • 作成日時: 2026年02月04日 18:58:30(UTC)
  • マージ日時: 2026年02月05日 15:22:12(UTC)
  • ラベル: area-VM-coreclr

概要

corelib.hとmetasig.hヘッダーファイルから未使用のメソッドシグネチャを削除するクリーンアップです。合計142行のコードを削除し、ランタイムのコード整理と保守性向上を目的としています。

変更内容

  • src/coreclr/vm/corelib.h: 未使用のメソッドシグネチャ定義を7行削除
  • src/coreclr/vm/metasig.h: 未使用のメタシグネチャ定義を135行削除

パフォーマンスへの影響

影響なし。不使用コードの削除のため、パフォーマンスへの直接的な影響はありません。

関連Issue

なし

その他

本変更は削除のみの操作です。既存の使用中のメソッドシグネチャには影響を与えず、ランタイムのメンテナンス効率向上と技術負債削減が目的と考えられます。


#123999 JIT: Further liveness cleanups

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月04日 11:53:11(UTC)
  • マージ日時: 2026年02月05日 10:34:51(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JITコンパイラのライブネス解析フェーズをリファクタリングする変更です。各ライブネスフェーズを独立した関数に分離し、LiveVarAnalysisクラスをLivenessクラスに統合しました。機能的な動作変更はありませんが、MSSQLコンパイラでのインライン決定に関連したテンポラルパフォーマンス回帰が存在します。

変更内容

  • liveness.cpp: ライブネス解析ロジックの大幅なリファクタリング(310行追加/309行削除)

    • 各ライブネスフェーズを個別の関数に分離
    • LiveVarAnalysisクラスをLivenessクラスに統合
    • フィールド名の改名
  • compiler.h: Liveness設定オプションの追加と変更(11行追加/12行削除)

    • fgIsDoingEarlyLivenessフラグを削除し、新しいコンフィグオプションで置き換え
    • fgLocalVarLivenessChangedLivenessクラスに移動
  • async.cpp、compiler.cpp、lower.cpp、ssabuilder.cpp: 参照先の更新(計8行の小規模変更)

パフォーマンスへの影響

MSSQLコンパイラ環境でのテンポラルパフォーマンス回帰: LiveVarAnalysis統合に伴うインライン決定への影響が報告されています。ただし、No diffs expectedと記載されており、生成されるコード自体に実質的な変更はないと考えられます。一般的なランタイムパフォーマンスへの影響は最小限と予想されます。

関連Issue

なし

その他

  • 最適化レベルチェックをライブネス解析から削除(ライブネス解析は最適化時のみ実行されるため冗長)
  • コード保守性と可読性の向上を目指したリファクタリング
  • 機能的な出力変更なし

#123970 Remove unused library_hash and library_hash_path from deps_entry_t

  • 作成者: @Copilot
  • 作成日時: 2026年02月03日 21:51:52(UTC)
  • マージ日時: 2026年02月05日 00:06:06(UTC)
  • ラベル: 指定なし

概要

.NET ランタイムのホストポリシーコンポーネントから、deps_entry_t 構造体の未使用フィールド library_hashlibrary_hash_path を削除するクリーンアップです。これらのフィールドは deps.json ファイルから解析されていましたが、実際には読み込まれていないデッドコードでした。

変更内容

  • deps_entry.h: deps_entry_t 構造体から library_hashlibrary_hash_path フィールド宣言を削除(-2行)
  • deps_format.cpp: deps.json 解析ロジックから関連する局所変数の割り当てを削除(-4行)

パフォーマンスへの影響

影響なし。ただし、以下の改善が期待されます:

  • メモリ使用量の微小な削減(deps_entry_t インスタンスあたり)
  • JSON 解析時の不要な文字列割り当てが削減され、メモリフラグメンテーションが軽減される可能性あり

関連Issue

なし

その他

  • ホストコンポーネントのビルドと全ホストテストが成功確認済み
  • 公開 API ではなく、内部実装のクリーンアップであるため互換性への影響なし
  • Copilot による自動化されたコード削減で、コードの保守性が向上

#123964 [mono] read $DOTNET_STARTUP_HOOKS

  • 作成者: @jonathanpeppers
  • 作成日時: 2026年02月03日 21:13:38(UTC)
  • マージ日時: 2026年02月05日 19:16:07(UTC)
  • ラベル: area-EnC-mono needs-area-label

概要

Monoランタイムが $DOTNET_STARTUP_HOOKS 環境変数を読み込まない問題を修正します。現在、System.StartupHookProvider.ProcessStartupHooks() 呼び出し時に空文字列のみが渡されており、他のランタイム(CoreCLRなど)と異なる動作をしていました。この修正により、Monoでも環境変数から起動フックを正しく読み込めるようになり、ランタイム間の一貫性が向上します。

// 修正前の問題
// Mono側では DOTNET_STARTUP_HOOKS 環境変数を無視し、
// 手動でホスト設定を追加する必要があった
<RuntimeHostConfigurationOption Include="STARTUP_HOOKS" 
    Value="MyStartupHook" 
    Condition=" '$(UseMonoRuntime)' == 'true' " />

// 修正後
// CoreCLRと同じように DOTNET_STARTUP_HOOKS 環境変数が読み込まれる

変更内容

  • src/mono/mono/metadata/object.c: Mono の起動フック処理に環境変数読み込み機能を追加(+15行、-1行、計16行変更)

パフォーマンスへの影響

影響なし。起動フック処理は初期化フェーズで1回のみ実行され、環境変数の読み込みはランタイムの起動時間への顕著な影響はありません。

関連Issue

その他

  • 非破壊的変更:既存の RuntimeHostConfigurationOption での設定は継続して機能します
  • Monoランタイムを使用する開発者(特にAndroidプラットフォーム)にとって、ランタイム間の互換性が向上します

#123919 Reduce the amount of string copying and comparing when resolving assets on startup

  • 作成者: @elinor-fung
  • 作成日時: 2026年02月02日 23:39:22(UTC)
  • マージ日時: 2026年02月05日 18:14:18(UTC)
  • ラベル: area-Host

概要

アプリケーション起動時のアセット解決処理を最適化し、文字列の比較とコピーを削減しました。サービス提供ディレクトリ名との不要な文字列比較を回避し、TPA リスト構築時のdeps_asset_tアセットのコピーを削減することで、空のコンソールアプリケーション起動時に約1000個のメモリ割り当てを削減しました。ベンチマーク結果では平均起動時間が55.77msから55.48msに短縮(-0.5%)されており、標準偏差も0.50msから0.35msに改善されています。

変更内容

  • deps_resolver.cpp/h: アセット解決ロジックを最適化し、不要な文字列比較を排除。TPA リスト構築時のアセットコピーを削減
  • deps_format.cpp: 依存関係フォーマット処理の細微な調整(+4/-2)
  • deps_entry.h: エントリ定義の軽微な修正(+1/-1)
  • version.cpp/h: バージョン処理の補完的な変更(+6/-1、+2/-1)

パフォーマンスへの影響

改善点(メジャー):

  • メモリ割り当て削減: 空のコンソールアプリケーション起動時に約1000個の割り当て削減(アセンブリ数に比例)
  • 起動時間短縮: 平均 -0.29ms (-0.5%) の改善
  • 安定性向上: 標準偏差が 0.50ms → 0.35ms に改善(変動が少なくなり、より安定した起動性能を実現)
  • 10回の連続テスト全てで改善が確認される一貫性

関連Issue

#123919

その他

本最適化は hostpolicy の起動パス最適化に分類され、アプリケーション依存関係解決フェーズの処理効率向上に焦点を当てています。


#123897 Update branding to 9.0.14

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年02月02日 17:32:46(UTC)
  • マージ日時: 2026年02月05日 01:00:05(UTC)
  • ラベル: Servicing-approved

概要

.NET Runtime 9.0.14リリースに向けて、ブランディング・ファイルバージョン情報を更新するPull Requestです。ProductVersionとPatchVersionを9.0.13から9.0.14へ引き上げています。

変更内容

ファイル 変更内容
eng/Versions.props ProductVersion: 9.0.13 → 9.0.14 に更新
PatchVersion: 13 → 14 に更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このPull Requestはブランディング・バージョン管理のみの変更であり、ランタイムの機能実装やバグ修正を含みません。9.0.14リリース時にビルド成果物やアセンブリのバージョン情報が正確に反映されるための必須の準備作業です。


#123896 Update branding to 8.0.25

  • 作成者: @vseanreesermsft
  • 作成日時: 2026年02月02日 17:31:38(UTC)
  • マージ日時: 2026年02月05日 00:47:03(UTC)
  • ラベル: Servicing-approved

概要

.NET Runtime 8.0系の製品ブランディングバージョンを 8.0.24 から 8.0.25 へ更新するパッチリリースです。共有バージョン設定ファイルの ProductVersionPatchVersion を段階的に更新しています。

変更内容

  • eng/Versions.props: ProductVersion を 8.0.24 から 8.0.25 へ更新、PatchVersion を 24 から 25 へ更新(+2/-2行、計4行の変更)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

なし


#123888 Sve2: Add ShiftRightLogicalNarrowingSaturate(Even|Odd)

  • 作成者: @a74nh
  • 作成日時: 2026年02月02日 15:11:31(UTC)
  • マージ日時: 2026年02月05日 18:21:11(UTC)
  • ラベル: area-System.Runtime.Intrinsics community-contribution

概要

ARM SVE2命令セットに対する2つの新しいシフト命令 ShiftRightLogicalNarrowingSaturate(Even|Odd) を追加します。これらの命令は、ベクトル要素を論理的に右にシフトしながら、結果を狭い型に飽和させます。

// 使用例
Vector<ulong> input = ...;
Vector<uint> result = Sve2.ShiftRightLogicalNarrowingSaturateEven(input, shiftAmount);

変更内容

  • src/coreclr/jit/hwintrinsiclistarm64sve.h: JITコンパイラの命令リストに2つの新命令を登録
  • src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Arm/Sve2.cs: ShiftRightLogicalNarrowingSaturateEvenShiftRightLogicalNarrowingSaturateOddの実装を追加
  • src/libraries/System.Private.CoreLib/src/System/Runtime/Intrinsics/Arm/Sve2.PlatformNotSupported.cs: プラットフォーム非サポート版の実装を追加
  • src/libraries/System.Runtime.Intrinsics/ref/System.Runtime.Intrinsics.cs: パブリックAPI定義を追加
  • src/tests/Common/GenerateHWIntrinsicTests/Arm/Sve2Tests.cs: テストケースを追加

パフォーマンスへの影響

影響なし。新しいネイティブ命令へのマッピングであり、既存コードのパフォーマンスには影響しません。これらの命令は単一のハードウェア操作として実行されるため、従来の複数ステップの操作よりも効率的です。

関連Issue

#122022

その他

Copilotによるレビューで、テストコード内の一部ヘルパーメソッド参照が正確かどうかについて低信頼度の指摘がありますが、レビュアーの承認により進行しています。


#123779 [EventPipe] Add dotnet_ipc_created mapping

  • 作成者: @mdh1418
  • 作成日時: 2026年01月29日 22:57:33(UTC)
  • マージ日時: 2026年02月05日 19:45:37(UTC)
  • ラベル: area-Tracing-coreclr

概要

EventPipeに新しいマッピング dotnet_ipc_created を追加し、.NETプロセスの診断ポート(listen port)が正常に作成されたことを低オーバーヘッドで外部ツールに通知できるようにしました。従来は複数の一時ファイルディレクトリをスキャンする必要がありましたが、この変更によりプロセスの準備完了を効率的に検出できます。

変更内容

  • src/native/eventpipe/ds-ipc.c (+36/-3): IPC マッピング作成ロジックの実装。listen port 作成時に dotnet_ipc_created マッピングを生成
  • src/native/eventpipe/ds-ipc.h (+3/-0): IPC マッピング関連の関数シグネチャ追加
  • src/native/eventpipe/ep-shared-config.h.in (+2/-0): マッピング名の定義
  • src/native/eventpipe/configure.cmake (+16/-0): ビルド設定の追加

パフォーマンスへの影響

改善点: マッピング機構により、外部診断ツール(one-collectなど)がプロセスの IPC 準備完了を効率的に検出でき、ディレクトリスキャンによるオーバーヘッドが削減されます。マッピング自体は低オーバーヘッド設計です。

関連Issue

  • microsoft/one-collect#226 での討論に基づく実装

その他

NativeAOT 環境での userevents ランタイムテストが正常に動作することを確認済み。テストログから、record-trace が複数の .NET プロセスの診断ソケットを正常にオープンし、イベント収集が機能していることが示されています。


#123726 [browser] host improvements

  • 作成者: @pavelsavara
  • 作成日時: 2026年01月28日 18:59:13(UTC)
  • マージ日時: 2026年02月05日 11:30:04(UTC)
  • ラベル: arch-wasm area-Host os-browser

概要

WebAssembly上のブラウザホスト環境の改善を行うPull Requestです。ファイルシステム仮想化の統一、エラー検出の強化、メモリプローブ機能の追加などが含まれています。主にWasm環境での実行時の安定性と互換性を向上させています。

変更内容

ファイルシステム関連:

  • coreRunの簡略化(終了処理の削除)
  • browserVirtualAppBase定数を導入し、アプリケーションディレクトリを/に統一
  • VFSリソースの仮想パスをbrowserVirtualAppBase相対パスとして設定
  • 仮想作業ディレクトリ(virtualWorkingDirectory)を作成・設定

エラー検出・終了処理:

  • PortableEntryPoint::GetActualCodeでNULLチェックを厳密化(アサーション追加)
  • デバッガ接続状態の検出実装
  • すべてのタイマーをtry-catchでラップし、異常終了時にemscripten ___trap()を使用
  • NodeJS環境でのCLI自己設定サポートを廃止

その他の機能:

  • PAL_ProbeMemoryのブラウザ向け実装
  • R2R(Ready to Run)向けに-sALLOW_TABLE_GROWTH=1追加
  • アセットコード(browserhost/host/assets.ts)の整理
  • V8/D8シェル互換性の改善(オプショナルTextDecoderサポート)

パフォーマンスへの影響

記載された情報からはパフォーマンスベンチマーク値は提供されていません。-sALLOW_TABLE_GROWTH=1の追加により動的テーブル拡張が可能になりますが、具体的な実行速度やメモリへの影響は不明です。デバッガ接続検出とタイマーのキャッチラッピングは、実行オーバーヘッドが微小と考えられます。

関連Issue

記載情報より、PR #123501のフィードバック反映が含まれています。

その他

  • 65/66ファイルがCopilot AIレビュアーにより検証済み
  • ブラウザWasm環境での厳密なエラーハンドリング強化により、デバッグが容易化
  • NodeJS環境での自己設定廃止は、セットアップ方式の簡潔化を意図
  • 複数レビュワーによる段階的レビュー完了

#123721 Add AppContext switch for SignedInfo maximum number of references.

  • 作成者: @vcsjones
  • 作成日時: 2026年01月28日 17:02:30(UTC)
  • マージ日時: 2026年02月05日 03:11:57(UTC)
  • ラベル: area-System.Security

概要

SignedInfo クラスの <Reference> 要素の最大数を AppContext スイッチで設定可能にしました。従来は 100 に硬直していましたが、.NET Framework の互換性を復元し、多数の参照を含む SOAP メッセージなどのワークロードに対応します。

// 使用例:AppContext で最大参照数を設定
AppContext.SetSwitch("System.Security.Cryptography.MaxReferencesPerSignedInfo", 200);

変更内容

  • LocalAppContextSwitches.cs (新規追加): System.Security.Cryptography.MaxReferencesPerSignedInfo AppContext キーから設定値を読み込み、デフォルト 100 で無効値は 100 にフォールバック
  • SignedInfo.cs: 参照数チェックを Utils.MaxReferencesPerSignedInfo から LocalAppContextSwitches.MaxReferencesPerSignedInfo へ変更
  • Utils.cs: MaxReferencesPerSignedInfo 定数を削除
  • SignedXml_Limits.cs: RemoteExecutor を使用したテストを追加し、デフォルト値と AppContext スイッチの動作を検証
  • プロジェクトファイル: IncludeRemoteExecutor を有効化、LocalAppContextSwitches.cs をビルドに含める

パフォーマンスへの影響

影響なし。参照数チェックのロジックは変わらず、AppContext からの値読み込みは起動時の一度のみ。

関連Issue

#123665 - .NET Core でのSignedInfo参照数上限の設定不可の問題

その他

破壊的変更なし。既存コードは デフォルト100 のまま動作し、必要に応じて AppContext スイッチで上限を拡張可能。


#123666 Fix SVE long narrowing for shifts

  • 作成者: @a74nh
  • 作成日時: 2026年01月27日 12:19:33(UTC)
  • マージ日時: 2026年02月05日 23:02:11(UTC)
  • ラベル: area-CodeGen-coreclr community-contribution

概要

SVE(Scalable Vector Extension)における長いナロー化操作でのシフト処理のバグを修正しました。Issue #123496 に対応した修正で、JIT コンパイラのベクトル操作処理における問題を解決しています。

変更内容

  • src/coreclr/jit/simd.h: SVE ナロー化ロジックの改善(+17/-7)
  • src/coreclr/jit/gentree.cpp: ツリー生成時の処理調整(+2/-1)
  • src/coreclr/jit/valuenum.cpp: 値の番号付け処理の修正(+1/-1)

パフォーマンスへの影響

影響なし。本修正は正確性の改善であり、既存の正常な動作に対するパフォーマンス影響はありません。

関連Issue

Issue #123496 - SVE long narrowing with shifts の問題

その他

変更行数が少なく、3ファイルのみの修正であることから、限定的で重点的な修正と考えられます。ARM SVE 命令セットを使用する環境でのベクトル処理の正確性が向上します。


#123651 Fix debugger hangs due to runtime deadlock by using patch DJI

  • 作成者: @Copilot
  • 作成日時: 2026年01月27日 00:24:27(UTC)
  • マージ日時: 2026年02月05日 00:59:42(UTC)
  • ラベル: 指定なし

概要

DebuggerController::BindPatchメソッド内でGetJitInfo呼び出しがハッシュマップ検索時にロック順序違反を起こし、デバッガハングが発生する問題を修正。パッチにDebuggerJitInfo(DJI)が既に存在する場合、それを直接使用してGetJitInfo呼び出しを回避することで、ロック競合を排除します。

// 修正例(C++の実装)
DebuggerJitInfo *info = patch->HasDJI() ? patch->GetDJI() : g_pDebugger->GetJitInfo(pMD, (const BYTE *)startAddr);

変更内容

  • ファイル: src/coreclr/debug/ee/controller.cpp
  • 変更: +3行、-1行(合計4行の修正)
  • BindPatchメソッドを修正し、patch->HasDJI()で DJI の存在確認を追加
  • DJI が存在する場合は patch->GetDJI() を使用
  • DJI が存在しない場合のみ GetJitInfo() を呼び出し(後方互換性維持)

パフォーマンスへの影響

改善あり:

  • ReadyToRunメソッドのブレークポイント設定時に、不要なハッシュマップ検索を回避
  • ロック競合による待機時間を削減し、デバッガ応答性が向上
  • 既に取得済みのDJI情報を再利用することで、メモリアクセスコストを低減

関連Issue

  • dotnet/runtime#123650(Debugger hangs due to runtime deadlock. HashMap takes ThreadStore out of order)

その他

セキュリティ: 脆弱性なし
リスク評価: 低リスク

  • API 仕様変更なし、BindPatchのシグネチャ不変
  • ロジック流は不変、既存データの活用のみ
  • 全CoreCLRビルド合格
  • パッチが既にDJIを保持しているため、追加パラメータ不要な設計
  • パッチなしの場合も従来のGetJitInfo呼び出しで互換性を維持

#123618 [release/8.0-staging] Update dependencies from dotnet/hotreload-utils

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月26日 09:35:06(UTC)
  • マージ日時: 2026年02月05日 00:02:26(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet/hotreload-utils の依存関係を更新するPull Requestです。Microsoft.DotNet.HotReload.Utils.Generator.BuildTool が バージョン 8.0.0-alpha.0.25625.3 から 8.0.0-alpha.0.26076.2 に更新されています。これは release/8.0 ブランチの自動依存関係更新です。

変更内容

  • eng/Version.Details.xml (+2/-2): HotReload.Utils のバージョン情報とコミットハッシュを更新
  • eng/Versions.props (+1/-1): Microsoft.DotNet.HotReload.Utils.Generator.BuildTool のバージョンを更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 自動更新: このPRは dotnet-maestro[bot] による自動依存関係更新です
  • 更新日時: 2026年1月26日 9:10:24 UTC
  • 更新元ブランチ: dotnet/hotreload-utils の release/8.0 ブランチ

#123516 [main] Update dependencies from dnceng/internal/dotnet-optimization

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月22日 23:39:09(UTC)
  • マージ日時: 2026年02月05日 21:06:11(UTC)
  • ラベル: area-codeflow

概要

このPull Requestは、dotnet-optimizationリポジトリからの依存関係を自動更新するものです。MIBC(Machine Intelligent Bytecode Commit)RuntimeおよびPGO(Profile-Guided Optimization)CoreCLRの最適化パッケージが、バージョン1.0.0-prerelease.25502.1から1.0.0-prerelease.26080.1に更新されました。Linux ARM64/x64、Windows NT ARM64/x64/x86の各プラットフォーム向けの最適化データが含まれています。

変更内容

ファイル 変更内容
eng/Version.Details.props バージョン参照情報の更新(+6/-6)
eng/Version.Details.xml 依存関係メタデータの更新(+12/-12)

更新された依存関係パッケージ:

  • optimization.linux-arm64.MIBC.Runtime
  • optimization.linux-x64.MIBC.Runtime
  • optimization.windows_nt-arm64.MIBC.Runtime
  • optimization.windows_nt-x64.MIBC.Runtime
  • optimization.windows_nt-x86.MIBC.Runtime
  • optimization.PGO.CoreCLR

パフォーマンスへの影響

MIBC Runtimeおよび PGO CoreCLRの最適化データの更新により、ランタイムの実行パフォーマンスが向上する可能性があります。これらのパッケージはJIT最適化とランタイム効率を向上させるために使用されます。具体的なパフォーマンス数値は提供されていませんが、最新の最適化データへの更新は全般的なスループット改善につながることが期待されます。

関連Issue

なし

その他

  • このPRはdotnet-maestro[bot]による自動化された依存関係更新です
  • ビルド日時:2026年1月30日 10:43:43 UTC
  • 複数のプラットフォーム(Linux、Windows、ARM/x64/x86)に対応した最適化パッケージが統一されて更新されています

#123436 [release/9.0-staging] Update dependencies from dotnet/hotreload-utils

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月21日 15:31:22(UTC)
  • マージ日時: 2026年02月05日 00:00:18(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet/hotreload-utils の依存パッケージを 9.0.0-alpha.0.25625.4 から 9.0.0-alpha.0.26104.3 にアップデートする自動的な依存パッケージ更新PRです。Microsoft.DotNet.HotReload.Utils.Generator.BuildTool のバージョンアップが含まれており、release/9.0-staging ブランチへの定期的なメンテナンス更新です。

変更内容

  • eng/Version.Details.xml (+2/-2): HotReload Utils パッケージメタデータの更新、コミット参照の更新
  • eng/Versions.props (+1/-1): Microsoft.DotNet.HotReload.Utils.Generator.BuildTool バージョン番号の更新
  • NuGet.config (+0/-1): パッケージソース設定の調整

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

このPRは dotnet-maestro[bot] による自動依存更新です。release/9.0-staging ブランチの定期的なメンテナンス更新であり、HotReload機能に関する Build Tool の改善が含まれています。


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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月20日 23:14:32(UTC)
  • マージ日時: 2026年02月05日 00:01:08(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

このPRは、dotnet/emsdkリポジトリからの依存関係を更新するものです。Emscripten関連のWorkloadマニフェストを9.0.13から9.0.14へアップグレードし、複数のプラットフォーム向けJITツールとMono LLVM関連パッケージの一貫性を確保しています。.NET 9.0ブランチのサービス版・安定版の両方のパッケージが更新対象です。

変更内容

  • NuGet.config: NuGetフィードの設定を更新(1行追加、1行削除)
  • eng/Version.Details.xml: 依存関係のバージョン詳細を更新(50行追加、50行削除)
    • Microsoft.SourceBuild.Intermediate.emsdk: 9.0.13-servicing.26059.3 → 9.0.14-servicing.26102.1
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: 同様に更新
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100: 9.0.13 → 9.0.14
  • eng/Versions.props: バージョン定義を更新(24行追加、24行削除)

一貫性更新(Coherency Updates):

  • JIT Tools: linux-arm64、linux-x64、linux-musl-arm64、linux-musl-x64、win-arm64、win-x64、osx-arm64、osx-x64向け
    • バージョン: 19.1.0-alpha.1.25625.1 → 19.1.0-alpha.1.26071.2
  • Mono LLVM SDK/Tools: 同じプラットフォーム向けに同一バージョンで更新

パフォーマンスへの影響

影響なし。このPRは依存関係のバージョン更新のみで、ランタイムコード変更を含みません。

関連Issue

なし

その他

  • このPRは自動化されたdotnet-maestroボットにより作成されています(依存関係の自動同期)
  • release/9.0ブランチを対象としており、.NET 9.0のサービス版更新に該当します
  • 複数プラットフォーム向けのコンポーネントが一貫性を保つように更新されています

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

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年01月20日 22:40:41(UTC)
  • マージ日時: 2026年02月05日 18:49:37(UTC)
  • ラベル: Servicing-approved area-codeflow

概要

dotnet/emsdk(Emscripten SDK)の依存関係を更新するPull Requestです。release/8.0ブランチにおいて、Microsoft.SourceBuild.Intermediate.emsdkおよびMicrosoft.NET.Workload.Emscripten.Current.Manifestを8.0.25へアップグレードしています。この更新により、WebAssembly開発向けのEmscripten関連ツールチェーンが最新化されます。

変更内容

  • eng/Version.Details.xml: emsdk依存関係のバージョン情報を更新(+4/-4行)
    • Microsoft.SourceBuild.Intermediate.emsdk: 8.0.24-servicing.26056.3 → 8.0.25-servicing.26102.2
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: 8.0.24 → 8.0.25
  • eng/Versions.props: プロパティファイルのバージョン定義を更新(+1/-1行)
  • NuGet.config: NuGetリソース設定を更新(+1/-1行)

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • このPull Requestはdotnet-maestro[bot]による自動依存関係更新です
  • dotnet/emsdk リポジトリのcommit badf9f97aaf4c2166b17bd6475ca73958c11e309が対象
  • 2026年2月3日にビルド ID 20260202.2として自動生成されました

#123142 [clr-interp] Add Swift calling convention support to CoreCLR interpreter on arm64

  • 作成者: @kotlarmilos
  • 作成日時: 2026年01月13日 17:05:09(UTC)
  • マージ日時: 2026年02月05日 10:13:25(UTC)
  • ラベル: area-CodeGen-Interpreter-coreclr

概要

CoreCLR interpreter on arm64にSwift呼び出し規約のサポートを追加しました。Swiftは標準arm64 ABIと異なる呼び出し規約を使用しており、専用レジスタ(x20=self、x21=error、x8=indirect result)とstruct値型の引数・戻り値のloweringに対応しています。

変更内容

  • callstubgenerator.cpp/h: SwiftSelf、SwiftError、SwiftIndirectResultの処理とstruct値型のlowering実装(920行追加)
  • asmhelpers.S: Swiftlowered構造体戻り値対応の新アセンブリルーチン追加(496行追加)
  • asmconstants.h: Swift関連の定数定義追加
  • unixasmmacrosarm64.inc: arm64アセンブリマクロ拡張
  • corelib.h/namespace.h: 名前空間・定義追加
  • テスト: SwiftCallbackAbiStress、SwiftErrorHandling、SwiftIndirectResultのテストケース追加

パフォーマンスへの影響

影響なし。本変更はSwift呼び出し規約を正しく処理するための呼び出しスタブ生成のみで、既存のコード実行パスへの変更はありません。

関連Issue

#120049に関連します

その他

  • x64とUnmanagedCallersOnlyは現在の対応外で、今後のフォローアップで実装予定
  • SwiftSelfが構造体をx20に渡す場合、構造体がlowering可能な場合は通常の引数として処理され、そうでない場合はアドレスをx20に読み込まれます
  • Swiftでは4ワード以内の構造体は複数の引数にlowerされるため、新しいload/store ルーチンでフィールドオフセットから直接読み書きされます

#122722 Runtime-async Exception.ToString()

  • 作成者: @rcj1
  • 作成日時: 2025年12月24日 05:50:09(UTC)
  • マージ日時: 2026年02月05日 04:22:55(UTC)
  • ラベル: area-ExceptionHandling-coreclr area-NativeAOT-coreclr runtime-async

概要

このPRは、CoreCLRとNativeAOT両方の実行時における非同期スタック(runtime-async stacks)でのスタックトレース収集を実装します。Exception.ToString()で非同期待機チェーン(async-await chain)のフレームを例外スタックトレースに含めることで、より完全なスタックトレース情報を提供します。主な実装は、AsyncHelpers内でContinuationのDiagnosticIPを使用してフレームを追加し、ThrowExactヘルパーで既存のスタックトレースを保持しながら例外を再スロー(ExKind.RethrowFlagを利用)することです。

変更内容

  • AsyncHelpers.CoreCLR.cs: スタック巻き戻しロジックを拡張し、runtime-async async-await チェーンからのフレームを例外スタックトレースに追加(+22行)
  • Exception handling(複数アーキテクチャ): amd64, arm, arm64, i386, loongarch64, riscv64のExceptionHandlingアセンブリを更新し、ThrowExactヘルパーロジックを実装
  • ILC(IL Compiler): StackTraceEmissionPolicy、JitHelper、CorInfoImplを修正し、runtime-async メソッドのスタックトレースレコード生成とレジューメーションスタブの非表示化を実装
  • ReadyToRun形式: readytorun.h、ReadyToRunConstants.csを更新し、新しいフラグ定義を追加
  • テスト: v1-v2チェーンを含む行番号/メソッド/ドキュメント正確性のテストを追加

パフォーマンスへの影響

スタックトレース収集は例外発生時の処理であるため、通常の実行パスのパフォーマンスへの影響は最小限と考えられます。ただし、例外がスロー・キャッチされる際のスタックトレース生成処理が追加されるため、例外処理が頻繁に行われるコードではわずかなオーバーヘッドが発生する可能性があります。詳細なベンチマーク結果は提供されていません。

関連Issue

なし

その他

  • 複数のアーキテクチャ(x86/x64/ARM/ARM64/LoongArch64/RISC-V)での対応が実装されており、広範囲なプラットフォームサポートを備えています
  • RethrowFlagの命名について、PRでは「NoEraseFlag」などへの改名も提案されていますが、最終的には現状のままとなっています
  • このPRは@dotnet/ilc-contribグループにレビューが求められており、複数のコアコントリビューターによる綿密なレビューが行われています

#120535 Fix indentation and formatting inconsistencies in .json files (#119468)

  • 作成者: @amritanand-py
  • 作成日時: 2025年10月08日 15:10:50(UTC)
  • マージ日時: 2026年02月05日 17:34:05(UTC)
  • ラベル: area-Meta linkable-framework community-contribution

概要

このPRは、dotnet/runtimeリポジトリ全体の.jsonファイルにおけるインデンテーションとフォーマットの不一致を修正するものです。セマンティックな変更は一切なく、スタイル・フォーマットのみを統一しています。約40個のJSONファイルを2スペースインデント(またはプロジェクト定義のインデント)に統一し、余分な空白を削除して構造を整理しました。

変更内容

  • 設定ファイル: .config/CredScanSuppressions.json.github/workflows/markdownlint-problem-matcher.json.markdownlint.jsonなど計8ファイル
  • ネイティブサイニング関連: eng/native/signing/配下のauth.jsonconfig.jsoninput.template.jsonpolicy.json
  • テスト構成: eng/testing/xunit/xunit.runner.jsonruntimeconfig.template.json
  • メタデータ更新スクリプト: System.Runtime.Loader/tests/ApplyUpdate/配下の31個のdeltascript.jsonファイル

全変更ファイルは合計約40ファイル、追加・削除の行数はほぼ同数(フォーマット変更のため)。

パフォーマンスへの影響

影響なし
JSONファイルはビルド時に読み込まれる設定・テストメタデータであり、インデンテーション変更は実行時パフォーマンス、ファイルサイズ、パースに影響しません。

関連Issue

#119468

その他

  • 破壊的変更: なし。JSONの意味的構造は完全に保持
  • レビュー観点: 大規模なフォーマット変更PR(~40ファイル)のため、差分の確認はツールの視認性設定を活用することを推奨

目次