注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
- #126742 Revert "Workaround for a bug in latest MSVC"
- #126737 Early init for FrameworkEventSource
- #126736 Arm64 jitstress outerloop
- #126732 Simple RuntimeTypeSystem DacDbi APIs
- #126731 Fix CLR->COM RCW ownership tracking on the slow path
- #126729 Replace SHash of call counting managers with linked list.
- #126728 Fix DAC GetNativeCodeInfo API to use async variant for thunk MethodDescs
- #126715 Re-enable FEATURE_CORPROFILER for tvOS to match iOS/MacCatalyst
- #126713 [cDAC] Add typed field extension methods for Data classes
- #126680 Enable runtime-async unconditionally in System.Private.CoreLib (CoreCLR and NativeAOT)
- #126676 Add
WASM_MEMORY_ADDR_REL_LEBRelocation Type - #126663 [Wasm RyuJit] fix funclet prolog and epilog codegen
- #126638 Agentics: Add Extensions & Compression review agent and instructions
- #126632 Add ProcessStartInfo.StartDetached to start processes detached from parent session/console
- #126631 [Apple mobile] Skip unsupported tests on Apple mobile platforms
- #126629 Add NonInheritedFileHandle_IsNotAvailableInChildProcess test to ProcessHandlesTests
- #126582 Convert throw and thread helpers to UCO
- #126571 Fix COM reentrancy contract violations and re-enable the ExtensionPoints test
- #126512 Merge hotreload-utils source into runtime repo
- #126511 Replace contract factories with registration-based ContractRegistry
- #126158 fix
ChainedRateLimitertreatingIdleDurationand chainedReplenishmentRateLimitersincorrectly - #126157 [wasm][coreclr] Batch CoreCLR library test suites on Helix
- #125853 Update baseline build instructions to use working branch instead of main
- #125819 Guard stackwalking in IXClrDataStackWalk codepaths to account for underlying max size of context
- #125630 Simplify TrimmerSingleWarn intermediate assembly update using MSBuild item Update
- #125613 [release/10.0] Fix missing call to write barrier in static constructors of ref structs
- #124851 Add ActivityTraceFlags.RandomTraceId flag
- #124698 Fix SYSLIB1045 code fixer generating duplicate MyRegex names across partial class declarations
- #118057 Delete
DEFAULT_STACK_SIZE
#126742 Revert "Workaround for a bug in latest MSVC"
- 作成者: @jkotas
- 作成日時: 2026年04月10日 04:33:07(UTC)
- マージ日時: 2026年04月10日 17:24:56(UTC)
- ラベル: area-Diagnostics-coreclr
概要
MSVC コンパイラの既知バグ対応を取り除くリバート PR です。CoreCLR の DAC/DBI 実装において、GetILCodeAndSig 関数周辺に適用されていた最適化無効化プラグマを削除し、元の最適化動作を復元します。
変更内容
src/coreclr/debug/daccess/dacdbiimpl.cpp:_MSC_VER条件付きの#pragma optimize("", off/on)ディレクティブ(9行)を削除
パフォーマンスへの影響
最適化が復元されるため、DAC/DBI コンポーネント(デバッガ関連機能)の実行速度向上が期待されます。ただし、具体的なベンチマーク数値は提供されていません。
関連Issue
#120282(このリバートの対象となった過去の PR)
その他
なし
#126737 Early init for FrameworkEventSource
- 作成者: @noahfalk
- 作成日時: 2026年04月10日 00:48:14(UTC)
- マージ日時: 2026年04月10日 06:15:27(UTC)
- ラベル: area-System.Diagnostics.Tracing
概要
ThreadPool初期化中にFrameworkEventSourceが遅延初期化される際、EventListenerロックを獲得してデッドロックが発生する問題を修正します。FrameworkEventSourceをランタイムの起動パスの早期段階で先制的に初期化することで、ロック競合を回避します。
変更内容
- src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs
EventSource.InitializeDefaultEventSources()内でFrameworkEventSourceを積極的に初期化- FEATURE_PERFTRACINGプリプロセッサシンボル下での変更
- デッドロック シナリオに関する説明コメントを追加
パフォーマンスへの影響
影響なし。スタートアップパスの早期段階での初期化により、将来的なオンデマンド生成時のロック競合を回避するため、むしろ全体的なスタートアップの安定性が向上する可能性があります。
関連Issue
その他
この修正は低リスクのスポット修正アプローチです。EventSource全体に関わるロック デッドロック問題については、EventSourceコールバックを非同期化するなどの抜本的な解決策も考慮されていますが、広範な互換性リスクがあるため、より安全な段階的な修正が採用されています。
#126736 Arm64 jitstress outerloop
- 作成者: @dhartglassMSFT
- 作成日時: 2026年04月10日 00:24:50(UTC)
- マージ日時: 2026年04月10日 18:42:41(UTC)
- ラベル: area-CodeGen-coreclr
概要
ARM64 JIT HWIntrinsic コード生成において、マルチ命令展開を含むRMWスタイルのSVE組み込み関数で、非定数即値ジャンプテーブル生成時の命令数計算を修正します。HWIntrinsicImmOpHelperのケースサイズ計算をエミッタの動作(targetReg != op1Reg時の追加移動命令)と一致させることで、jitstressテスト(特にarm64)での失敗を解決します。
変更内容
- src/coreclr/jit/hwintrinsiccodegenarm64.cpp (+4/-2)
- SVE saturating inc/dec-by-element-count コード生成時に、エミッタが追加の移動命令を挿入する可能性がある場合、明示的な
numInstrsをHWIntrinsicImmOpHelperに渡す NI_Sve_ExtractVectorコード生成時に、RMW処理の動作(targetReg != op1Reg時に移動が必要)に合わせて、明示的なnumInstrsをHWIntrinsicImmOpHelperに渡す
- SVE saturating inc/dec-by-element-count コード生成時に、エミッタが追加の移動命令を挿入する可能性がある場合、明示的な
パフォーマンスへの影響
影響なし(バグ修正により正確なコード生成が実現されるため)
関連Issue
なし
その他
- 元の修正(コミット95f94b62378e2ac3e74b42bebfb91327a4d8708d)が一部のケースを見落としていたため、同様の修正を他の箇所に適用
- jitstress arm64テストがグリーン化したことが確認済み
- コード変更は@ylpoonlgから提供
#126732 Simple RuntimeTypeSystem DacDbi APIs
- 作成者: @rcj1
- 作成日時: 2026年04月09日 23:08:57(UTC)
- マージ日時: 2026年04月10日 23:28:27(UTC)
- ラベル: area-Diagnostics-coreclr
概要
cDAC(Compact Data Access Components)の RuntimeTypeSystem コントラクトを拡張し、3つの DacDbi API(HasTypeParams、GetTypeHandle、GetThreadStaticAddress)を実装しました。これらの API は診断ツール(デバッガ、SOS)がジェネリック型情報とスレッドスタティックフィールドのアドレスを取得するために使用されます。
変更内容
- DacDbiImpl.cs:
HasTypeParams、GetTypeHandle、GetThreadStaticAddressの3つの DacDbi API を cDAC コントラクトベースで実装。DEBUG ビルドでは従来の DAC との検証チェックを含む - RuntimeTypeSystem_1.cs:
ContainsGenericVariablesプロパティとGetFieldDescThreadStaticAddressメソッドを追加 - MethodTableFlags_1.cs: MethodTable フラグに
ContainsGenericVariablesビットサポートを追加 - EcmaMetadataUtils.cs: メタデータトークンヘルパーを公開化し、複数の実装で共有可能に
- CorDbHResults.cs: "class not loaded" の HRESULT 定数を追加
- RuntimeTypeSystem.md: 新しい API と スタティック/スレッドスタティックアドレスヘルパーのドキュメント追加
- テストファイル: DacDbi と RuntimeTypeSystem の機能テストケースを追加
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
- 変更は内部実装(cDAC 契約とレガシー DAC の実装)に限定され、公開 API への影響なし
- Copilot レビューで、ダンプ/ミニダンプシナリオにおいて
IEcmaMetadata.GetMetadata()が null を返した場合の処理を明示的に実装すべき点が指摘されています(現在は null 検証が不十分)
#126731 Fix CLR->COM RCW ownership tracking on the slow path
- 作成者: @AaronRobinsonMSFT
- 作成日時: 2026年04月09日 20:46:33(UTC)
- マージ日時: 2026年04月10日 17:54:39(UTC)
- ラベル: area-VM-coreclr
概要
PR #114609で導入されたリグレッションを修正します。ネイティブスレッド上で System.StubHelpers.GetCOMIPFromRCW() がスローパスにフォールバックする際、OLE TLSの初期化後のRCWキャッシュヒットに対して不正に Release が呼ばれていた問題を解決します。スローヘルパーに pfNeedsRelease フラグを返却させることで、RCWキャッシュヒット(借用ポインタ)と新規取得ポインタを区別し、所有権に基づいた適切なクリーンアップを行うようにします。
変更内容
- src/coreclr/vm/stubhelpers.h: QCallスローパスのシグネチャを更新し、所有権フラグを明示的に返却
- src/coreclr/vm/stubhelpers.cpp: 所有権追跡を実装。RCWキャッシュヒット時は借用ポインタ(リリース不要)、新規取得時のみ
pfNeedsRelease=trueを設定 - src/coreclr/System.Private.CoreLib/src/System/StubHelpers.cs: マネージドコードでスローパスに
pfNeedsRelease判定を委譲 - テストコード: COM相互運用のライフタイム管理に関する包括的なテストを追加・拡張
パフォーマンスへの影響
影響なし
関連Issue
#126619(このPRで修正対象) #114609(リグレッション発生のきっかけとなったPR)
その他
- 修正は内部実装の変更(CLR→COM相互運用のスタブクリーンアップパス)
- COM RCW(ランタイム呼び出し可能ラッパー)のメモリリーク防止に関連
- ローカル再現ケースに対して検証済み
#126729 Replace SHash of call counting managers with linked list.
- 作成者: @rcj1
- 作成日時: 2026年04月09日 19:10:12(UTC)
- マージ日時: 2026年04月10日 17:07:52(UTC)
- ラベル: area-VM-coreclr
概要
コール カウンティング マネージャーのデータ構造を SHash からリンク リストに変更します。ハッシュの機能を使用せず、要素の追加・削除・全体反復のみを行うため、より適切なデータ構造への最適化です。
変更内容
- src/coreclr/vm/callcounting.h:
SHashベースの実装をリンク リストに置き換え(28行削除、4行追加) - src/coreclr/vm/callcounting.cpp: マネージャー実装の更新、ハッシュ関連ロジックの削除(45行削除、7行追加)
- src/coreclr/vm/ceemain.cpp: 呼び出し元の軽微な調整(1行変更)
パフォーマンスへの影響
メモリ効率の向上が期待されます。ハッシュテーブルのオーバーヘッドが削除され、シンプルなリンク リスト構造に変更されることで、メモリ消費量が削減されます。ただし、ランダムアクセスが必要な場合はパフォーマンスが低下する可能性がありますが、提供情報では反復処理のみとのことです。
関連Issue
その他
なし
#126728 Fix DAC GetNativeCodeInfo API to use async variant for thunk MethodDescs
- 作成者: @tommcdon
- 作成日時: 2026年04月09日 18:58:39(UTC)
- マージ日時: 2026年04月10日 15:11:27(UTC)
- ラベル: area-Diagnostics-coreclr
概要
DAC(Debugging Access Component)のGetNativeCodeInfo APIがasync thunkのMethodDescを正しく解決するための修正。async thunkの場合、対応する実装のMethodDesc(async variant)を選択することで、ネイティブコード情報を正確に報告するようになります。このPRは#125900で導入された回帰を修正します。
変更内容
- src/coreclr/debug/daccess/dacdbiimpl.cpp:
DacDbiInterfaceImpl::GetNativeCodeInfoを更新し、解決されたMethodDescがasync thunkの場合にGetAsyncVariantNoCreate()を使用してasync実装のMethodDescを取得するよう修正
パフォーマンスへの影響
影響なし
関連Issue
その他
なし
#126715 Re-enable FEATURE_CORPROFILER for tvOS to match iOS/MacCatalyst
- 作成者: @steveisok
- 作成日時: 2026年04月09日 15:48:45(UTC)
- マージ日時: 2026年04月10日 06:06:50(UTC)
- ラベル: area-Diagnostics-coreclr
概要
tvOS向けの FEATURE_CORPROFILER 機能フラグを再び有効化し、Apple モバイルプラットフォーム(iOS/MacCatalyst/Android)間で一貫性を保つ変更です。PR #126550 でtvOSのみプロファイラーが無効化されたことにより、Thread 構造体のオフセットが変わり、asmconstants.h の静的アサーションが失敗していました。tvOSをiOS/MacCatalystと同じ扱いにすることで、構造体レイアウトを正常に戻し、ビルドエラーを解決します。
変更内容
- src/coreclr/clrfeatures.cmake: tvOS向けの
AND NOT CLR_CMAKE_TARGET_TVOS条件をコメントアウト。これによりFEATURE_CORPROFILERが tvOS でも有効になり、iOS/MacCatalyst/Android と同じ動作となります。
パフォーマンスへの影響
FEATURE_CORPROFILER の有効化に伴い、Thread 構造体に 3 つのプロファイラー関連フィールド(m_pProfilerFilterContext、m_profilerCallbackState、m_dwProfilerEvacationCounters)が復元されます(合計 144 バイト)。これによる tvOS のメモリ・パフォーマンスへの影響は、他の Apple モバイルプラットフォームと同等になります。
関連Issue
なし
その他
- 影響を受けるビルド構成: tvOS_Shortstack_arm64、tvOSSimulator_Shortstack_x64、tvOSSimulator_Shortstack_arm64
asmconstants.hの静的オフセットアサーション(__builtin_offsetof(Thread, m_pInterpThreadContext))が正しく機能するため、オフセット値の手動調整が不要になります
#126713 [cDAC] Add typed field extension methods for Data classes
- 作成者: @max-charlamb
- 作成日時: 2026年04月09日 15:30:53(UTC)
- マージ日時: 2026年04月10日 17:05:15(UTC)
- ラベル: area-Diagnostics-cdac
概要
cDAC管理側リーダー向けの型付きフィールド拡張メソッドを追加し、すべてのIData<T>クラスを新メソッドで統一しました。ネイティブデータディスクリプタ型システムを利用した管理側の型検証を実装しています。
新しいTargetFieldExtensionsには以下のメソッドが含まれます:
ReadField<T>— プリミティブフィールド読み取り(型検証付き)ReadPointerField/ReadPointerFieldOrNull— ポインタフィールド読み取りReadNUIntField— ネイティブ符号なし整数フィールド読み取りReadCodePointerField— コードポインタフィールド読み取りReadDataField<T>/ReadDataFieldPointer<T>— Dataストラクト読み取り(インライン/ポインタ)ReadFieldOrDefault<T>— オプショナルフィールド読み取り(デフォルト値付き)
変更内容
新規追加:
TargetFieldExtensions.cs— 型付きフィールド読み取りメソッドと互換性チェック用アサーション機能
ネイティブディスクリプタ更新:
datadescriptor.inc— フィールド型アノテーション修正(4箇所)
~130個のIData<T>クラス更新 — すべてのデータクラスを新メソッドに統一。例:target.Read<T>(address + (ulong)type.Fields[...].Offset) → target.ReadField<T>()
バグ検出・修正:
DynamicStaticsInfo.GCStatics/NonGCStatics— ディスクリプタ記載のuint32は実際にはTADDR(ポインタ)EEClass.FieldDescList— ポインタフィールドをRead<ulong>で読み込み(32ビットで破損)ExceptionClause.ClassToken—TypeHandle(nuint)をuintとして読み込みSimpleComCallWrapper.RefCount— 符号付きLONGLONGを符号なしulongで読み込みNativeCodeVersionNode.NativeCode— ディスクリプタはT_POINTER、実際はCodePointerMethodTable.EEClassOrCanonMT— ディスクリプタはT_NUINT、管理側がポインタで読み込み
パフォーマンスへの影響
影響なし
関連Issue
その他
- DEBUG/CHECKED ビルド時のみ型互換性チェックが有効化される
- Copilotレビューで低信頼度のコメント1件:
PrecodeMachineDescriptor.csのStubPrecodeSizeフィールド読み込みロジックに潜在的な問題指摘あり - 型検証インフラ(テスト、Roslyn生成器、ランタイムヘルパー)も追加
#126680 Enable runtime-async unconditionally in System.Private.CoreLib (CoreCLR and NativeAOT)
- 作成者: @Copilot
- 作成日時: 2026年04月09日 01:07:58(UTC)
- マージ日時: 2026年04月10日 03:08:09(UTC)
- ラベル: area-System.Reflection
概要
runtime-async=on コンパイラ機能をすべてのビルド構成(Debug、Checked、Release)で無条件に有効化します。従来は Release ビルドのみ、また NativeAOT では riscv64/loongarch64 を除外していた制限を廃止し、統一的に有効化することで、全ビルド構成での非同期機能の動作検証とサポートを強化します。
変更内容
- src/coreclr/System.Private.CoreLib/System.Private.CoreLib.csproj:
<Features>$(Features);runtime-async=on</Features>を Release 構成専用の PropertyGroup から構成非依存の PropertyGroup に移動し、Debug/Checked/Release ビルドすべてで runtime-async 機能を有効化 - src/coreclr/nativeaot/System.Private.CoreLib/src/System.Private.CoreLib.csproj: riscv64/loongarch64 アーキテクチャ除外条件と関連する古い Issue 参照コメントを削除し、runtime-async を無条件で有効化(#125446、#125114 で対応済み)
パフォーマンスへの影響
影響なし(機能フラグの有効化であり、ランタイム動作自体の変更ではない)
関連Issue
#125446、#125114(riscv64/loongarch64 サポート対応)
その他
- 内部実装の変更(System.Private.CoreLib のコンパイラ機能設定)
- NativeAOT における riscv64/loongarch64 対応が完了したため、除外条件が不要になった
#126676 Add WASM_MEMORY_ADDR_REL_LEB Relocation Type
- 作成者: @adamperlin
- 作成日時: 2026年04月09日 00:19:08(UTC)
- マージ日時: 2026年04月10日 16:54:37(UTC)
- ラベル: area-crossgen
概要
WebAssemblyのR2R (Ready-to-Run) シナリオで使用する新しいリロケーションタイプ WASM_MEMORY_ADDR_REL_LEB を追加します。このリロケーションは、イメージベースからの相対オフセットをULEB128エンコードで表現し、メモリロード/ストア命令の offset イミディエートとして直接使用できます。
例:
global.get $__image_base
i32.load align=... offset=<reloc>
変更内容
- JitInterface層 (
CorInfoTypes.cs,CorInfoImpl.cs):WASM_MEMORY_ADDR_REL_LEBをCorInfoReloc列挙型に追加し、管理されたJIT-EEインターフェースにマッピング - リロケーション解決 (
WasmObjectWriter.cs): WasmオブジェクトライターにWASM_MEMORY_ADDR_REL_LEBのリロケーション処理ロジックを追加 - Wasm命令生成 (
WasmInstructions.cs): メモリ引数のオフセットエンコーディングをリファクタリングし、定数値またはリロケーション可能なシンボルの両方に対応。I32.LoadWithRVAOffset()ヘルパーAPIを追加 - リロケーション定義 (
Relocation.cs): 新しいRelocTypeの読み書き・サイズ情報対応 - バージョニング (
jiteeversionguid.h): JIT/EEインターフェース変更に伴いGUIDを更新
パフォーマンスへの影響
影響なし
関連Issue
その他
本PR は #126662 から抽出されたもので、PR規模と複雑性を削減するためのもの。新機能自体はまだ使用されておらず、#126662 で利用予定です。内部実装変更(JIT/EEインターフェース)であり、公開APIには影響なし。
#126663 [Wasm RyuJit] fix funclet prolog and epilog codegen
- 作成者: @AndyAyersMS
- 作成日時: 2026年04月08日 21:37:55(UTC)
- マージ日時: 2026年04月10日 14:26:25(UTC)
- ラベル: arch-wasm area-CodeGen-coreclr
概要
WebAssembly RyuJIT のfunclet(例外処理の分離コード)のプロロローグ・エピローグコード生成を修正するものです。genEmitStartBlock の呼び出しを funclet prolog IG セットアップ後に遅延させ、エピローグ生成のための BasicBlock をエミッターからコード生成側に戻すようにしました。また、funclet を含むメソッドについて、R2R フェイルオーバーをデフォルト有効化しています(JitWasmFunclets=1 で無効化可能)。加えて、ノード参照の重複収集を防ぐ修正を含みます。
変更内容
- codegen.h:
genFuncletEpilogメソッドシグネチャを変更し、BasicBlock*パラメータを追加 - 各アーキテクチャ実装 (arm, arm64, loongarch64, riscv64, xarch):
genFuncletEpilogシグネチャを更新してBasicBlock*パラメータに対応 - codegencommon.cpp: funclet を含むメソッドに対する R2R フェイルオーバー処理を追加
- codegenlinear.cpp:
genFuncletEpilog呼び出し時に BasicBlock を渡すよう修正 - codegenwasm.cpp: funclet prolog IG セットアップのタイミングと
genEmitStartBlockの呼び出し順序を修正 - emit.cpp: エミッターから codegen への BasicBlock 戻り値処理を追加
- jitconfigvalues.h:
JitWasmFunclets構成値を追加 - regallocwasm.cpp: ノード参照の重複収集を防ぐロジックを修正(連続した同じノードのみをスキップ)
パフォーマンスへの影響
影響なし(バグ修正による正確性向上が主目的)
関連Issue
#125756 - ノード参照の重複収集に関連
その他
- WebAssembly プラットフォーム向けの funclet 生成については、JIT ホストが funclet を個別の関数として抽出できるようになるまで、R2R フェイルオーバーが必要です
- AMD64 実装で
blockパラメータが未使用となっているため、将来的に未使用パラメータ警告の対処が必要
#126638 Agentics: Add Extensions & Compression review agent and instructions
- 作成者: @T-Gro
- 作成日時: 2026年04月08日 11:24:20(UTC)
- マージ日時: 2026年04月10日 08:13:22(UTC)
- ラベル: area-Infrastructure
概要
Microsoft.Extensions.*およびSystem.IO.Compressionライブラリ向けのCopilot agentic assetを追加するPRです。専用のレビューエージェント、書き込みスキル、および複数の拡張機能エリア向けのフォルダスコープ命令ファイルが含まれます。これらは実装ガイダンス、検証ポイント、パフォーマンス・セキュリティに関する推奨事項を提供します。
変更内容
- extensions-reviewer.md: 新しい「Extensions & Compression」レビューエージェントを定義(原則、チェック次元、ルーティング、ワークフロー)
- extensions-review/SKILL.md: Extensions/Compression実装向けのライティングスキルおよび例を追加
- 拡張機能別命令ファイル: DI、Configuration、Logging、Hosting、Options、Caching、共通ライブラリ向けの各命令ファイルを追加
- DI: ライフタイム、解決、trim/AOT、テストガイダンス
- Logging: LoggerMessageジェネレータ、セキュリティ、パフォーマンス
- Configuration: バインディング、ソースジェネレータ互換性
- Hosting: ライフサイクル、テスト信頼性
- Options: 検証、監視、ジェネレータ互換性
- Caching: 正確性/パフォーマンス(キー、削除、スタンピード防止)
- compression.instructions.md: フォーマット正確性、セキュリティ、パフォーマンス、相互運用テスト向けのCompressionガイダンスを追加
これらはすべて新規追加で、既存コードへの変更はありません。
パフォーマンスへの影響
影響なし (このPRは開発ツーリング・レビュープロセス資産の追加であり、ランタイムまたはライブラリのパフォーマンスに直接的な影響はありません)
関連Issue
なし
その他
- 本PRは「Extensions & Compression」レビューエージェントを個別に呼び出し可能な別エージェントとして追加します
- Copilotによるレビューで10ファイル中10ファイルが確認されました
- 開発者向けドキュメント・レビューガイダンス資産の拡充により、これらのライブラリエリアへの貢献品質向上を目指しています
#126632 Add ProcessStartInfo.StartDetached to start processes detached from parent session/console
- 作成者: @Copilot
- 作成日時: 2026年04月08日 08:24:30(UTC)
- マージ日時: 2026年04月10日 21:26:00(UTC)
- ラベル: area-System.Diagnostics.Process
概要
ProcessStartInfo.StartDetached プロパティを新規追加し、親プロセスのセッション/コンソールから独立したプロセスを開始できるようにします。このプロパティはWindows(DETACHED_PROCESSフラグ)、macOS(POSIX_SPAWN_SETSID)、その他Unix(setsid())で異なるメカニズムを使用して実装されています。
使用例:
var psi = new ProcessStartInfo("myserver")
{
StartDetached = true
};
// stdin/stdout/stderr は自動的に NUL/dev/null にリダイレクトされます
Process.Start(psi);
変更内容
- ProcessStartInfo.cs —
StartDetachedプロパティを追加(XML ドキュメント付き);UseShellExecute = trueとの組み合わせでInvalidOperationExceptionをスロー - Process.cs — デタッチ時に明示的に設定されていない標準ハンドルを null デバイスにリダイレクト;単一の null ハンドルを開きスタート後に破棄
- SafeProcessHandle.cs / SafeProcessHandle.Windows.cs / SafeProcessHandle.Unix.cs — 各プラットフォームでの
StartDetachedフラグの実装;Windows でDETACHED_PROCESSフラグを追加 - Interop.ProcessOptions.cs —
DETACHED_PROCESS定数を追加 - Interop.ForkAndExecProcess.cs — マネージド相互運用チェーン全体で
startDetachedパラメータをスレッド化 - pal_process.h / pal_process.c / pal_process_wasi.c — ネイティブ実装:macOS で
POSIX_SPAWN_SETSID、その他 Unix でsetsid()を使用 - Strings.resx — エラーメッセージリソースキー
StartDetachedNotCompatibleを追加 - ProcessTests.cs / ProcessTests.Unix.cs / ProcessTests.Windows.cs / ProcessHandlesTests.cs —
UseShellExecute検証、プロセスグループ隔離、基本的な動作確認を含むテスト追加
パフォーマンスへの影響
影響なし。ただし、デタッチプロセスでは標準ハンドルが null デバイスにリダイレクトされるため、ハンドルリークを防ぎメモリ効率が向上します。
関連Issue
なし
その他
- 互換性:
UseShellExecute = trueとの併用は禁止されます(CreateNoWindowは許可) - リソース管理: 未設定の標準 I/O ハンドルは自動的に null デバイスにリダイレクトされ、ロック外で単一ハンドルが開かれ
finallyブロックで破棄されます - テスト戦略: デタッチプロセスが親シグナル受信後も生存することを確認;Windows Nano Server および
RemoteExecutor非対応環境ではスキップ - Unix ヘルパー:
SendSignalは汎用的に実装(シグナルをGetPlatformSignalNumber経由でkill(-pgid, signalNumber)に渡す)
#126631 [Apple mobile] Skip unsupported tests on Apple mobile platforms
- 作成者: @kotlarmilos
- 作成日時: 2026年04月08日 08:22:42(UTC)
- マージ日時: 2026年04月10日 07:40:44(UTC)
- ラベル: area-Infrastructure-mono
概要
Apple mobile platforms(iOS/tvOS/MacCatalyst)でのテスト失敗に対応するため、Mono AOT IL stripping によって method bodies が変更・削除される環境でのテストをスキップまたは条件付けする変更です。IsMethodBodySupported を拡張して aggressively-trimmed builds を検出し、影響を受けるテストを条件付きで実行します。
変更内容
- PlatformDetection.cs:
IsMethodBodySupportedロジックを更新し、aggressively-trimmed builds(Apple mobile含む)をサポート対象外として扱うよう拡張 - CustomMethodInfoTests.cs:
GetMethodImplementationFlags_ReturnsILテストをPlatformDetection.IsNotMonoRuntimeで条件付け - CustomConstructorInfoTests.cs:
GetMethodImplementationFlags_ReturnsILテストをPlatformDetection.IsNotMonoRuntimeで条件付け - ProcessTests.cs:
ProcessTests.Start_Disposed_ThrowsObjectDisposedExceptionをApple mobile platforms でスキップ - tests.proj: System.Diagnostics.TraceSource.Config.Tests.csproj をビルド対象から除外
- build.proj:
RestoreUseStaticGraphEvaluation=falseを設定し、既知の NuGet 問題に対応
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
Copilot による査読では、テスト条件が IsNotMonoRuntime に限定されており、NativeAOT などの他の aggressively-trimmed 環境での失敗可能性が指摘されています。より正確には IsMethodBodySupported または IsNotBuiltWithAggressiveTrimming で条件付けすることが推奨されています。
#126629 Add NonInheritedFileHandle_IsNotAvailableInChildProcess test to ProcessHandlesTests
- 作成者: @Copilot
- 作成日時: 2026年04月08日 06:08:25(UTC)
- マージ日時: 2026年04月10日 10:01:13(UTC)
- ラベル: area-System.Diagnostics.Process test-enhancement
概要
ProcessHandlesTestsにファイルハンドル継承動作を検証するテストを追加。InheritedHandlesを使用して子プロセスを生成する際、ハンドルが継承されたかどうかを確認します。本PR内で検討された他の変更(ネイティブPALエクスポート、SafeFileHandleパス解決)は、OSレベルのパス解決がユーザーフレンドリーなパスではなくデバイスパスを返すため、レビュアーのフィードバックに基づいて元に戻されました。
変更内容
ProcessHandlesTests.cs:
NonInheritedFileHandle_IsNotAvailableInChildProcessテスト追加([ConditionalTheory])InheritedHandles = []の場合:ハンドルが子プロセスでアクセス不可であることを検証InheritedHandles = [fileHandle]の場合:ハンドルが子プロセスでアクセス可能かつ同じファイルを指すことを検証FileShare.Noneでファイルをオープンして独立したオープンを防止GetSafeFileHandleIdで取得したプラットフォーム固有のアイデンティティで比較- ハンドルが継承されない場合は
Win32Exceptionをキャッチ
ProcessHandlesTests.Unix.cs(新規):
GetSafeFileHandleIdを実装Interop.Sys.FStatを使用して"{status.Dev}:{status.Ino}"(デバイス+iノード)をファイルアイデンティティとして返却- syscall失敗時は
Win32Exceptionをスロー
ProcessHandlesTests.Windows.cs:
GetSafeFileHandleIdを追加実装Interop.Kernel32.GetFinalPathNameByHandleを使用してノーマライズされたファイルパスを返却- 失敗時は
Win32Exceptionをスロー
System.Diagnostics.Process.Tests.csproj: Unix向けにProcessHandlesTests.Unix.csを追加、FStat/GetFinalPathNameByHandle対応アセンブリを参照
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
コード内のコメントでは、ハンドル継承の制限により確実にハンドルが継承されなかったことを確認しにくい理由を説明(OSが異なるパイプ/ファイル/デバイス用に同じハンドル番号を再利用する可能性があるため、アイデンティティ比較アプローチを採用)。
#126582 Convert throw and thread helpers to UCO
- 作成者: @am11
- 作成日時: 2026年04月06日 17:39:13(UTC)
- マージ日時: 2026年04月10日 04:24:11(UTC)
- ラベル: area-VM-coreclr community-contribution
概要
Throw と Thread のヘルパーを Unmanaged Calling Origination(UCO)に変換するリファクタリング。マネージドコード側でスロー処理とスレッド操作を管理するための呼び出し規約を統一し、VM(仮想マシン)レイヤーでの実装を簡潔化するもの。優先度3の改善目標(#123864)に貢献します。
変更内容
- callhelpers.h: 呼び出しヘルパーの実装を大幅削減(98行削除、48行追加)し、UCO ベースの設計に統合
- excep.cpp / exceptionhandling.cpp: 例外処理ロジックを簡潔化し、新しい呼び出し規約に対応
- Thread.CoreCLR.cs: マネージドスレッド操作のラッパーを更新(内部実装の調整)
- GC.CoreCLR.cs: GC ヘルパーで新しい呼び出し規約に対応
- ExceptionHandling.cs (NativeAOT): NativeAOT 環境での例外処理を UCO パターンで実装
- wasm/callhelpers-reverse.cpp: WebAssembly 環境用の逆呼び出し処理を新規追加
- その他: VM 内の同期処理、シグネチャ定義、ファイナライザスレッドの実装を調整
パフォーマンスへの影響
影響なし。本変更はリファクタリング性質であり、機能的な動作変更を伴いません。
関連Issue
その他
- 本変更はランタイムの内部実装(VM レイヤー)に限定されており、公開 API への影響はありません。
- NativeAOT と WebAssembly を含む複数のプラットフォーム環境をサポートしています。
- 複数のレビュワーによる詳細なレビューが実施されています。
#126571 Fix COM reentrancy contract violations and re-enable the ExtensionPoints test
- 作成者: @Copilot
- 作成日時: 2026年04月06日 05:45:15(UTC)
- マージ日時: 2026年04月10日 23:00:26(UTC)
- ラベル: area-Interop-coreclr
概要
CoreCLR COM相互運用性のコントラクト違反を修正し、ExtensionPointsテストを再度有効化するPRです。ネイティブCOMのクリーンアップ・割り当てフック中にマネージドコード(管理されたIMallocSpy実装など)に合法的に再入可能なパスに対して、コントラクト違反の適切なアノテーションを追加しました。
変更内容
- olevariant.cpp:
OleVariant::ClearLPSTRArrayおよびClearLPWSTRArrayのCoTaskMemFreeクリーンアップパスにPERMANENT_CONTRACT_VIOLATION(ThrowsViolation, ReasonRuntimeReentrancy)を追加。関数自体はNOTHROWのまま。 - comcallablewrapper.cpp:
ComPreStubWorkerの管理例外ディスパッチャーおよびアンワインドハンドラー設定をBEGIN_CONTRACT_VIOLATION(ThrowsViolation) / END_CONTRACT_VIOLATIONブロックで囲み、外側のコントラクトをSTATIC_CONTRACT_NOTHROWに更新。 - comcallablewrapper.h:
CheckParentComVisibilityから未使用のfForIDispatchパラメータを削除し、冗長なCheckParentComVisibilityNoThrowヘルパーを削除。 - stubhelpers.cpp、stdinterfaces.cpp: 新しい
CheckParentComVisibility()シグネチャに対応するコールサイトを更新。 - ExtensionPoints.cs:
Validate_Managed_IMallocSpyテストの一時的なActiveIssueスキップを削除して再度有効化。
パフォーマンスへの影響
影響なし
関連Issue
その他
- Copilotによるレビュー時に、
FEATURE_INTERPRETER下でのComPreStubWorkerにおける早期リターン時にEND_CONTRACT_VIOLATIONに到達しない可能性に関する低信頼度の指摘あり(未解決)。 olevariant.cpp:1749におけるPERMANENT_CONTRACT_VIOLATIONスコープが条件付きで実行可能なコード領域全体に適用されている点(cElements==0やnullエントリの場合も含む)について、より限定的なスコープの検討が推奨されている。
#126512 Merge hotreload-utils source into runtime repo
- 作成者: @steveisok
- 作成日時: 2026年04月03日 18:35:24(UTC)
- マージ日時: 2026年04月10日 16:19:03(UTC)
- ラベル: area-Infrastructure
概要
dotnet/hotreload-utils リポジトリのホットリロード・デルタ生成ツールチェーンをランタイムリポジトリに統合し、外部NuGetパッケージ依存を排除しました。src/tools/hotreload-delta-gen/に5つのプロジェクト(Generator、Generator.Tasks、Generator.Frontend、Generator.Data、Generator.BuildTool)とその共有コードを追加し、eng/testing/hotreload-delta-gen.targetsで従来のNuGet .targetsファイルを置き換えました。ApplyUpdateテスト、WASMホットリロードテスト、Monoサンプルの3つのコンシューマーを更新しました。
変更内容
ホットリロード・デルタ生成ツール全体の統合:
src/tools/hotreload-delta-gen/に5プロジェクトを追加Microsoft.DotNet.HotReload.Utils.Generator:Roslyn HotReloadService を使用したコア・デルタ生成ロジックMicrosoft.DotNet.HotReload.Utils.Generator.Tasks:MSBuildタスク(HotReloadDeltaGeneratorComputeScriptOutputs)Microsoft.DotNet.HotReload.Utils.Generator.Frontend:CLI引数解析とエントリーポイントMicrosoft.DotNet.HotReload.Utils.Generator.Data:JSON シリアライズ可能な契約型(スクリプト、出力サマリー)Microsoft.DotNet.HotReload.Utils.Generator.BuildTool:実行可能ファイル
MSBuild統合:新しい
eng/testing/hotreload-delta-gen.targetsがNuGetパッケージを置き換えコンシューマー更新:3つのテスト/サンプルプロジェクトをローカルターゲットにポイント
src/libraries/System.Runtime.Loader/tests/ApplyUpdate/src/tests/FunctionalTests/WebAssembly/Browser/HotReload/ApplyUpdateReferencedAssembly/src/mono/sample/mbr/console/ConsoleDelta.csproj
バージョン管理から削除:
eng/Version.Details.xmlとeng/Version.Details.propsからhotreload-utils依存を除去ビルド順序化:
src/libraries/pretest.projにBuildToolとTasksを追加アナライザー抑制:ベンダリングコードに
RunAnalyzers=falseを適用(ilinkパターンに準拠)
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
- この変更は内部ツール統合であり、公開APIに影響しません
- クロスリポジトリ依存を削除することで、ビルドの自律性が向上します
- ホットリロード機能自体の動作に変更はなく、既存の互換性が保たれます
#126511 Replace contract factories with registration-based ContractRegistry
- 作成者: @max-charlamb
- 作成日時: 2026年04月03日 17:49:28(UTC)
- マージ日時: 2026年04月10日 19:45:11(UTC)
- ラベル: area-Diagnostics-coreclr
概要
cDAC(CoreCLR Diagnostic Access Component)のコントラクト初期化モデルを、26個の個別ファクトリクラスから登録ベースの ContractRegistry API に変更します。これにより、外部ランタイム(NativeAOT、Mono等)の契約サポートを追加する際に、コアリーダーの複数ファイルを修正する必要がなくなります。
新しい登録API(内部実装、将来の外部ランタイム向け):
public static void Register(ContractRegistry registry)
{
registry.Register<IThread>(1, static t => new Thread_1(t));
registry.Register<IRuntimeTypeSystem>(1, static t => new RuntimeTypeSystem_1(t));
}
変更内容
新規追加:
ContractRegistry.Register<TContract>(int version, Func<Target, TContract> creator)API(抽象クラス)CoreCLRContracts.cs:26個のコントラクト実装版すべて(Thread_1、Object_1、GC_1等)を一箇所に集約して登録CachingContractRegistry:(Type, version) → creatorマッピングに基づくコントラクト解決キャッシング
削除(26ファイル):
- ThreadFactory、ObjectFactory、GCFactory、RuntimeTypeSystemFactory、ExceptionFactory等、すべての名前付きファクトリクラス
変更(内部実装):
- 各コントラクト実装(Thread_1、Object_1等)のコンストラクタを簡略化:ファクトリから引数を受け取らず、
Target targetのみを受け取り、必要なグローバル情報を内部で読み込む ContractDescriptorTarget.TryCreate():additionalFactoriesパラメータをcontractRegistrationsに変更し、登録アクションの配列を受け取る- テストとエントリポイント:
CoreCLRContracts.Registerを使用してターゲット生成時に登録
パフォーマンスへの影響
影響なし。コントラクト解決のキャッシング機構は変わらず、初期化フェーズでのオーバーヘッドは同等です。
関連Issue
なし
その他
- 全1406個の既存cDACテストが合格
- 互換性:コントラクト実装は内部実装のため破壊的変更ではない
- 設計的意義:外部ランタイムパッケージが
ContractRegistry.Register()メソッドを実装することで、コアリーダーを修正せずに契約サポートを追加可能(例:ContractDescriptorTarget.TryCreate(addr, ..., [CoreCLRContracts.Register, NativeAOTContracts.Register], out target))
#126158 fix ChainedRateLimiter treating IdleDuration and chained ReplenishmentRateLimiters incorrectly
- 作成者: @DeagleGross
- 作成日時: 2026年03月26日 16:51:47(UTC)
- マージ日時: 2026年04月10日 16:18:04(UTC)
- ラベル: area-System.Threading
概要
ChainedRateLimiterのIdleDurationプロパティとReplenishing RateLimiter統合の問題を修正します。
主な修正内容:
IdleDurationの意味論を修正:子要素のいずれかがIdleDuration == nullを報告する場合、nullを返すように変更ChainedRateLimiter内の内部replenishing limiterに対してDefaultPartitionedRateLimiter.Heartbeat()からReplenishment呼び出しを確保RateLimiter.CreateChained(...)への渡されるlimiterに応じて、2つの異なるChained limiter実装を提供
変更内容
- ChainedRateLimiter.cs:
IdleDurationの意味論を修正し、内部replenishing limiterをReplenishするTryReplenish()を追加 - ChainedRateLimiterShared.cs: 共有ロジック用の新規ファイル(183行追加)
- ChainedReplenishingRateLimiter.cs: Replenishing RateLimiter向けの新規実装ファイル(127行追加)
- DefaultPartitionedRateLimiter.cs: Heartbeat処理で
ChainedRateLimiterを特別扱いしてReplenishment呼び出しを実施 - PartitionedRateLimiter.cs, RateLimiter.cs: 新規メソッド追加による公開API拡張
- テストファイル: Chained limiterのReplenishment挙動と空きベース削除の検証に関する網羅的なカバレッジを追加
パフォーマンスへの影響
影響なし
関連Issue
その他
本変更により、ChainedRateLimiterの2つの実装パターン(通常のRateLimiterチェーン用と、replenishing limiterを含むチェーン用)が導入されます。内部実装の分離により、異なるセマンティクスに対応した専用実装が可能になります。
#126157 [wasm][coreclr] Batch CoreCLR library test suites on Helix
- 作成者: @radekdoulik
- 作成日時: 2026年03月26日 16:51:12(UTC)
- マージ日時: 2026年04月10日 10:14:08(UTC)
- ラベル: arch-wasm area-Infrastructure-coreclr
概要
WASM CoreCLR ライブラリテストのHelix キューイング圧力を削減するため、約172個の個別テスト作業項目を約21個のバッチ作業項目にグループ化(88%削減)し、総マシン時間を56%削減(437分→195分)します。すべてのテスト結果は同一で、失敗はありません。
変更内容
eng/testing/WasmBatchRunner.sh(新規): 単一のHelix作業項目内で複数のテストスイートを順序実行するバッチランナースクリプト。スイートごとにHELIX_WORKITEM_UPLOAD_ROOTディレクトリを分離してрезультat結果を隔離し、エラー処理と後処理に対応src/libraries/sendtohelix-browser.targets(修正):WasmBatchLibraryTestsプロパティを追加(CoreCLR+Chromeではデフォルト有効)_AddBatchedWorkItemsForLibraryTestsターゲット: バッチディレクトリをステージング、zip化し、HelixCommandを構築。サンプルアプリはバッチ対象外- 元のターゲットは
WasmBatchLibraryTests != true時のみ実行
src/tasks/HelixTestTasks/(新規プロジェクト):GroupWorkItemsMSBuildタスク: ファイルサイズ別の貪欲ビンパッキング、大規模スイート(>50MB)は個別実行ComputeBatchTimeoutMSBuildタスク: スイートあたり20分+30分最小値(WASM起動オーバーヘッド考慮)
パフォーマンスへの影響
大幅な改善(マシン時間ベース):
- 総マシン時間: 437分 → 195分(56%削減、245分短縮)
- Helix作業項目: 172個 → 21個(88%削減)
- キュースロット消費: 151個削減
- テスト実行数: 259,527(変化なし、品質維持)
削減の内訳:Helix per-項目オーバーヘッド(スケジューリング+ペイロード+アップロード+報告)で約1.5分/項目×151項目=約227分節約。最長バッチは30m13s(タイムアウト160分以内)。
関連Issue
なし
その他
- 互換性:
/p:WasmBatchLibraryTests=falseで個別作業項目モードに戻せます(オプトアウト可能) - 設計: バッチランナーは既存の
RunTests.shの薄いラッパーで、xharness/Chrome/WASMの設定は各スイートのランナースクリプト内に留まり、結合度は最小限 - ディスク効率: バッチ実行間でスイートディレクトリをクリーンアップして空き容量を確保
#125853 Update baseline build instructions to use working branch instead of main
- 作成者: @Copilot
- 作成日時: 2026年03月20日 19:18:39(UTC)
- マージ日時: 2026年04月10日 02:57:15(UTC)
- ラベル: area-Infrastructure
概要
baseline buildの手順を簡略化し、main ブランチへの切り替えを廃止して、working branchで直接baseline buildを実行するよう更新しました。これにより、main とworking branchが分岐している場合の不要な作業を削減できます。
変更内容
.github/copilot-instructions.md- Step 2: baseline buildの実行をworking branchで行うよう指示を変更(main への切り替え指示を削除)
- Step 3: baseline build後の「working branchへの切り替え」という説明文を削除
パフォーマンスへの影響
影響なし(ワークフロー効率の改善は定性的。不要なブランチ切り替えが減少)
関連Issue
なし
その他
この変更は開発者向けのドキュメント更新であり、baseline buildを「変更前の状態」として捉え、main ブランチの状態ではなくworking branchの状態を基準にすることで、より現実的なベースラインを提供します。
#125819 Guard stackwalking in IXClrDataStackWalk codepaths to account for underlying max size of context
- 作成者: @hoyosjs
- 作成日時: 2026年03月20日 06:03:47(UTC)
- マージ日時: 2026年04月10日 04:15:28(UTC)
- ラベル: area-Diagnostics-coreclr
概要
CoreCLR DAC(デバッグ支援コンポーネント)のスタックウォーキング機能(IXClrDataStackWalk)において、メモリ安全性の問題を修正します。Windows SDK の CONTEXT 構造体にインラインXSTATE(拡張状態)を含めた大きなバッファをcallerが渡した場合、バッファサイズの検証が正しく機能せず、メモリオーバーラン(読み書きの境界外アクセス)が発生する問題を解決します。
具体的には、GetContextとSetContext2メソッドにおいて、コピー処理のサイズをT_CONTEXTの実際のサイズ(AMD64では0x4D0バイト)に制限し、overflowを防ぎます。
変更内容
- src/coreclr/debug/daccess/stack.cpp
GetContext: ローカルcontext構造体を超えて読み取ることを防ぐため、コピーサイズをsizeof(T_CONTEXT)に制限SetContext2: callerが提供する大きなバッファ(XSTATE付き)から隣接フィールドを上書きするのを防ぐため、コピーサイズをsizeof(m_context)に制限- 変更は合計6行(追加3行、削除3行)
パフォーマンスへの影響
影響なし(メモリ安全性の修正であり、パフォーマンスへの悪影響はない)
関連Issue
なし
その他
このは内部実装(DAC/デバッグ支援コンポーネント)の修正であり、公開APIには影響を与えません。ただし、デバッガやプロファイラなどのツールを通じて不正なメモリアクセスによるクラッシュ対象となるため、安定性向上に寄与します。
#125630 Simplify TrimmerSingleWarn intermediate assembly update using MSBuild item Update
- 作成者: @Copilot
- 作成日時: 2026年03月16日 18:59:52(UTC)
- マージ日時: 2026年04月10日 16:49:14(UTC)
- ラベル: linkable-framework area-Tools-ILLink
概要
MSBuild設定ファイルの_PrepareTrimConfigurationタスク内で、TrimmerSingleWarnメタデータを適用する際の複雑な交差計算パターンをMSBuildのUpdate機能で直接置き換えることで、コードを簡潔化し、アイテム順序を保持するように改善しました。
変更内容
- Microsoft.NET.ILLink.targets: 13行の交差パターン(Include/Remove/Remove+Re-include)を3行の
Updateに置き換えResolvedFileToPublish Update="@(IntermediateAssembly)"で直接マッチするアイテムを更新- メタデータ参照を
%(ResolvedFileToPublish.TrimmerSingleWarn)として修飾し、MSB4096警告(限定されていないメタデータバッチング)を防止
パフォーマンスへの影響
ビルド処理の簡潔化によりMSBuild評価ステップが削減されるため、わずかなビルド時間の改善が期待できます。影響なし(負の影響はなし)。
関連Issue
#124801(このPRは同Issueのレビューフィードバックへのフォローアップ)
その他
- 変更は内部ビルドロジック(
Microsoft.NET.ILLink.targets)に限定され、公開APIへの影響なし - アイテムの順序保持により、下流の処理での予測可能性が向上
#125613 [release/10.0] Fix missing call to write barrier in static constructors of ref structs
- 作成者: @janvorli
- 作成日時: 2026年03月16日 13:46:15(UTC)
- マージ日時: 2026年04月10日 17:48:32(UTC)
- ラベル: Servicing-approved area-CodeGen-coreclr
概要
.NET 10で導入されたリグレッションを修正するPRです。JITコンパイラがref struct型の静的フィールドへの代入時に、write barrier呼び出しを誤って省略していたため、GCヒープ破損を引き起こしていました。静的フィールドは常にGCヒープ上に存在するため、write barierの追加が必要です。この修正により、DOTNET_HeapVerify=1で実行時の致命的エラーが検出されるようになります。
変更内容
- src/coreclr/jit/importer.cpp: JITインポーターのロジックを修正し、"フィールド所有者がbyref-like⇒ターゲットはヒープ上にない"という判定を非静的フィールドのみに限定。静的フィールドについてはこの最適化を適用しないよう修正しました(+2/-2)。
パフォーマンスへの影響
若干の負の影響の可能性があります。以前は誤ってwrite barrier呼び出しが省略されていた静的フィールド代入に対して、今後はwrite barrier呼び出しが追加されるため、これらの操作のコストがわずかに増加します。ただし、動作正確性の修正であり、GCヒープ破損を防ぐ重要な修正です。
関連Issue
#125418(本体修正)
#111733(リグレッション導入)
その他
- .NET 10でのリグレッション、顧客報告による不具合
- release/10.0ブランチへのバックポート
- 修正のリスク評価:低(write barierの追加のみ)
- 顧客から提供されたローカルテストによる検証済み
#124851 Add ActivityTraceFlags.RandomTraceId flag
- 作成者: @Kielek
- 作成日時: 2026年02月25日 10:48:25(UTC)
- マージ日時: 2026年04月10日 00:31:33(UTC)
- ラベル: area-System.Diagnostics.Activity community-contribution
概要
W3C Context Propagation Level 2で定義されるRandomTraceIdフラグのサポートを追加します。ActivityTraceFlags列挙型に新しいフラグを追加し、トレースIDがランダムに生成されたかどうかを示せるようになります。
変更内容
- System.Diagnostics.DiagnosticSource/src/System/Diagnostics/Activity.cs: ActivityクラスにRandomTraceIdフラグ対応ロジックを追加(52行追加)
- System.Diagnostics.DiagnosticSource/ref/System.Diagnostics.DiagnosticSourceActivity.cs: ActivityTraceFlags列挙型にRandomTraceIdフラグを公開API として追加
- System.Diagnostics.DiagnosticSource/src/System/Diagnostics/ActivityCreationOptions.cs: ActivityCreationOptionsの定義を更新(13行追加)
- System.Diagnostics.DiagnosticSource/tests/ActivityTests.cs: RandomTraceIdフラグの動作を検証する包括的なテスト追加(130行追加)
- Microsoft.Extensions.Logging.EventSource関連: EventSourceLoggerおよびテストの軽微な調整
パフォーマンスへの影響
影響なし
関連Issue
その他
- 公開API変更となるため、ActivityTraceFlags列挙型にRandomTraceIdメンバーが追加されます
- W3C Context Propagationの仕様に準拠した実装となります
#124698 Fix SYSLIB1045 code fixer generating duplicate MyRegex names across partial class declarations
- 作成者: @danmoseley
- 作成日時: 2026年02月21日 04:37:17(UTC)
- マージ日時: 2026年04月10日 02:37:06(UTC)
- ラベル: area-System.Text.RegularExpressions
概要
SYSLIB1045コード修復ツール(Regexコンストラクタ呼び出しをGeneratedRegexに変換)がバッチ処理で部分的なクラス宣言に対して複数の修正を同時適用する際、重複したMyRegexプロパティ名を生成していた問題を修正しました。根本原因は、複数のフィクサーが修正前の元のコンパイル状態を参照するため、同一の名前が利用可能と判断されていたためです。
変更内容
- UpgradeToGeneratedRegexCodeFixer.cs:
CountPrecedingRegexCallSitesヘルパーメソッドを追加し、含有型のすべてのDeclaringSyntaxReferencesを走査してRegexコンストラクタ/静的メソッド呼び出しサイトを検出。ファイルパスと位置で決定的にソートし、現在のノードのインデックスに応じてスキップする名前数を決定し、各フィクサーに一意の名前を割り当てます。 - UpgradeToGeneratedRegexAnalyzer.cs: 修正可能なRegex操作の判定ロジックを
IsFixableRegexOperationメソッドに集約し、アナライザーとコード修復ツール間で再利用可能にしました。 - UpgradeToGeneratedRegexAnalyzerTests.cs: 部分的なクラス宣言(同一ファイル内および別ファイル)における一意の名前生成を検証するテストを追加。
MyRegexとMyRegex1が正しく生成されることを確認します。
パフォーマンスへの影響
影響なし
関連Issue
その他
なし
#118057 Delete DEFAULT_STACK_SIZE
- 作成者: @MichalStrehovsky
- 作成日時: 2025年07月25日 09:55:38(UTC)
- マージ日時: 2026年04月10日 08:13:24(UTC)
- ラベル: area-VM-coreclr
概要
DEFAULT_STACK_SIZE マクロの定義を削除します。このマクロは未使用またはレガシーな定義であり、コードの簡潔化を目的としています。
変更内容
src/coreclr/vm/corhost.cpp:DEFAULT_STACK_SIZEの定義を削除(6行削除)src/coreclr/vm/threads.cpp:DEFAULT_STACK_SIZEの参照を削除し、関連コードを整理(27行削除、1行追加)
パフォーマンスへの影響
影響なし
関連Issue
その他
CLRランタイムの内部実装に関する変更であり、公開APIへの影響はありません。