注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
- #124148 Add a code review skill based on past PR interactions
- #124146 Add official build freshness check to vmr-codeflow-status skill
- #124137 [Wasm RyuJit] fix local type encoding
- #124135 Document canceled job recovery in helix Copilot skill
- #124129 [skill] Use Version.Details.xml as VMR snapshot fallback for manual backflow
- #124128 Fix JIT range analysis Multiply for ranges spanning negative values
- #124120 Remove HAVE_CLOCK_MONOTONIC and dead fallback code
- #124058 [release/10.0] [EventPipe] Add dotnet_ipc_created mapping
- #124041 Default to ninja for faster builds (mac & linux)
- #123956 Fix Crossgen2 failure on trimmed intrinsic types
#124148 Add a code review skill based on past PR interactions
- 作成者: @stephentoub
- 作成日時: 2026年02月08日 18:58:22(UTC)
- マージ日時: 2026年02月08日 19:34:13(UTC)
- ラベル: area-skills
概要
このPull Requestは、GitHubのCopilot統合に関する設定を更新するもので、過去のPRでのインタラクションに基づいたコードレビュースキルを追加しています。Copilot指示ファイルの更新と、新しいコードレビュースキル定義ファイルの追加が含まれています。
変更内容
.github/copilot-instructions.md (+4行)
- Copilot統合の指示設定に4行の追加
.github/skills/code-review/SKILL.md (+585行)
- 新規ファイル追加
- 過去のPRインタラクションを基盤としたコードレビュースキルの定義を記載
パフォーマンスへの影響
影響なし（設定ファイルの追加のため、ランタイムパフォーマンスへの直接的な影響はありません）
関連Issue
なし
その他
本変更はCopilotのコードレビュー機能をdotnet/runtimeリポジトリに統合するための基盤構築であり、CI/CDパイプラインやレビュープロセスに組み込まれるスキル定義です。実装者はstephentoubであり、jkotasによるレビューが行われています。
#124146 Add official build freshness check to vmr-codeflow-status skill
- 作成者: @lewing
- 作成日時: 2026年02月08日 17:57:38(UTC)
- マージ日時: 2026年02月08日 20:08:30(UTC)
- ラベル: area-skills
概要
VMR（Visual Studio Runtime）公式ビルドの鮮度確認機能を追加し、Codeflow状態スキルの診断精度を向上させました。aka.ms経由で最後に成功したビルドのタイムスタンプを取得し、バックフロー停止の真の原因を特定できるようになります。従来の誤解を招く「Maestroが停止している可能性」という警告から、より正確な「アップストリームのビルドが古い」という診断に改善されました。
変更内容
- Get-VMRBuildFreshness関数: aka.ms/dotnet//daily/dotnet-sdk-win-x64.zipへのHEADリクエストで最後のビルド公開時刻を取得
- Get-CodeflowPRHealth関数: MaestroコメントとCodeflow検証ステータスから競合/古さを検出し、解決済みの競合を区別
- 診断メッセージ改善: 明確なエラーメッセージ（例：「backflow blocked upstream」）とHttpResponseMessageの適切なリソース破棄
- vmr-build-topology.md追加: ビルドパイプライン構造とdarc検証の参考ドキュメント
パフォーマンスへの影響
HttpClient使用による統一化と15秒のタイムアウト設定により、ハングアップのリスク軽減。複数のバックフロー/フォワードフロー検査時に一度のビルド確認で済むため、診断時間は大きく変わらず。HttpResponseMessageの適切な破棄でメモリリーク防止。
関連Issue
なし
その他
bugfix: マージ済みPR選択時にclosedAt比較を使用することでgh search --sort updatedの順序に依存しない正確な判定を実現。gh search失敗時の明示的な警告追加。
#124137 [Wasm RyuJit] fix local type encoding
- 作成者: @AndyAyersMS
- 作成日時: 2026年02月08日 02:37:23(UTC)
- マージ日時: 2026年02月08日 21:52:44(UTC)
- ラベル: arch-wasm area-CodeGen-coreclr
概要
WASM RyuJit コンパイラのローカル型エンコーディングの不具合を修正しました。WasmValueType enum の順序と typecode_mapping ルックアップテーブルの順序が一致していなかったため、正しい順序に再整列しました。
変更内容
- src/coreclr/jit/emitwasm.cpp:
GetWasmValueTypeCode関数内のtypecode_mappingテーブルをWasmValueTypeenum の定義順に合わせるため再整列（+4/-4） - インラインコメントを修正して、正確な enum-to-インデックスマッピングを反映
パフォーマンスへの影響
影響なし。本修正はエンコーディングロジックの正確性を確保するもので、パフォーマンス特性の変更はありません。
関連Issue
不具合を示唆する詳細なIssueは記載されていません。
その他
WASM バイナリへのコンパイル時にローカル変数の型情報が誤ってエンコードされていた可能性があります。この修正により、WASM ランタイムが正しい型情報に基づいて実行されるようになります。テーブルインデックスのミスマッチはランタイム動作に影響を与える可能性があるため、回帰テストによる検証が推奨されます。
#124135 Document canceled job recovery in helix Copilot skill
- 作成者: @lewing
- 作成日時: 2026年02月08日 01:07:37(UTC)
- マージ日時: 2026年02月08日 02:33:14(UTC)
- ラベル: area-skills
概要
Azure DevOpsのタイムアウトなどによってキャンセルされたジョブから、Helixのテスト結果を回復する方法をドキュメント化しました。キャンセルされたジョブでもパイプラインアーティファクトに含まれるSendToHelix.binlogからHelixジョブIDを抽出し、Helix APIで直接クエリして結果を回復できることを解説しています。
変更内容
.github/skills/azdo-helix-failures/SKILL.md: 「Recovering Results from Canceled Jobs」セクションを追加（+16/-1）- キャンセルされたジョブからの回復ワークフローを文書化
- アーティファクトダウンロード → binlog読み込み → HelixジョブID抽出 → Helix API クエリの手順を説明
- PR #124125の具体例（3時間のタイムアウトキャンセルにも関わらず226個のワークアイテムすべてが成功）を記載
- binlog分析用のMCP サーバーの活用についてのTipを追加
パフォーマンスへの影響
影響なし
関連Issue
- #124125（関連する調査対象のIssue）
その他
このドキュメント化により、CI/CDパイプラインのタイムアウト発生時に、テスト結果が失われたかのように見える状況でも、実際の結果を回復可能なオペレーション手順が確立されました。開発チームがトラブルシューティングで無駄な再実行を避けられるようになります。
#124129 [skill] Use Version.Details.xml as VMR snapshot fallback for manual backflow
- 作成者: @lewing
- 作成日時: 2026年02月07日 07:29:33(UTC)
- マージ日時: 2026年02月08日 02:44:35(UTC)
- ラベル: area-skills
概要
dotnet/runtimeのVMRコードフロー状態スクリプトを改善し、Version.Details.xmlをVMRスナップショットの主要ソースとして使用するようになりました。手動バックフロー（darc vmr backflow）時にPRボディメタデータが古くなる問題を解決し、フォワードフロー（product repo → dotnet/dotnet）のスキャン機能も追加されました。
// Version.Details.xmlから<Source Sha=...>を解析する優先度
// 1. ng/Version.Details.xml内のSHA（正規表現フォールバック付き）
// 2. コミットメッセージ（セカンダリ確認）
// 3. PRボディ（最後の手段）
変更内容
Get-CodeflowStatus.ps1 (+166/-42)：
- Version.Details.xmlをVMRスナップショットの一次ソースとして解析追加
- 40文字SHA検証とケース非感応SHA比較の実装
-CheckMissingでオープンなフォワードフローPR（dotnet/sdk、dotnet/runtime）をスキャン- Maestroコメント解析による競合性と鮮度検出
- すべての
gh呼び出しで2>&1を使用してstderr分離
SKILL.md (+8/-5)：
- ドキュメント更新（フォワードフロー機能の説明追加）
パフォーマンスへの影響
影響なし。スクリプト実行時間は既存処理に統合されるため、顕著なパフォーマンス低下はありません。複数リポジトリのPRスキャンが追加されていますが、既存のコードフロー状態チェック内で実施されます。
関連Issue
なし
その他
注意点：
- Copilotが指摘した通り、
$repoShortNameの導出方法に潜在的な問題あり：現在はdotnet/プレフィックスのみ削除されているため、非dotnet/*リポジトリを使用する場合は不正な検索文字列が生成される可能性があります - 実装されたテストカバレッジ：sdk#52727（手動バックフロー不一致）、sdk#52885（競合）、aspnetcore#65338（削除ブランチ）など複数シナリオで検証済み
#124128 Fix JIT range analysis Multiply for ranges spanning negative values
- 作成者: @Copilot
- 作成日時: 2026年02月07日 05:42:36(UTC)
- マージ日時: 2026年02月08日 22:11:20(UTC)
- ラベル: needs-area-label
概要
JIT の範囲分析において、乗算演算が負の値を含む範囲に対して不正な結果を返していた問題を修正しました。例えば [-100..100] * [0..10] が [0..1000] ではなく正しく [-1000..1000] を返すようになります。標準的な区間演算のアプローチを採用し、4つのエンドポイント積すべての最小値・最大値を計算することで解決しています。
// 修正前の問題例
// (ushort)1 * (sbyte)(-1) で不正な結果が生成されていた
byte[] vr9 = s_12[0];
long vr10 = (ushort)s_4 * (sbyte)(-s_4); // キャスト関連の最適化で誤った範囲に基づく生成コード
変更内容
src/coreclr/jit/rangecheck.h:
RangeOps::Multiplyメソッドを改修- 定数範囲のチェック追加
- 4つのエンドポイント積（
r1lo*r2lo,r1lo*r2hi,r1hi*r2lo,r1hi*r2hi）のオーバーフロー検査 - すべての積から最小値・最大値を計算する正確な境界決定
src/tests/JIT/Regression/JitBlue/Runtime_124082/Runtime_124082.cs: Fuzzlyn生成の回帰テスト追加
パフォーマンスへの影響
影響なし オーバーフローチェックが4回発生しますが、これは定数範囲に限定されるため、JIT コンパイル時のみの処理です。生成されるコードの実行時パフォーマンスに影響を与えません。むしろ、不正な範囲推測に基づいた不適切な最適化が排除されるため、コード生成の正確性が向上します。
関連Issue
#124082 - JIT: Bad result with multiplication and casts
その他
このバグは PR #123233 で導入され、キャストを伴う乗算式の最適化時に不正なコード生成を引き起こしていました。Fuzzlyn ファジングで検出されたこの問題は、負の値を含む範囲演算の処理が誤っていたことが根本原因です。
#124120 Remove HAVE_CLOCK_MONOTONIC and dead fallback code
- 作成者: @Copilot
- 作成日時: 2026年02月07日 01:43:06(UTC)
- マージ日時: 2026年02月08日 09:06:12(UTC)
- ラベル: area-PAL-coreclr
概要
HAVE_CLOCK_MONOTONIC マクロをすべてのUnix系プラットフォームから削除するリファクタリングです。このマクロはすべてのサポート対象プラットフォームで常に1に定義されているため、マクロ定義とその関連フォールバックコードを完全に削除し、clock_gettime(CLOCK_MONOTONIC, ...) の使用を標準化します。
変更内容
設定ファイルの削除
- CMakeおよび設定ヘッダ（
config.h.in）からHAVE_CLOCK_MONOTONICチェックを削除 - 対象：CoreCLR PAL、Mono、ネイティブライブラリ、minipalの設定ファイル
- キャッシュファイル（
tryrun.cmakeシリーズ）から設定値を削除
ランタイムコードの簡素化
- src/native/minipal/time.c: 条件付きブランチを削除し、
clock_gettime(CLOCK_MONOTONIC)に統一 - src/native/libs/System.Native/pal_threading.c、pal_crossprocessmutex.c:
HAVE_PTHREAD_CONDATTR_SETCLOCKのみに依存するよう簡素化 - src/coreclr/pal/src/synchmgr/synchmanager.cpp:
GetAbsoluteTimeout()からfPreferMonotonicClockパラメータを削除（常にTRUEだったため） - src/mono/mono/utils/mono-time.c:
#ifdef HAVE_CLOCK_MONOTONICを#ifdef CLOCK_MONOTONICに変更（Windows WASMビルド対応） - src/mono/mono/eventpipe/ep-rt-mono.c: Apple向けの
#undef HAVE_CLOCK_MONOTONICワークアラウンドとgettimeofday()フォールバックを削除
統計: 17ファイルで計81行削減
パフォーマンスへの影響
影響なし。本変更はコード最適化ではなく、不要な条件分岐を削除する純粋なリファクタリングです。すべてのサポート対象プラットフォームで CLOCK_MONOTONIC が常に利用可能であるため、実行時動作に変更はありません。むしろ、不要な条件判定コードが削除されることでコード保守性が向上します。
関連Issue
なし
その他
- 全ビルド成功、CI検証済み
- テスト失敗はこのPRと無関係の既知問題（#124052、#110173）
- Windows WASMビルド対応：
HAVE_CLOCK_MONOTONICマクロではなく、標準的なPOSIX定数CLOCK_MONOTONICを直接チェック
#124058 [release/10.0] [EventPipe] Add dotnet_ipc_created mapping
- 作成者: @github-actions[bot]
- 作成日時: 2026年02月05日 19:49:10(UTC)
- マージ日時: 2026年02月08日 10:10:44(UTC)
- ラベル: Servicing-approved area-Tracing-coreclr
概要
.NET 10のUser_events機能をNativeAOTで動作可能にするため、診断ポート（diagnostic ports）の可用性を通知するためのdotnet_ipc_createdメモリマッピングを追加しました。このマッピングはPROT_NONEパーミッションを持つプライベートマッピングで、One-Collectのrecord-traceツールがNativeAOTでUser_eventsを有効化できるようになります。
// dotnet_ipc_createdマッピング作成時の概要
// PROT_NONEの最小限のパーミッションで、.NETプロセスの診断ポート可用性を通知
変更内容
- src/native/eventpipe/ds-ipc.c:
dotnet_ipc_createdマッピングの作成実装を追加（+36行） - src/native/eventpipe/ds-ipc.h: マッピング関連の関数宣言追加（+3行）
- src/native/eventpipe/configure.cmake: ビルド設定にマッピング作成処理を追加（+16行）
- src/native/eventpipe/ep-shared-config.h.in: 設定ヘッダに定義追加（+2行）
パフォーマンスへの影響
影響なし。dotnet_ipc_createdはPROT_NONEのプライベートマッピングであり、メモリへのアクセス操作を伴わないため、実行時のパフォーマンスへの影響はありません。
関連Issue
#123779（メインブランチへのPull Request） https://github.com/microsoft/one-collect/issues/226（NativeAOT互換性の議論）
その他
- 影響範囲: CoreCLRおよびNativeAOTの両方で検証済み
- リスク評価: 低リスク。最小限のパーミッション（PROT_NONE）で実装
- 対象: release/10.0ブランチへのバックポート版
- テスト: User_eventsランタイムテストで検証済み
#124041 Default to ninja for faster builds (mac & linux)
- 作成者: @steveisok
- 作成日時: 2026年02月05日 13:01:40(UTC)
- マージ日時: 2026年02月08日 06:38:12(UTC)
- ラベル: area-Infrastructure
概要
dotnet/runtime のビルドシステムで、macOS と Linux のデフォルトビルドツールを Ninja に変更するPRです。ベンチマーク結果によると、macOS では平均 654 秒から 718 秒への改善により、約 8.8% の高速化が期待されます。ユーザーは --ninja false オプションで従来のビルドシステムに戻すことができます。
変更内容
- eng/build.sh: Ninja をデフォルトのビルドツールに設定
- eng/native/build-commons.sh: macOS で Ninja をデフォルト化、
-ninja falseでオプトアウト可能に - docs/workflow/requirements/: macOS、Linux、FreeBSD の要件ドキュメントを更新（Ninja 関連の記述を修正）
- src/coreclr/build-runtime.sh、src/tests/build.sh: 不要な Ninja 指定を削除
パフォーマンスへの影響
改善: macOS でのビルド時間が約 8.8% 高速化（平均 718 秒 → 654 秒）。Linux でも同様の改善が期待されます。Ninja はより効率的な並列ビルドを提供するため、マルチコア環境での性能向上が見込めます。
関連Issue
https://github.com/dotnet/runtime/issues/54022
その他
- ユーザーは
--ninja falseまたは-ninja false（ネイティブビルドの場合）でオプトアウト可能 - ドキュメント更新により、Ninja の導入要件や使用方法が明確化されます
- Copilot のコードレビューでは新たなコメントは生成されておらず、品質が確認されています
#123956 Fix Crossgen2 failure on trimmed intrinsic types
- 作成者: @Copilot
- 作成日時: 2026年02月03日 19:00:51(UTC)
- マージ日時: 2026年02月08日 10:47:59(UTC)
- ラベル: area-crossgen2-coreclr
概要
Crossgen2がトリミングされたハードウェア拡張機能型を含むプロジェクトをコンパイルする際のTypeLoadException失敗を修正しました。InstructionSetGeneratorを改修し、型のロック時にGetType(..., false)を使用してnullを返すようにし、nullチェックを追加することで、トリミングされた型を適切にスキップできるようになります。
// 変更前: 型が見つからない場合に例外を発生
var type = Type.GetType("System.Runtime.Intrinsics.Arm.Crc32", true);
// 変更後: 型が見つからない場合にnullを返す
var type = Type.GetType("System.Runtime.Intrinsics.Arm.Crc32", false);
if (type != null)
{
// 型を処理
}
変更内容
- InstructionSetGenerator.cs: コード生成テンプレートを更新し、親型およびネストされた型の両方に対してnull安全な型ロックアップを生成するようにしました。
- CorInfoInstructionSet.cs: 自動生成ファイルを再生成し、ARM64、X64、X86アーキテクチャ全体のすべての命令セットに対してnull安全な型ロックアップ実装を適用しました。
パフォーマンスへの影響
影響なし。null チェックの追加はオーバーヘッドが極めて小さく、むしろビルド成功により全体的には改善されます。
関連Issue
dotnet/runtime#123953
その他
Mac Catalystなどのトリミング環境でハードウェア拡張機能型が除去されている場合、Crossgen2がビルド失敗することなく正常に完了するようになります。これはトリミングされた型はコンパイルルートに追加されるべきではないという正しい動作です。