Pull Request on 2026年02月13日

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

注意点

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

目次

  1. #124398 ci-analysis skill: let the agent reason about its own tools
  2. #124381 Fix ConnectAsync sending stale ReceiveAsync buffer via ConnectEx
  3. #124376 Disable TestStackOverflowLargeFrameMainThread for x64 on Unix
  4. #124372 [native] Fix build of strrchr
  5. #124367 Skip special formatting for stackoverflow exceptions in trivial cases
  6. #124360 JIT: don't set liveness on unreachable blocks
  7. #124359 ci-analysis skill: MSBuild guidance, merge commit shortcut, MCP alternatives
  8. #124358 Consolidate CoreCLR pipeline platform matrices and migrate NativeAOT to ARM64 macOS
  9. #124348 SPMI: Run NuGet authentication in target container
  10. #124343 SPMI: Run superpmi-diffs on windows-x64
  11. #124330 Fix Optimization Profile writing
  12. #124309 [cDAC] Magic enums - add comments to native code where they are defined so that we know to version the cDAC when they change. Also prune unused or suboptimal enums from cDAC.
  13. #124283 Avoid resolving direct awaits to thunks
  14. #124264 Add ProcessExitStatus class to System.Diagnostics.Process
  15. #124248 Update IServiceScopeFactory.CreateScope docs to clarify transient service disposal
  16. #124205 [Wasm RyuJIT] Start generating relocations for call_indirect
  17. #124152 Increase timeout on OneFuzz deployment pipeline
  18. #123962 [browser] native - no process, no signals, no threads, no blocking
  19. #123932 Fix parsing inconsistencies between Uri ctors and TryCreate factories
  20. #123735 [CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler
  21. #123601 Added Adler32 to System.IO.Hashing.

#124398 ci-analysis skill: let the agent reason about its own tools

  • 作成者: @lewing
  • 作成日時: 2026年02月13日 19:04:57(UTC)
  • マージ日時: 2026年02月13日 22:00:56(UTC)
  • ラベル: needs-area-label

概要

ci-analysis skillをリファクタリングし、AIエージェントのプロンプトから明示的なMCPツール名参照を削除しました。エージェントは既に実行時にツールの説明とパラメータを保有しているため、skillはドメイン知識（落とし穴、優先順位、データ位置、アンチパターン）に集中すべきという設計思想の実装です。ツール呼び出しの連鎖をアクション説明に置き換え、パラメータレベルの詳細をワークフローガイダンスに変更しました。

変更内容

  • .github/skills/ci-analysis/SKILL.md: コア定義を整理（+6/-7行）
  • binlog-comparison.md: ステップバイステップのツール呼び出し指示を削除（+9/-34行）
  • build-progression-analysis.md: 同様にツール名参照とパラメータ詳細を削除（+7/-27行）
  • delegation-patterns.md: サブエージェント委譲プロンプトをツール呼び出しから目標説明に変更（+9/-12行）
  • azure-cli.md, helix-artifacts.md, manual-investigation.md: ドメイン知識を保持しながら冗長性を削減

総計: 89行削除、45行追加 — メンテナンス負荷削減、ツール変更時の影響を最小化

パフォーマンスへの影響

影響なし。本変更はAIエージェントのプロンプト品質改善に関するもので、実行時パフォーマンスへの直接的な影響はありません。

関連Issue

PR #124095（実際のCI調査に基づくテスト対象）

その他

テスト状況: Claude Sonnet 4およびGPT-5で多モデルテスト済み。両モデルともskill内に明示的ツール名がない状態で、すべてのシナリオで正しいツール選択と実行を確認。

注記: Copilotレビューで低信頼度コメント1件あり——delegation-patterns.mdの"console logs検索"指示が、hlx_logs削除後に詳細不足とされています。hlx_search_logとの使い分けや具体的な検索パターン例の明示が望ましい可能性があります。

#124381 Fix ConnectAsync sending stale ReceiveAsync buffer via ConnectEx

  • 作成者: @rzikm
  • 作成日時: 2026年02月13日 12:56:00(UTC)
  • マージ日時: 2026年02月13日 15:10:53(UTC)
  • ラベル: area-System.Net.Sockets

概要

Socket.ConnectAsync(EndPoint) が再利用するキャッシュされた _singleBufferReceiveEventArgs に、prior の ReceiveAsync 呼び出しから残された buffer/count が残っていたため、ConnectEx にそのバッファが send-on-connect データとして誤って渡されていました。特に DisconnectAsync(reuseSocket: true) 後の再接続時に、前の接続で受信したデータが新しい接続で送信されてしまう重大なバグです。修正では接続前に SetBuffer(default) を呼び出してバッファ状態をクリアします。

// 修正内容：ConnectAsync前にバッファをクリア
_singleBufferReceiveEventArgs.SetBuffer(default);
await ConnectAsync(endPoint);

変更内容

  • Socket.Tasks.cs: ConnectAsync(EndPoint, CancellationToken) で SetBuffer(default) を呼び出し、キャッシュされた SAEA のバッファ状態をクリア
  • DisconnectTest.cs: DisconnectAndReuse_SameHost_Succeeds テストを追加し、disconnect+reconnect 後にstaleデータが漏洩しないことを検証

パフォーマンスへの影響

SetBuffer(default) 呼び出しのオーバーヘッドは軽微（単純なフィールド代入）。接続操作自体のパフォーマンスに影響なし。

関連Issue

#124353

その他

セキュリティ・互換性への影響

  • 重大度: 高。TLS ハンドシェイク破損など、プロトコル層の重大なデータ破損を引き起こす可能性
  • 互換性: この修正は正しい動作への是正であり、バグ由来の誤った挙動に依存するコードは存在しないと考えられる
  • 検証方法: Wireshark キャプチャで stale TLS record が送信されないことを確認、およびC言語での検証により Windows kernel は正常に動作していることを確認済み

#124376 Disable TestStackOverflowLargeFrameMainThread for x64 on Unix

  • 作成者: @Copilot
  • 作成日時: 2026年02月13日 12:02:16(UTC)
  • マージ日時: 2026年02月13日 14:39:55(UTC)
  • ラベル: needs-area-label

概要

TestStackOverflowLargeFrameMainThreadテストをx64アーキテクチャ上のUnix/MacOSXプラットフォームで無効化するパッチです。スタックプローブが十分にスタックポインタから離れた位置でプローブを行う際に、ランタイムが基盤となるsigsegvをスタックオーバーフローとして認識できない問題（Issue #13519）に対応しています。テストはWindowsおよび他のアーキテクチャ（x86、ARM）では引き続き有効です。

変更内容

  • ファイル: src/tests/baseservices/exceptions/stackoverflow/stackoverflowtester.cs
    • TestStackOverflowLargeFrameMainThreadメソッドにArchitecture.X64を追加
    • テスト実行時のアーキテクチャチェックロジックを拡張し、ARM64、X64、RiscV64、LoongArch64をUnix/MacOSX上で早期終了させる

パフォーマンスへの影響

影響なし（テストスキップロジックの追加であり、実行時ランタイムのパフォーマンスには関連なし）

関連Issue

  • GitHub Issue #13519: スタックオーバーフロー検出に関する問題（複数アーキテクチャでの不安定な動作）

その他

  • テスト修正のため、ランタイム本体の変更ではなく、テストスイート内での対応
  • スタックプローブがスタックポインタを移動させず、特定のアーキテクチャとプラットフォームの組み合わせでsigsegvの正確な分類ができないという根本的な問題が存在することに注意

#124372 [native] Fix build of strrchr

  • 作成者: @ManickaP
  • 作成日時: 2026年02月13日 10:27:11(UTC)
  • マージ日時: 2026年02月13日 15:15:11(UTC)
  • ラベル: area-PAL-coreclr

概要

glibc 2.43のC23関連の変更により、strrchrがconst char*の引数に対してconst char*を返すようになったため、vendored libunwindのelfxx.cでのビルド失敗を修正しました。ローカル変数の型をchar*からconst char*に変更することで対応しています。

// 修正前
char *p = strrchr(file, '/');

// 修正後
const char *p = strrchr(file, '/');

変更内容

  • src/native/external/libunwind/src/elfxx.c: strrchrの戻り値を受け取る変数pの型をchar*からconst char*に変更（933行目付近）
  • src/native/external/libunwind-version.txt: libunwindバージョン情報の更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

この変更はglibc 2.43のC23準拠の型チェック強化に対応するためのコンパイラ互換性修正です。vendored libunwindはランタイム自体には影響しませんが、ネイティブコンパイラの要件を満たすために必要な修正となります。作成者も指摘している通り、他の解決方法（例えばキャストの追加など）がある可能性もあります。

#124367 Skip special formatting for stackoverflow exceptions in trivial cases

  • 作成者: @jkotas
  • 作成日時: 2026年02月13日 05:32:15(UTC)
  • マージ日時: 2026年02月13日 15:29:12(UTC)
  • ラベル: area-ExceptionHandling-coreclr

概要

StackOverflow例外の特殊フォーマット処理をスキップする条件を追加しました。出力がより冗長になる（行数が増える）場合は、特殊フォーマットを適用しないようにしています。これにより、例外メッセージの出力をより簡潔に保つことができます。

変更内容

  • src/coreclr/vm/eepolicy.cpp: StackOverflow例外のフォーマット処理に条件判定を追加（+6行）
    • 出力の行数を確認し、特殊フォーマットがより詳細な出力を生じる場合はスキップするロジックを実装

パフォーマンスへの影響

影響なし。この変更は例外フォーマット時の出力判定ロジック追加であり、ランタイムのパフォーマンスに直接的な影響はありません。

関連Issue

なし

その他

  • 変更はeepolicy.cppの例外ポリシー管理部分に限定されており、StackOverflow例外処理の特殊ケース対応です
  • trivialなケースでの冗長な出力を削減する品質改善となります

#124360 JIT: don't set liveness on unreachable blocks

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年02月12日 23:13:47(UTC)
  • マージ日時: 2026年02月13日 14:41:55(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT のライブネス分析で、到達不可能なスロー ヘルパー ブロックに対するレガシーコードを削除しています。スロー ヘルパー ブロックが lower/liveness フェーズの後に作成されるようになったため、ライブネス分析時には到達不可能なスロー ヘルパー ブロックは存在しないという新しい不変式を強制します。

変更内容

  • src/coreclr/jit/liveness.cpp:
    • DoLiveVarAnalysis() で到達不可能なスロー ヘルパー ブロックのライブネスを設定していたループを削除
    • ライブネス実行時に fgRngChkThrowAdded が false であることを確認するアサーションを追加
    • DEBUG ビルド時に、到達不可能なブロックに BBF_THROW_HELPER フラグが設定されていないことを検証

パフォーマンスへの影響

影響なし。不要なループを削除することで、ライブネス分析の処理を若干簡略化しますが、実質的なパフォーマンス改善は期待できません。

関連Issue

なし

その他

この変更は、スロー ヘルパー ブロックの生成タイミングを StackLevelSetter フェーズに移動したという前提条件に基づいています。これにより、ライブネス分析コードが単純化され、コンパイラの設計がより明確になります。

#124359 ci-analysis skill: MSBuild guidance, merge commit shortcut, MCP alternatives

  • 作成者: @lewing
  • 作成日時: 2026年02月12日 22:08:53(UTC)
  • マージ日時: 2026年02月13日 00:25:02(UTC)
  • ラベル: area-skills

概要

dotnet/runtimeのCI分析スキルの改善PR。MSBuildのクロスプラットフォーム警告、マージコミットからのターゲットブランチHEAD抽出ショートカット、およびMCP（Model Context Protocol）ツール代替案の追加により、CI障害調査ワークフローのドキュメントを強化します。構造的な変更はなく、インラインでの最小限の追加です。

変更内容

ファイル変更:

  1. build-progression-analysis.md (+19/-1)

    • MSBuildクロスプラットフォーム警告：Windows(;)とLinux(:)のパスセパレータ差異による誤検出を回避
    • Step 2bショートカット追加：gh api repos/{owner}/{repo}/git/commits/{sourceVersion} --jq '.parents[0].sha'でマージコミットのターゲットブランチHEADを簡潔に抽出
    • get_commit MCPツール代替案を記載

  2. SKILL.md (+2/-2)

    • PR分析モードでpull_request_read MCPツールをgh pr checksの代替として追加
    • MCPツール選択時の構造化アクセス利点を明記

  3. azure-cli.md (+2/-0)

    • MCP優先アプローチを示すプリアンブルを追加
    • AzDO MCP ツールがほとんどのクエリに対応、Azure CLIはフォールバックの構成を記載

  4. azdo-helix-reference.md (+1/-1)

    • search_issues MCPツール利用推奨を括弧内に追記

パフォーマンスへの影響

影響なし。ドキュメント強化のみで、ランタイムコードやコンパイル動作への変更なし。

関連Issue

#124240（フォローアップPR）

その他

  • マージコミットショートカット使用時の注意：最新ビルドのみ対応。GitHubはプッシュごとにマージ参照を再計算するため、古いビルドではターゲットSHA抽出失敗の可能性あり
  • ドキュメント変更のため、言語的解釈や具体的な技術課題の詳細は確認資料の参照推奨

#124358 Consolidate CoreCLR pipeline platform matrices and migrate NativeAOT to ARM64 macOS

  • 作成者: @Copilot
  • 作成日時: 2026年02月12日 21:47:06(UTC)
  • マージ日時: 2026年02月13日 20:02:19(UTC)
  • ラベル: area-NativeAOT-coreclr

概要

CoreCLRパイプライン設定の最適化を実施。NativeAOT Release ビルドを osx_x64 から osx_arm64 に移行し、ARM64 macOS インフラとの整合性を確保。また、CoreCLR テスト実行の重複したプラットフォームマトリックス定義を統合し、設定の冗長性を削減しました。

変更内容

eng/pipelines/runtime.yml

  • Line 649: NativeAOT Release ビルドのプラットフォーム設定を osx_x64 → osx_arm64 に変更
  • Lines 1617-1658: buildConfig: checked の重複した run-test-job.yml エントリを統合。既存のマルチプラットフォームリストに osx_x64 を追加し、20行の重複定義を排除

両変更により、helixQueueGroup、条件、アーティファクト名などの他のパラメータはすべて保持されます。

パフォーマンスへの影響

影響なし。本変更はCI/CDパイプライン設定の最適化であり、実行時のパフォーマンスには直接的な影響はありません。ただし、ARM64 macOS インフラへの移行により、CI ビルド時間が短縮される可能性があります。

関連Issue

なし

その他

  • 本変更は既存の NativeAOT_Libraries 設定と整合性を取る目的で実施（既に ARM64 macOS を使用）
  • パイプライン設定の YAML 妥当性は保持される
  • 設定の冗長性を削減し、メンテナンスコストを低減

#124348 SPMI: Run NuGet authentication in target container

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月12日 17:18:34(UTC)
  • マージ日時: 2026年02月13日 09:48:57(UTC)
  • ラベル: needs-area-label

概要

SuperPMI収集パイプラインにおいて、linux-arm/linux-arm64ビルド時にx64コンテナ内でSPMIコンポーネントを構築する際、NuGet認証がコンテナ内で正しく実行されるよう修正されました。これにより、x64ホストマシン上でのビルド失敗が解決されます。

変更内容

変更ファイル: eng/pipelines/coreclr/templates/superpmi-collect-pipeline.yml

  • linux-armジョブ向けに、x64 SuperPMIビルドステップの前にNuGetAuthenticate@1タスクを追加（linux_x64コンテナをターゲット）
  • linux-arm64ジョブ向けに、同様にNuGetAuthenticate@1タスクを追加（linux_x64コンテナをターゲット）
  • Checked および Release ビルド設定の両方に適用

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

本変更はビルドインフラストラクチャの修正に関するもので、実行時の.NETランタイム機能には直接影響しません。linux-arm/linux-arm64ビルドでx64ホストコンテナを使用する際の認証エラーを解決するパイプライン構成上の改善です。

#124343 SPMI: Run superpmi-diffs on windows-x64

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月12日 13:23:47(UTC)
  • マージ日時: 2026年02月13日 12:03:30(UTC)
  • ラベル: area-CodeGen-coreclr

概要

SPMI（SuperPMI）の差分ビルド実行環境をosx-arm64からwindows-x64に変更するパイプライン修正です。osx-arm64のAzDOプール過負荷によるビルド開始遅延（数時間待機）を回避し、ビルドおよびHelixジョブ投入の効率化を実現します。

変更内容

  • eng/pipelines/coreclr/superpmi-diffs.yml: パイプライン設定ファイルを修正
    • osx-arm64でのSPMI差分実行設定をwindows-x64に切り替え
    • 変更規模：2行追加、11行削除（総13行）

パフォーマンスへの影響

ビルドキューイング時間の大幅改善

  • 従来のosx-arm64実行時：数時間の待機時間が発生
  • windows-x64への変更：AzDOプール負荷軽減により待機時間を短縮
  • 結果として、全体的なCI/CDパイプラインのスループット向上が期待される

関連Issue

なし

その他

本変更はインフラストラクチャレベルの最適化であり、機能追加やAPIの変更を含みません。SPMI差分実行ロジック自体への影響はなく、実行基盤の効率化に限定されます。

#124330 Fix Optimization Profile writing

  • 作成者: @FixBo
  • 作成日時: 2026年02月12日 09:50:06(UTC)
  • マージ日時: 2026年02月13日 20:59:26(UTC)
  • ラベル: community-contribution needs-area-label

概要

.NET 11 Preview 1において、モジュール名の長さがDWORD境界に整列している場合、Optimization Profileの保存に失敗するバグを修正しました。このバグはPR #116203で導入された回帰です。

変更内容

  • src/coreclr/vm/multicorejit.cpp (+8/-6)
    • Optimization Profile書き込み時のバッファ配置ロジックを修正
    • モジュール名長がDWORD整列時の処理を改善

パフォーマンスへの影響

影響なし（バグ修正のみ）

関連Issue

PR #116203による回帰修正

その他

  • マルチコアJIT最適化プロファイルの永続化処理に関わる修正
  • VMレイヤー（coreclr/vm）での低レベルバッファ処理の問題
  • .NET 11 Preview 1での重要な修正

#124309 [cDAC] Magic enums - add comments to native code where they are defined so that we know to version the cDAC when they change. Also prune unused or suboptimal enums from cDAC.

  • 作成者: @rcj1
  • 作成日時: 2026年02月12日 01:46:38(UTC)
  • マージ日時: 2026年02月13日 13:21:18(UTC)
  • ラベル: area-VM-coreclr

概要

このPRはcDAC（Common Data Access Contract）関連の列挙型（enum）に対してバージョン管理を強化するものです。ネイティブコード内で定義されているマジックナンバーに対して、変更時にcDACをバージョニングする必要があることを示すコメントを追加します。また、cDACから未使用または最適でない列挙型を削除し、メンテナンス性を向上させます。

変更内容

ヘッダーファイルのコメント追加:

  • src/coreclr/inc/*.h - 複数のネイティブヘッダーファイルに列挙型のバージョニングに関するコメント追加
  • src/coreclr/vm/method.hpp - 31行追加/24行削除で主要な変更
  • src/coreclr/vm/methodtable.h - 18行追加/14行削除
  • src/coreclr/vm/assembly.hpp - 列挙型定義へのコメント追加

cDAC定義の削除/最適化:

  • src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/ - 複数の列挙型定義を削除
  • src/native/managed/cdac/tests/ - テストコードから未使用の列挙型参照を削除

ドキュメント更新:

  • docs/design/datacontracts/*.md - cDAC列挙型の設計仕様を更新

パフォーマンスへの影響

影響なし。これはメタデータ管理とバージョン管理に関する変更であり、ランタイムパフォーマンスへの直接的な影響はありません。

関連Issue

なし

その他

  • 列挙型定義の変更歴を分析した結果、新しい値の追加は一般的ですが、既存の数値を変更することは稀であることが判明しています
  • すでにデバッガ関連のコードでは同様のバージョン管理アプローチが採用されており、その慣例に従ったものです
  • このアプローチにより、ネイティブコードとマネージドcDACコード間の同期ズレを防止し、バージョン管理を明示的にすることで、保守性が向上します

#124283 Avoid resolving direct awaits to thunks

  • 作成者: @jakobbotsch
  • 作成日時: 2026年02月11日 16:30:35(UTC)
  • マージ日時: 2026年02月13日 16:56:58(UTC)
  • ラベル: area-CodeGen-coreclr

概要

直接的なawaitをthunk（仲介関数）に解決することを回避する最適化です。不要なJIT compilation と thunk経由の呼び出しによるオーバーヘッドを削減し、JITがコードをより効率的に最適化できるようにします。

変更内容

  • corinfo.h: 新しいflag定義を追加（+1行）
  • compiler.cpp/compiler.h: Tierbot interpreter のawait処理ロジックを修正（-8行の削減）
  • importer.cpp: JIT importerの直接await処理を改善（+8行）
  • CorInfoImpl.cs: managed JIT interface層で新しいflagハンドリングを実装（+36行）
  • CorInfoTypes.cs: 対応する型定義を追加（+1行）
  • CorInfoImpl.RyuJit.cs: RyuJIT向けの実装調整（-7行の削減）
  • jitinterface.cpp: VM層でのawait解決ロジックを最適化（+26行）

パフォーマンスへの影響

改善点:

  • 不要なthunk経由のJIT compilation を削減し、overall jitting コストを低減
  • thunkの透過性が低下していた問題を解決し、JITの最適化がより効果的に動作可能
  • 特にawait-heavy なコードで、call stack depth の削減とインライン化機会の増加を実現

関連Issue

#115771

その他

本変更は interpreter, importer, managed JIT interface, VM層の複数レイヤーにまたがる実装調整が必要となっています。thunk回避による最適化であり、破壊的なAPI変更ではありません。

#124264 Add ProcessExitStatus class to System.Diagnostics.Process

  • 作成者: @Copilot
  • 作成日時: 2026年02月11日 12:06:17(UTC)
  • マージ日時: 2026年02月13日 11:24:22(UTC)
  • ラベル: area-System.Diagnostics.Process

概要

System.Diagnostics.Process に新しい ProcessExitStatus クラスを追加します。このクラスは、プロセスの終了状態（終了コード、オプションの POSIX シグナル、キャンセル/タイムアウト情報）を表現します。sealed クラスとして実装され、XML ドキュメントと包括的なユニットテストが含まれています。

// 使用例
var exitStatus = new ProcessExitStatus(exitCode: 0, signal: null, canceled: false);
int code = exitStatus.ExitCode;
bool wasCanceled = exitStatus.Canceled;

変更内容

  • ProcessExitStatus.cs: 新しい public sealed クラスの実装（55行）。ExitCode、Signal、Canceled プロパティを持つコンストラクタと XML ドキュメンテーション
  • System.Diagnostics.Process.cs（ref）: public API サーフェスの参照宣言（7行）
  • ProcessExitStatusTests.cs: コンストラクタと複数のパラメータ組み合わせに対するプロパティ動作の検証テスト（61行）
  • System.Diagnostics.Process.csproj: ProductCompilation リストに ProcessExitStatus.cs を追加
  • System.Diagnostics.Process.Tests.csproj: テスト用 csproj にテストファイルを追加

パフォーマンスへの影響

影響なし

関連Issue

#123380（API レビュー）

その他

  • API レビューの指摘に基づき、IEquatable と equality メンバーは削除
  • struct から sealed class へ変更（API 仕様に従う）
  • Signal プロパティは Unix のみの概念であることをドキュメントで明記
  • コンストラクタパラメータを cancelled から canceled へ統一（米国英語綴り）

#124248 Update IServiceScopeFactory.CreateScope docs to clarify transient service disposal

  • 作成者: @Copilot
  • 作成日時: 2026年02月10日 22:16:34(UTC)
  • マージ日時: 2026年02月13日 14:56:31(UTC)
  • ラベル: area-Extensions-DependencyInjection

概要

このPRは、依存性注入(DI)コンテナのスコープ破棄時の動作に関するAPI ドキュメントを更新するものです。従来のドキュメントでは「スコープ化されたサービス」のみが破棄されると記載されていましたが、実際の動作では一時的なサービス(transient services)もスコープによって追跡・破棄されます。このドキュメント更新により、実装の動作とドキュメントの整合性が取れます。

変更内容

  • IServiceScopeFactory.cs: CreateScope メソッドの<returns>セクションを更新。スコープ破棄時に「スコープ化されたサービス」に加えて「一時的なサービス」も破棄されることを明記
  • IServiceScope.cs: <remarks>セクションを同様に更新し、スコープ破棄時の動作を明確化

更新後のドキュメント文言：

Once this is disposed, any scoped services and any transient services that have been resolved from the ServiceProvider will be disposed.

パフォーマンスへの影響

影響なし

このPRは純粋なドキュメント更新であり、実装コードの変更を含まないため、ランタイムパフォーマンスやメモリ使用量への影響はありません。

関連Issue

  • #104472（元のissue）
  • StackOverflow質問: disposable transient servicesに関する混乱

その他

この更新は、Microsoft Learnの依存性注入ガイドラインにおける「スコープから解決された一時的なサービスはスコープ破棄時に破棄される」という説明と一致させるためのものです。複雑なインターフェース型(IDisposable/IAsyncDisposable)の明示を避け、シンプルかつアクセスしやすい表現で混乱を解消しています。

#124205 [Wasm RyuJIT] Start generating relocations for call_indirect

  • 作成者: @kg
  • 作成日時: 2026年02月10日 00:09:20(UTC)
  • マージ日時: 2026年02月13日 05:09:24(UTC)
  • ラベル: arch-wasm area-CodeGen-coreclr

概要

WebAssemblyの間接呼び出し（call_indirect）に対するリロケーション生成サポートを追加するPull Requestです。Wasm RyuJIT コンパイラが、リンク仕様に基づいたリロケーション型を使用して、呼び出し対象アドレスを動的に解決できるようになります。これにより、Wasmバイナリのリンク時最適化とランタイム動的リンクが改善されます。

変更内容

  • corinfo.h: CorInfoRelocおよびRelocType列挙体に新しいWasmリロケーション型を追加（+11）
  • emitfmtswasm.h: IF_CALLおよびIF_MEMADDRなど、リロケーション済み定数ペイロード用の新しい命令フォーマットを定義（+3）
  • emitwasm.cpp: リロケーション処理をemitIns_Callに統合し、リロケーションメタデータ生成ロジックを追加（+74）
  • instrswasm.h: Wasmの疑似命令フォーマット定義をリロケーション対応に更新（+10）
  • Relocation.cs: Wasmリロケーション型の定義と処理ロジックを追加（+44）
  • WasmTypeNode.cs: WasmTypeNodeをISymbolNodeインターフェース実装により、リロケーション対象として利用可能に変更（+20）
  • DwarfHelper.cs、CorInfoImpl.cs、CorInfoTypes.cs: メタデータ処理とリロケーション情報管理の関連コード追加

パフォーマンスへの影響

直接的なパフォーマンス影響は軽微と考えられます。リロケーション情報生成は主にコンパイル時処理であり、ランタイム実行には大きな負荷増加をもたらしません。ただし、コンパイル時のメタデータ処理量がわずかに増加します。

関連Issue

なし

その他

  • 複数のレビュアー（jakobbotsch、SingleAccretion、AndyAyersMS等）による綿密なレビューがされており、設計の堅牢性が確保されている
  • Wasm linking specに準拠した実装であり、将来のWasm標準化動向への対応基盤となります

#124152 Increase timeout on OneFuzz deployment pipeline

  • 作成者: @MihaZupan
  • 作成日時: 2026年02月08日 21:49:23(UTC)
  • マージ日時: 2026年02月13日 16:01:05(UTC)
  • ラベル: area-Meta

概要

Azure Pipelines のライブラリ Fuzzing "deploy to OneFuzz" パイプラインのジョブタイムアウト値を増加させました。夜間デプロイメント実行が現在のタイムアウト値 (240分) に頻繁に近づいており、または超過している問題を解決するため、windows ジョブのタイムアウトを 240 分から 600 分に延長します。これにより、CI における信頼性の低いタイムアウトエラーを削減します。

変更内容

  • eng/pipelines/libraries/fuzzing/deploy-to-onefuzz.yml: windows ジョブの timeoutInMinutes パラメータを 240 から 600 に変更 (+1/-1)

パフォーマンスへの影響

直接的なパフォーマンス改善ではなく、CI/CD パイプラインの信頼性向上です。タイムアウト値の増加により、OneFuzz デプロイメント処理が安定して完了するまでの時間的余裕が増加します。懸念点として、パイプラインの完了時間が最大で 6 時間まで延長される可能性があり、CI リソースの効率性に影響する可能性があります。

関連Issue

なし

その他

この変更は Azure Pipelines の設定ファイルに限定されており、ランタイムコードやライブラリに影響しません。OneFuzz は Microsoft の継続的なファジング服務であり、セキュリティテストの一環として夜間に実行されるため、ビルド時間の増加は許容可能と考えられます。

#123962 [browser] native - no process, no signals, no threads, no blocking

  • 作成者: @pavelsavara
  • 作成日時: 2026年02月03日 20:38:00(UTC)
  • マージ日時: 2026年02月13日 15:42:51(UTC)
  • ラベル: arch-wasm area-PAL-coreclr os-browser

概要

WebAssembly (WASM) ブラウザ環境での.NET ランタイム実行を実現するため、プロセス、シグナル、スレッド、ブロッキング操作に対応しないネイティブレイヤーの実装を追加しています。PAL（Platform Abstraction Layer）層でWASM固有のスタブ実装を提供し、ブラウザ環境の制約に適応させる変更です。

変更内容

  • PAL層の条件付きコンパイル: src/coreclr/pal/src/ 配下の複数ファイル（debug.cpp、thread.cpp、threadsusp.cpp、wait.cpp等）にWASM向けのスタブ実装を追加
  • ネイティブライブラリ更新: src/native/libs/System.Native/ のWASM固有実装（pal_console_wasm.c、pal_dynamicload_wasm.c、pal_signal_wasm.c等）を拡張
  • イベントパイプ対応: WebSocket経由のIPC機能をWASM環境向けに実装
  • ビルドシステム: eng/native.wasm.targets でWASM向けコンパイルターゲットを新規追加
  • 型定義更新: src/mono/browser/runtime/dotnet.d.ts でTypeScript定義を更新

パフォーマンスへの影響

直接的なパフォーマンス低下は想定されません。WASM環境ではプロセス生成やシグナルハンドリングがサポートされないため、スタブ実装により不要な処理を削除し、ブラウザ環境に最適化された動作を実現します。ただしスレッド操作がブロッキング不可となるため、非同期I/Oパターンへの依存が増加します。

関連Issue

#122506

その他

  • 本変更はWASM/ブラウザ環境専用の最小限実装です
  • プロセス、シグナル、従来型スレッド、ブロッキングI/Oはブラウザセキュリティモデルの制約により実装されません
  • PAL層の条件分岐により、既存プラットフォームへの影響を最小化しています

#123932 Fix parsing inconsistencies between Uri ctors and TryCreate factories

  • 作成者: @MihaZupan
  • 作成日時: 2026年02月03日 05:04:49(UTC)
  • マージ日時: 2026年02月13日 21:26:36(UTC)
  • ラベル: area-System.Net breaking-change needs-breaking-change-doc-created

概要

UriコンストラクタとTryCreateファクトリメソッド間の解析矛盾を修正します。相対URIへのフォールバック時にIRI正規化がスキップされるなど、2つのコードパス間で動作が異なっていました。修正により両者の動作が統一されます。

// 修正前: 異なる動作
var uri1 = new Uri("p%41th", UriKind.Relative);
Uri.TryCreate("p%41th", UriKind.Relative, out Uri uri2);
Console.WriteLine(uri1); // pAth (IRI正規化適用)
Console.WriteLine(uri2); // p%41th (IRI正規化なし)

// 修正後: 同じ動作
Console.WriteLine(uri1); // pAth
Console.WriteLine(uri2); // pAth

変更内容

  • src/System/Uri.cs: コンストラクタロジックの簡潔化（-10行）
  • src/System/UriExt.cs: TryCreate実装の共通ロジック統一（+44/-92行）
    • コード重複を排除し、同一の解析ロジックを使用
    • 相対URIへのフォールバック時のIRI正規化を統一
  • src/UriTests.cs: 統一動作の検証テスト追加（+32行）

パフォーマンスへの影響

影響なし。コード重複削除による保守性向上が主目的です。

関連Issue

  • PR #122001
  • PR #122002

その他

破壊的変更: 相対URIのTryCreateで新たにIRI正規化が適用されるため、直接クエリした場合の動作が変わります。ただし、相対URIをベースURIと組み合わせる通常のユースケースでは実質的な影響はありません。ドキュメント更新が必要です。

#123735 [CoreCLR][Signal] Bump shutdown notif and crashdump before prev handler

  • 作成者: @mdh1418
  • 作成日時: 2026年01月28日 23:12:22(UTC)
  • マージ日時: 2026年02月13日 17:31:03(UTC)
  • ラベル: area-ExceptionHandling-coreclr

概要

CoreCLR のシグナルハンドラ処理の順序を変更し、以前登録されたシグナルハンドラを呼び出す前に PROCNotifyProcessShutdown と PROCCreateCrashDumpIfEnabled を実行するようにしました。これにより、Android などのプラットフォームで同期フォルト（SIGSEGV など）発生時に、以前のハンドラが戻らない場合でも、マネージドコンテキストのダンプ生成とシャットダウン通知が確実に実行されます。

// シグナル処理の実行順序が変わります
// 変更前: invoke_previous_action() → PROCNotifyProcessShutdown() → PROCCreateCrashDumpIfEnabled()
// 変更後: PROCNotifyProcessShutdown() → PROCCreateCrashDumpIfEnabled() → invoke_previous_action()

変更内容

  • src/coreclr/pal/src/exception/signal.cpp: シグナルハンドラ内での処理順序を変更。以前のハンドラ呼び出しを最後に移動
  • src/coreclr/pal/inc/pal.h: 新しい設定フラグ関連のAPI宣言を追加
  • src/coreclr/inc/clrconfigvalues.h: 新しい設定値定義を追加（Android 対応用）
  • src/coreclr/dlls/mscoree/exports.cpp: 設定エクスポート関連の変更
  • src/tasks/AndroidAppBuilder/Templates/monodroid-coreclr.c: Android ビルドテンプレート更新

パフォーマンスへの影響

影響なし。シグナルハンドラ実行時の処理順序変更のみであり、オーバーヘッド増加はありません。

関連Issue

なし

その他

重要な背景情報：

  • Android CoreCLR では、デフォルトでシステムのシグナルハンドラが登録されており、同期フォルト発生時に戻らないため、変更前はダンプ生成が実行されていませんでした
  • MacOS/Linux では既に意図通り動作していました
  • Mono では同様のシグナルチェーン機能で、スタック追跡後にハンドラをチェーンしており、このPRはその挙動に合わせています
  • 历史調査の結果、処理順序の変更を妨げる理由が見当たらないため、この変更を採用しています

#123601 Added Adler32 to System.IO.Hashing.

  • 作成者: @AraHaan
  • 作成日時: 2026年01月25日 18:35:08(UTC)
  • マージ日時: 2026年02月13日 03:46:43(UTC)
  • ラベル: community-contribution area-System.IO.Hashing

概要

System.IO.Hashing ライブラリに Adler32 ハッシュアルゴリズムの実装を追加しました。Adler32 は RFC 1950 で定義された軽量なチェックサムアルゴリズムで、ZIP ファイル形式など複数の標準で使用されています。

変更内容

  • Adler32.cs (+210 行): Adler32 ハッシュアルゴリズムの実装を追加
  • ref/System.IO.Hashing.cs (+17 行): 公開 API の参照定義を追加
  • Adler32Tests.cs (+172 行): 包括的なユニットテストを追加
  • プロジェクトファイル: テストおよびメインプロジェクトの設定を更新

パフォーマンスへの影響

既存の System.IO.Hashing ライブラリへの影響なし。Adler32 は単純なアルゴリズムで、2つの 16 ビット値を保持し、ストリーミング処理をサポートしているため、メモリ効率が良好です。

関連Issue

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

その他

  • RFC 1950 に準拠した実装
  • ストリーミング API をサポート（他の System.IO.Hashing アルゴリズムと一貫性がある）
  • ZIP や zlib などの標準フォーマットとの互換性を確保
目次