注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
- #135536 [release/11.0] Clarify async validation XML documentation
- #135517 Pass CLR_CROSS_COMPONENTS_BUILD as a separate -cmakeargs
- #135480 Skip test135234 where working-set monitoring is unsupported
- #135470 [cDAC] Test entry-point MethodDesc resolution
- #135454 [release/8.0-staging] Fix Duplicate ownership state machine under concurrency for NCrypt handles
- #135452 Wait for EE startup before finalizer managed execution
- #135450 Consolidate cDAC entrypoint MethodDesc resolution
- #135447 Fix NativeImageEagerFixups lock ordering
- #135437 [release/9.0-staging] Fix Duplicate ownership state machine under concurrency for NCrypt handles
- #135421 JIT: Fold unsigned constant range tests
- #135420 Reintroduce SmtpClient.SslOptions for TLS configuration
- #135419 Upgrade gh-aw to v0.89.21
- #135410 Clarify async validation XML documentation
- #135380 Optimize Wasm comparisons against zero
- #135305 [release/8.0] Update branding to 8.0.33
- #135303 [release/9.0] Update branding to 9.0.22
- #135302 Support
GetMethodwithgenericParameterCountin System.Reflection.Context - #135286 Fix Delegate.Method reflection cache pollution for private generic-base methods
- #135233 Remove support for
rollForwardOnNoCandidateFxandapplyPatches - #135140 [cDAC][wasm] Continue stack walks from a TransitionFrame into its R2R caller
- #135115 Emit pseudoattributes as metadata in managed ilasm
- #135073 Simplify metadata imports for single-module assemblies
- #134848 Package DiaSymReader native assets with ILLink
- #134623 Deduplicate identical Wasm method bodies
- #134167 Run some libraries tests in jitstress isas pipelines
- #133606 Populate RemoteIdentity SID claims from the Kerberos PAC on Unix
- #133263 Move runtime test build into product jobs
- #132347 Update guidelines for C++ standard library usage and build against libc++ w/ libstdc++ ABI for linux arm/arm64/x64
- #131502 docs: remove RuntimeFrameworkVersion dogfooding guidance now that we have VMR daily builds
#135536 [release/11.0] Clarify async validation XML documentation
- 作成者: @github-actions[bot]
- 作成日時: 2026年10月09日 19:09:15(UTC)
- マージ日時: 2026年10月09日 23:35:06(UTC)
- ラベル: Servicing-approved area-System.ComponentModel.DataAnnotations
概要
.NET 11 の新機能である非同期検証(async validation)に関する XML ドキュメントを明確化する PR #135410 の release/11.0 へのバックポートです。ドキュメントのみの変更で、ランタイムの挙動や API 形状への変更はありません。内部で発見された問題で、顧客報告ではなく、リグレッションでもありません。リスクは低いとされています。
変更内容
Microsoft.Extensions.Options.DataAnnotationsDataAnnotationValidateOptions.Async.cs:XML ドキュメントを 7 行追加OptionsBuilderDataAnnotationsExtensions.cs:ドキュメントを修正(+4/-3)
Microsoft.Extensions.OptionsIAsyncValidateOptions.cs:ドキュメントを 10 行追加OptionsBuilder.cs:ドキュメントを大幅に追加・修正(+114/-1)OptionsValidatorAttribute.cs:ドキュメントを修正(+7/-1)
System.ComponentModel.AnnotationsAsyncValidationAttribute.cs:ドキュメントを拡充(+33/-5)IAsyncValidatableObject.cs:ドキュメントを拡充・修正(+23/-8)Validator.cs:ドキュメントを拡充・修正(+25/-7)
パフォーマンスへの影響
影響なし(ドキュメントコメントのみの変更)。
関連Issue
- 元の PR:#135410(バックポート元)
その他
- 対象ブランチは
release/11.0で、github-actions[bot] による自動バックポートです。 - 提供された情報の範囲では、コード上の挙動変更や互換性への影響を示す記載はありません。
#135517 Pass CLR_CROSS_COMPONENTS_BUILD as a separate -cmakeargs
- 作成者: @pcshrosbree
- 作成日時: 2026年10月09日 16:16:02(UTC)
- マージ日時: 2026年10月09日 20:09:49(UTC)
- ラベル: area-Infrastructure community-contribution
概要
CLR_CROSS_COMPONENTS_BUILD フラグを、ユーザー指定の CMakeArgs に文字列連結する方式から、MSBuildプロパティ ClrCrossComponentsBuild=true を経由して runtime.proj が独立した -cmakeargs として渡す方式に変更します。
修正前は CMakeArgs=$(CMakeArgs) -DCLR_CROSS_COMPONENTS_BUILD=1 と連結されていたため、Windows(build-runtime.cmd)ではクォートされた値が1つのCMake引数として扱われ、-cmakeargs -DCLR_PROBE_NOOP=1 を指定すると CLR_PROBE_NOOP の値が 1 -DCLR_CROSS_COMPONENTS_BUILD=1 になり、CLR_CROSS_COMPONENTS_BUILD が定義されませんでした。Linuxでは build-commons.sh が eval で再解析するため問題は顕在化していませんでした。
変更内容
eng/Subsets.props: host cross-components build、linuxdac、alpinedacの3プロジェクトで、CMakeArgsへの追記をやめてClrCrossComponentsBuild=trueを設定(+3/-3)src/coreclr/runtime.proj:-cmakeargs "-DCLR_CROSS_COMPONENTS_BUILD=1"をFEATURE_INTERPRETER等の内部定義と同様に独立エントリとして渡す(+2/-0)Directory.Build.props:ClrCrossComponentsBuildをNativeBuildPartitionPropertiesToRemoveにCMakeArgsと並べて追加し、これが原因でruntime-prereqs.projやcdac-build-toolが再ビルドされないようにする(+1/-1)
補足:
- 新しいエントリはユーザーの
CMakeArgsより前に列挙されます。build-runtime.cmdとbuild-commons.shはいずれも各-cmakeargsを先頭に追加するため、CMakeコマンドライン上ではユーザー引数の後ろに来ます。その結果、ユーザーが-DCLR_CROSS_COMPONENTS_BUILD=0を指定しても上書きされません。 runtime.projでCMakeArgsをスペース分割する案も検討されましたが、スペースを含むCMake引数を壊すため採用されていません。
パフォーマンスへの影響
影響なし(ビルドシステムの引数受け渡しの修正であり、ランタイムの実行性能には関係しません)。
関連Issue
その他
ビルド結果とCMakeキャッシュによる検証が報告されています(MSBuildファイル用のテストハーネスはなし)。
- Windows x64 ホスト
build.cmd clr.runtime -a arm64 -c Debug -cmakeargs -DCLR_PROBE_NOOP=1: 修正前はfloatconversion.asmでエラー(A2008)となり、CMakeCache.txtにCLR_PROBE_NOOP:UNINITIALIZED=1 -DCLR_CROSS_COMPONENTS_BUILD=1という融合エントリが残る。修正後はビルド成功し、CLR_CROSS_COMPONENTS_BUILD=1とCLR_PROBE_NOOP=1が別エントリになる。build.cmd linuxdac -a x64 -c Debug -cmakeargs -DCLR_PROBE_NOOP=1: 修正前はCMake configureで失敗。修正後は linux-x64 のmscordaccoreとmscordbiがビルドされる。-cmakeargsなしのclr.runtimeもビルド成功。
- Linux x64(
./build.sh clr.crossarchtools -a arm64 -c Debug)- 複数の
-cmakeargs指定でも修正前後で同じキャッシュエントリになる。 -DCLR_CROSS_COMPONENTS_BUILD=0を指定してもCLR_CROSS_COMPONENTS_BUILD=1のままになる。
- 複数の
alpinedacはlinuxdacと同じ経路のため、個別にはビルドされていません。
#135480 Skip test135234 where working-set monitoring is unsupported
- 作成者: @radekdoulik
- 作成日時: 2026年10月09日 09:31:56(UTC)
- マージ日時: 2026年10月09日 12:07:43(UTC)
- ラベル: area-Infrastructure
概要
Process.GetCurrentProcess() が未サポートの Browser/WASI、および WorkingSet64 が PlatformNotSupportedException を投げる iOS/tvOS で、回帰テスト test135234 をスキップするようにしました。#135290 で追加された回帰テストにより発生していた Browser/Wasm インタプリタでの失敗を修正します。
Boolean の入力パターンとネイティブのワーキングセットリーク検証は変更されていません。Desktop、MacCatalyst、Android でのテストカバレッジは維持されます。プロジェクト設定の変更もありません。
変更内容
src/tests/Regressions/coreclr/GitHub_135234/test135234.cs(+2/-0)- 上記のサポート外プラットフォームでテストをスキップするための記述を追加(ワーキングセット監視が使えない環境でのスキップが目的)
パフォーマンスへの影響
影響なし(テストコードのみの変更でランタイムやライブラリの実装には触れていません)。
関連Issue
- #135290(失敗の原因となった回帰テストを追加した PR)
その他
- 検証内容:macOS、Browser、WASI、iOS、tvOS、両 Apple シミュレータ、MacCatalyst、Android のマネージドのみのターゲットビルドが成功。生成されたラッパーは、未サポート環境ではディスパッチを省略し、サポート環境では両方の入力を保持していることを確認。
- main-CI の macOS ランタイム上では、生成されたエントリポイントが 100 を返し、補足の xUnit XML は 2 件成功・0 件失敗・0 件スキップでした。
- Browser/WASI での実行確認は行われていません。
#135470 [cDAC] Test entry-point MethodDesc resolution
- 作成者: @pcshrosbree
- 作成日時: 2026年10月09日 06:34:33(UTC)
- マージ日時: 2026年10月09日 16:35:42(UTC)
- ラベル: community-contribution area-Diagnostics-cdac
概要
#135450 のフォローアップとして、cDAC(Contract Data Access Component)における entry-point から MethodDesc への解決処理に対するユニットテストを追加するPRです。vtableの各スロットは NonVirtualEntry2MethodDesc を経由して解決されますが、その非ポータブルなパスや、ValidateMethodDescPointer における temporary entry point のチェックにはテストカバレッジがありませんでした。このため、該当ロジックを壊してもテストが全て通る状態でした。本PRはテストのみの追加です。
変更内容
ExecutionManagerTests.cs(+91):NonVirtualEntry2MethodDescのテストを追加- jitted code の場合
FIXUPPRECODEのrange listの場合- range list上のアドレスだがprecodeではない場合(null)
- どのrange sectionにも属さないアドレスの場合(null、デコードされないこと)
MethodDescTests.cs(+122/-5)GetMethodDescForSlotによる、populatedなvtableスロットの解決テストValidateMethodDescPointerが temporary entry point から元のMethodDescへ解決できることを要求する点のテスト(portable × resolves-to-self の組み合わせ)
MockDescriptors.RuntimeTypeSystem.cs(+26): テスト用ヘルパーAddMethodTableWithVtableを追加
作成者によると、以下の12個の単一ガードのミューテーションがそれぞれ1つのテストメソッドで失敗するようになっています。
NonVirtualEntry2MethodDescの各分岐- slotパス
- 検証の両バリアント
- 検証の比較処理
ValidateForDataAccessのガード
UnitTests は linux-x64、osx-arm64、windows-x64 で 3324/3324 が成功しています。また osx-arm64 と windows-x64 では、precodeアドレスに対して NonVirtualEntry2MethodDesc がnullを返すミューテーションを再実行し、テストが失敗することを確認したとのことです。
パフォーマンスへの影響
影響なし(テストコードのみの変更)
関連Issue
#135450(フォローアップ元。PRとして言及されています)
その他
- 作成者によれば、本PRはAI(Anthropic Claude、OpenAI Codexによるレビュー)の支援を受けて作成され、テストとミューテーション実行はローカルで実施されたとのことです。
#135454 [release/8.0-staging] Fix Duplicate ownership state machine under concurrency for NCrypt handles
- 作成者: @bartonjs
- 作成日時: 2026年10月08日 22:49:35(UTC)
- マージ日時: 2026年10月09日 21:26:17(UTC)
- ラベル: Servicing-approved area-System.Security
概要
release/8.0-staging への #130804 のバックポート。NCrypt ハンドル(SafeNCryptKeyHandle 等)の「重複所有(Duplicate ownership)」状態機械が、複数スレッドが同じキーオブジェクトを初めて同時に使用した際のレース条件で不正な状態に入る問題を修正します。
不正な状態に入ると、ファイナライズ時に ObjectDisposedException が発生し、最悪の場合プロセスが異常終了します(CI で assert により検出された #130760 と同一の問題と報告されています)。
修正は、レースの影響を受けるコードを lock で囲むという単純なものです。最初の使用が完了した後の並列アクセスは、もともとこのレースの影響を受けません。
変更内容
src/libraries/System.Security.Cryptography/src/Microsoft/Win32/SafeHandles/NCryptSafeHandles.cs(+22/-11): レースの影響を受ける箇所にロックを追加src/libraries/System.Security.Cryptography.Cng/tests/CngKeyTests.cs(+60/-0): 積極的に並列化したテストを追加
影響範囲は System.Security.Cryptography ライブラリ内部のハンドル管理の実装であり、公開 API の変更はありません。
パフォーマンスへの影響
影響なし(ベンチマーク結果の記載なし)。ロックの追加による影響については、PR 情報には言及がありません。
関連Issue
その他
- 顧客からの報告および社内での発見の両方があります。
- リグレッションではありません(ロジックは .NET Core 1.0 以降変更されていません)。
- リスクは低いと評価されています(単純なロック追加のため)。
#135452 Wait for EE startup before finalizer managed execution
- 作成者: @davidwrighton
- 作成日時: 2026年10月08日 22:34:43(UTC)
- マージ日時: 2026年10月09日 01:08:56(UTC)
- ラベル: area-VM-coreclr
概要
専用ファイナライザースレッドが、マネージドのワーカーに入る前にEE(実行エンジン)の起動完了を待つように変更します。CoreLibの有効化は起動完了の十分な同期点ではなく、その後に共有静的変数やスレッド静的変数の基盤が初期化されます。その間にファイナライザースレッドが動作し得ます。GC.RunFinalizers はファイナライズ対象を確認する前に Thread.CurrentThread にアクセスするため、起動途中で競合が発生し得ました。
修正後は、HasStarted() とバックグラウンドスレッド登録の後に、プリエンプティブGCモードで EnsureEEStarted() を呼び出します。EE起動はスタートアップロックを保持したままファイナライザースレッドを作成するため、この呼び出しは新たなロードを開始せず、既存の初期化の完了を待ちます。起動が利用不可または失敗している場合は、HRESULTをログに記録し、マネージド実行をスキップして、ファイナライザーのシャットダウン完了を通知します。
変更内容
src/coreclr/vm/finalizerthread.cpp(+28/-13)- ファイナライザースレッドが
HasStarted()とバックグラウンドスレッド登録の後、プリエンプティブGCモードでEnsureEEStarted()を呼び、EE起動完了を待機するようにしました。 - 起動が利用不可または失敗の場合は、HRESULTを記録してマネージド実行をスキップし、ファイナライザーのシャットダウン完了を通知します。
- 早期のWindows COM/FLSハンドシェイクとデバッガーヘルパースレッドは変更していません。
- ファイナライザースレッドが
パフォーマンスへの影響
影響なし(ベンチマーク結果の記載なし)。ファイナライザースレッドの起動時に、EE起動完了までの待機が1回追加されます。
関連Issue
#135448(Resolves)
その他
- Windows ICorDebug検証(Windows 11 x64、Checked CoreCLR、Release libraries、Debug host、ReadyToRun CoreLib):
- 修正なし: GCStress=0x3 のICorDebug起動で、10回中9回が
Main到達前に失敗しました。 - 修正あり: 同条件で30/30回が
MainとDebugger.Breakに到達し、起動ランチャーは終了コード0で、コントラクトのアサーションは発生しませんでした。 - 修正なしの失敗は、Checkedビルドのネイティブアサーションでした。
CrstBase::EnterがGC_NOTRIGGER + MODE_COOPERATIVE領域でのロック取得を拒否したもので、Issueに記載のマネージド例外0x80131506は再現していません。
- 修正なし: GCStress=0x3 のICorDebug起動で、10回中9回が
- Linux x64 検証(Checked CoreCLR):
GC/API/GCの3テスト(Finalize、ReRegisterForFinalize、SuppressFinalize)を GCStress 0 と 0x3 で各10回、計60回実行し、すべて戻り値100で成功しました。CoreLibを意図的に除いた起動失敗ケースでは、EnsureEEStarted()の失敗によりファイナライザーがマネージド実行をスキップすることを確認しました。Linuxのマネージドテストは、スモークテスト相当の位置付けです。 - スコープと制限: 以前の起動順序でも、TLS準備前にファイナライザーが実行され得ました。原因となったコミットが、既存の競合を顕在化させた可能性があります。
ThreadSuspend::SuspendEEのデバッガーリトライ経路は変更しておらず、別途報告されている起動スレッドのCatchAtSafePointGCモードのコントラクト違反の解消も主張していません。
#135450 Consolidate cDAC entrypoint MethodDesc resolution
- 作成者: @rcj1
- 作成日時: 2026年10月08日 22:17:57(UTC)
- マージ日時: 2026年10月09日 04:51:14(UTC)
- ラベル: area-Diagnostics-cdac
概要
cDAC(Contract Data Descriptor Reader)におけるエントリポイントから MethodDesc を解決する処理を統合するリファクタリングです。RuntimeTypeSystem コントラクトが ExecutionManager.NonVirtualEntry2MethodDesc を経由して MethodDesc を解決するよう変更し、portable 専用だった PrecodeStubs コントラクト(PrecodeStubs_2)を削除しています。
変更内容
RuntimeTypeSystem_1.cs:エントリポイントからの MethodDesc 解決をExecutionManager.NonVirtualEntry2MethodDesc経由に変更(+1/-18)PrecodeStubs_2.cs:portable 専用のPrecodeStubs実装を削除(-22)CoreCLRContracts.cs:コントラクト登録の更新(+8/-5)MethodValidation.cs:MethodDesc 検証処理の調整(+3/-2)datadescriptor.inc:データディスクリプタの定義を整理(+1/-3)- 設計ドキュメント(
PrecodeStubs.md、RuntimeTypeSystem.md)を上記変更に合わせて更新 - ユニットテスト(
TargetTests.cs、ExecutionManagerTests.cs、MethodDescTests.cs、PrecodeStubsTests.cs)を更新。ExecutionManagerTestsには新規テストが追加され、PrecodeStubsTestsからは portable 向けのテストが削除されています。
パフォーマンスへの影響
影響なし(記載された情報の範囲では、パフォーマンスに関する言及やベンチマーク結果はありません)。
関連Issue
なし
その他
- 診断用 cDAC 内部の実装整理であり、公開 API への影響は提供情報からは確認できません。
- 作成者による説明は簡潔で、互換性や破壊的変更に関する記載はありません。
#135447 Fix NativeImageEagerFixups lock ordering
- 作成者: @davidwrighton
- 作成日時: 2026年10月08日 20:50:01(UTC)
- マージ日時: 2026年10月09日 18:44:23(UTC)
- ラベル: area-VM-coreclr
概要
R2R(ReadyToRun)コンポジットのテスト経路で、CrstNativeImageEagerFixups を保持したまま CrstAppDomainCache を取得するケースがありました。この依存関係が CrstTypes.def に記述されていなかったため、Checked ビルドで CRST(Critical Section)のレベル違反が報告されていました。
CrstNativeImageEagerFixups を CrstAppDomainCache および CrstGlobalStrLiteralMap より前に取得されるロックとして宣言し、crsttypes_generated.h を再生成することで、ロック順序の不整合を解消しています。
変更内容
src/coreclr/inc/CrstTypes.def(+2/-1):CrstNativeImageEagerFixupsがCrstAppDomainCacheとCrstGlobalStrLiteralMapより前に取得される旨の依存関係を追加src/coreclr/inc/crsttypes_generated.h(+1/-1): 上記定義から再生成。生成されるCrstNativeImageEagerFixupsのレベルが 8 から 17 に変更
影響範囲はランタイム(CoreCLR)内部のロック順序定義であり、公開 API の変更や互換性への影響はありません。
パフォーマンスへの影響
影響なし
関連Issue
その他
作成者によるテスト結果は以下の通りです。
CrstTypeToolの実行: 成功./build.sh clr -rc checked -hc checked: 成功src/tests/build.sh checked/src/tests/run.sh checked: 成功(4,996 件中 4,753 件成功、0 件失敗、243 件スキップ)RunCrossGen2=1、CompositeBuildMode=1、LargeVersionBubble=1を指定したjit64_3: Crossgen2 コンパイル、R2RDump 検証、実行まで成功
なお、本 PR は GitHub Copilot の支援を受けて作成されたと記載されています。
#135437 [release/9.0-staging] Fix Duplicate ownership state machine under concurrency for NCrypt handles
- 作成者: @github-actions[bot]
- 作成日時: 2026年10月08日 17:04:22(UTC)
- マージ日時: 2026年10月09日 16:53:00(UTC)
- ラベル: Servicing-approved area-System.Security
概要
release/9.0-staging へのバックポート(元PR: #130804)です。NCrypt系ハンドル(SafeNCryptKeyHandle など)の「所有権状態マシン(duplicate ownership)」が、複数スレッドが同時に初めてキーオブジェクトを使用した際の競合状態により不正な状態に入る問題を修正します。
- 不正な状態は CI 中の assert で検出されました(#130760)。
- 顧客からも、ファイナライズ中に
ObjectDisposedExceptionが発生しプロセスが終了するという報告があり、同じ問題とみられます。 - 競合は「2つのスレッドが同時にキーオブジェクトを初めて使用する」場合のみ発生し、初回使用完了後の並列アクセスは影響を受けません。
- ロジック自体は .NET Core 1.0 から変更されておらず、リグレッションではありません。
- リスクは低いと説明されています(競合しうるコードに単純な lock を追加するのみ)。
変更内容
src/libraries/System.Security.Cryptography/src/Microsoft/Win32/SafeHandles/NCryptSafeHandles.cs(+22/-11)- 競合が起こりうる所有権状態の処理を lock で保護するよう変更。
src/libraries/System.Security.Cryptography/tests/CngKeyTests.cs(+60/-0)- 積極的に並列化したテストを追加。
パフォーマンスへの影響
影響なし(PR情報にベンチマークの記載はありません。lock の追加による影響についての記述もありません)。
関連Issue
その他
- 顧客報告あり/社内でも発見された問題です。
- レビュー対象としてメンションされているのは @bartonjs と @vcsjones です。
#135421 JIT: Fold unsigned constant range tests
- 作成者: @EgorBo
- 作成日時: 2026年10月08日 12:46:22(UTC)
- マージ日時: 2026年10月09日 18:03:51(UTC)
- ラベル: area-CodeGen-coreclr
概要
JITのoptOptimizeBoolsにおける定数範囲テストの畳み込み(range folding)を、符号なし(unsigned)比較にも拡張するPRです。これにより、n is >= '0' and <= '9' のようなパターンが、2回の比較・分岐ではなく「減算+1回の比較」に変換されます。Closes #135418。
bool Pattern() => n is >= '0' and <= '9';
x64のコード生成は以下のように変化します(作成者提示)。
- mov ecx, dword ptr [rcx+0x08]
- cmp ecx, 48
- jae SHORT G_M53568_IG05
- xor eax, eax
- ret
-G_M53568_IG05:
- cmp ecx, 57
+ mov eax, dword ptr [rcx+0x08]
+ sub eax, 48
+ cmp eax, 9
setbe al
movzx rax, al
ret
-; Total bytes of code: 21
+; Total bytes of code: 16
変更内容
src/coreclr/jit/optimizebools.cpp(+6/-6)optOptimizeBoolsで符号なしの定数範囲テストを畳み込み対象として有効化- 畳み込みの際に、比較の符号性(signedness)が一致していることを要求するガードを追加
- 符号付きのみを対象としていた「非負値フォールバック」は維持
影響範囲はランタイムのJITコンパイラ内部の最適化で、公開APIの変更や互換性への影響(破壊的変更・非推奨化)は記載されていません。
パフォーマンスへの影響
- 上記の例でコードサイズが21バイトから16バイトに減少
- 条件分岐が1つ減り、比較が1回で済む形になる
- ベンチマーク結果の数値は提供されていません
関連Issue
その他
- Copilotのレビューでは、新たに有効化された符号なし変換に対するターゲットを絞った回帰テストが不足している点が中程度の指摘として挙げられています(総合判定は「Changes recommended」)。
- Copilotは、このレビュー時にビルドとランタイムテストが実行されていないと記載しています。
#135420 Reintroduce SmtpClient.SslOptions for TLS configuration
- 作成者: @rzikm
- 作成日時: 2026年10月08日 12:35:03(UTC)
- マージ日時: 2026年10月09日 07:12:00(UTC)
- ラベル: area-System.Net
概要
SmtpClient に TLS 設定用の SslOptions プロパティを再導入する変更です。#134919 の機能を、CI を大きく壊したため revert した #135370 の後に復活させるものです。
元 PR のマージ後のテスト失敗は、#133174 の並行する変更が原因でした(元 PR の CI を再実行せずに main に取り込まれたため)。本 PR では、証明書検証コールバックに依存するテストで TLS セッション再開(resumption)を無効化し、コールバックが確実に実行されるよう修正しています。
変更内容
- 公開 API
System.Net.Mail/ref/System.Net.Mail.cs(+1):参照アセンブリに追加(プロパティ名はSmtpClient.SslOptions)ref/System.Net.Mail.csproj(+1)、src/System.Net.Mail.csproj(+2):プロジェクト参照/構成の更新
- 実装
SmtpClient.cs(+36/-3):SslOptions関連の実装SmtpClient.Wasm.cs(+8):Wasm 向けの実装SmtpTransport.cs(+15/-3):SslOptions を接続側へ受け渡す変更SmtpConnection.cs(+6/-43):TLS 関連処理の大幅な削減(SslOptions 経由に整理されたとみられますが、詳細は提供情報からは不明)
- テスト
LoopbackSmtpServer.cs(+4)SmtpClientTest.cs(+110)SmtpClientTlsTest.cs(+175/-31):TLS 再開を無効化して証明書検証コールバックが実行されるよう修正
パフォーマンスへの影響
影響なし(ベンチマーク結果の記載なし)。
関連Issue
その他
- 公開 API(
SmtpClient.SslOptions)の追加を含みます。 - 提供情報にはプロパティの型や詳細な挙動の記載がないため、それらについては記述していません。
#135419 Upgrade gh-aw to v0.89.21
- 作成者: @vitek-karas
- 作成日時: 2026年10月08日 12:25:10(UTC)
- マージ日時: 2026年10月09日 09:54:47(UTC)
- ラベル: area-skills
概要
GitHub Agentic Workflows (gh-aw) を v0.86.2 から v0.89.21 へアップグレードし、6つのagenticワークフローのlockファイルとaction/containerキャッシュを再生成するPRです。リポジトリ固有のバージョン上書きは廃止し、gh-aw既定の依存バージョンを採用しています。MCP Gatewayおよび holistic-review のCLI proxyは v0.4.9 から v0.4.25 に更新されています。
変更内容
- ワークフロー本体(6本):
breaking-change-doc/ci-failure-fix/ci-failure-scan/ci-failure-scan-feedback/closed-issue-reference-check/holistic-reviewの.lock.ymlを再生成。トリガー、スケジュール、ジョブ権限、共有import、出力上限は維持。 breaking-change-doc.md: 新コンパイラの検証に対応するため、ベースリポジトリのcheckoutを明示的に宣言(リポジトリのskillsは引き続き利用可能)。ci-failure-scan.md/ci-failure-scan-feedback.md: 手書きのGPT-6.1価格オーバーレイを削除。ランタイムが起動時にCopilotのモデルカタログから価格を取得するため。gpt-6.1-sol、2,500クレジット上限、既存のResponsesルーティングは維持。holistic-review.md: 軽微な修正(+2/-2)。.github/aw/actions-lock.json: コンパイラ生成のimmutableなaction/container参照を更新。.github/agents/agentic-workflows.agent.md: 対応する上流のオーサリングドキュメントを参照するよう更新。validate-pat-pool.yml: setup actionを v0.89.21 に更新(CLIバージョンは据え置き)。.github/skills/vectorization/SKILL.md: skill validatorが説明文中の<T>をXML風タグとして拒否するため、Vector<T>を "the generic Vector type" に変更(技術的内容・例は不変)。.github/workflows/evals/:README.mdとkbe-search.test.mjsを軽微に更新。
パフォーマンスへの影響
影響なし(CI/ワークフロー基盤の変更でありランタイム/ライブラリのコードは未変更)。
関連Issue
なし
その他
- 検証結果:
gh aw compile --strict --validate --validate-imagesが6ワークフローすべてで成功。再生成してもlockファイル・pinキャッシュに差分なし。- MCP Gatewayイメージ v0.4.25 の起動確認(
--version)に成功。 - AWF v0.28.23 / gh-aw v0.89.21 に対するオフラインのスモークテストが成功。ただしライブのCopilotカタログへの問い合わせや推論は未実施。
actionlintは既存の40件の診断が残るものの、元のlockファイルと比較して新規の診断はなし。skill-validatorは23 skills / 3 agents すべて成功。Skill Validation CIも成功。
- 実際のagenticワークフローのライブ実行は行われていません。
- 作成にはGitHub Copilotが使用されています。
#135410 Clarify async validation XML documentation
- 作成者: @ViveliDuCh
- 作成日時: 2026年10月08日 06:27:25(UTC)
- マージ日時: 2026年10月09日 19:05:16(UTC)
- ラベル: area-System.ComponentModel.DataAnnotations
概要
非同期のDataAnnotations検証と、非同期のMicrosoft.Extensions.Optionsバリデータに関するXMLドキュメントコメントを明確化・拡充する、ドキュメントのみの変更です。ランタイムの動作やAPIシグネチャの変更は含まれません。
同期フォールバック、ディスパッチ、キャンセル、例外、並行性に関するガイダンスを追記し、DataAnnotationsからOptionsへのブリッジおよびOptionsバリデーションのソースジェネレーターのコメントも補完しています。
DataAnnotations側の更新は dotnet/dotnet-api-docs#13101 と整合しています。Microsoft.Extensions.Options側のコメントはソース管理で、通常のAPIリファレンスのインポート処理で反映されます。
変更内容
- System.ComponentModel.Annotations
AsyncValidationAttribute.cs: 同期フォールバック等に関するドキュメントを拡充(+33/-5)IAsyncValidatableObject.cs: ガイダンスの明確化(+23/-8)Validator.cs: 非同期検証に関するコメントの更新(+25/-7)
- Microsoft.Extensions.Options
OptionsBuilder.cs: 非同期Optionsバリデータの登録、ディスパッチ、起動時検証、同期アクセス時の挙動に関するドキュメントを大幅に追記(+114/-1)IAsyncValidateOptions.cs: ドキュメント追記(+10/-0)OptionsValidatorAttribute.cs: ソースジェネレーター関連のコメントを補完(+7/-1)
- Microsoft.Extensions.Options.DataAnnotations
DataAnnotationValidateOptions.Async.cs: ドキュメント追記(+7/-0)OptionsBuilderDataAnnotationsExtensions.cs: コメントの更新(+4/-3)
パフォーマンスへの影響
影響なし(ドキュメントコメントのみの変更)。
関連Issue
#131498(関連) dotnet/dotnet-api-docs#13101(ドキュメント整合の対象PR)
その他
- テスト結果(作者記載):
System.ComponentModel.Annotations.Tests(1,008件)合格、Microsoft.Extensions.Options.Testsは両ターゲット実行で合格、Optionsのソース生成テストおよびソース生成ユニットテストも合格(1件は条件付きでスキップ)。
#135380 Optimize Wasm comparisons against zero
- 作成者: @davidwrighton
- 作成日時: 2026年10月07日 23:58:30(UTC)
- マージ日時: 2026年10月09日 18:45:48(UTC)
- ラベル: area-CodeGen-coreclr
概要
Wasm向けJITで、整数の等価/非等価比較においてゼロとの比較を最適化するPRです。ゼロ定数オペランドをcontainedにし、「ゼロ定数 + 汎用の等価命令」の代わりに i32.eqz / i64.eqz を直接出力します。また、結果が br_if に直接渡される場合の冗長な i32 != 0 正規化を削除します。
比較結果は引き続き0または1に正規化されます。そのため非等価の値は eqz を2回使う形になり、条件に合致する i32 != 0 の分岐のみ元の値を br_if が直接消費します。この直接消費は i32 に限定され、i64 はWasmの分岐条件が i32 を要求するため i64.eqz を引き続き使用します。
変更内容
src/coreclr/jit/codegenwasm.cpp(+36/-1): ゼロとの等価/非等価比較に対してi32.eqz/i64.eqzを出力するコード生成の追加。条件を満たすi32 != 0の分岐で正規化を省略しbr_ifへ直接渡す処理。src/coreclr/jit/lowerwasm.cpp(+15/-2): 整数のゼロオペランドをcontainedにするLowering処理。
生成コードの変化(Crossgen2での確認結果):
int == 0→i32.eqzint != 0(値として使用)→i32.eqz; i32.eqzlong == 0→i64.eqzlong != 0(値として使用)→i64.eqz; i32.eqz- 条件を満たす
i32 != 0の分岐 →br_ifに直接渡す i64の分岐 →i64.eqzを維持- null比較 →
i32.eqz - 大小比較(ordered comparison)は変更なし
パフォーマンスへの影響
主な効果はコードサイズの削減です。ブラウザ/Wasm Releaseビルドの System.Private.CoreLib.wasm での結果:
| 指標 | ベースライン | 更新後 | 差分 |
|---|---|---|---|
| 生サイズ | 26,040,664 bytes | 25,935,080 bytes | -105,584 bytes (-0.4055%) |
| Brotli q11 | — | — | 約 -3.5〜-3.9 KB |
生サイズの削減はすべてCODEセクションで発生しています。個別の例:
System.TimeZoneInfo.CacheTransitionsForYear: ゼロ定数との等価シーケンス48箇所をすべて除去し、命令バイトを105削減System.SpanHelpers.IndexOfAny_0<System.__Canon>: 同49箇所を除去し、命令バイトを112削減
実行速度に関する計測結果は提示されていません。
関連Issue
#135379(本PRで解決)
その他
- 検証として以下のビルドが成功したと記載されています:
clr.wasmjit(Checked)、clr.tools+clr.wasmjit(Checked)、clr.crossarchtools(browser, Release)、clr.corelib+clr.nativecorelib(browser, Release)。JITのフォーマット確認とgit diff --checkも成功しています。 - 本PRはGitHub Copilotを用いて作成されたと記載されています。
#135305 [release/8.0] Update branding to 8.0.33
- 作成者: @dotnet-release-bot[bot]
- 作成日時: 2026年10月06日 19:33:32(UTC)
- マージ日時: 2026年10月09日 16:28:08(UTC)
- ラベル: Servicing-approved community-contribution area-codeflow branding-update
概要
release/8.0 ブランチのバージョンブランディングを更新するPRです。パッチバージョンを 32 から 33 に変更し、8.0.33 としています。リリースボットによる自動生成PRです。
変更内容
eng/Versions.props(+3 / -4)- PatchVersion を
32→33に更新 - 提供された情報では、上記以外の差分(追加3行・削除4行の詳細)は不明です
- PatchVersion を
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
- 変更はバージョン番号のブランディング更新のみで、ランタイム/コンパイラ/ライブラリの動作や公開API、互換性への影響は提供情報からは確認できません。
- セキュリティ修正やバグ修正に関する記載はありません。
#135303 [release/9.0] Update branding to 9.0.22
- 作成者: @dotnet-release-bot[bot]
- 作成日時: 2026年10月06日 19:20:05(UTC)
- マージ日時: 2026年10月09日 16:27:58(UTC)
- ラベル: Servicing-approved community-contribution area-codeflow branding-update
概要
release/9.0 ブランチのバージョンブランディングを更新するPRです。パッチバージョンを 21 から 22 に変更し、9.0.22 向けの設定に更新します。
変更内容
eng/Versions.props(+3/-4)PatchVersionを21→22に更新- 提供された情報には、その他の差分の詳細は含まれていません
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
- 作成者は
dotnet-release-bot[bot]で、リリースブランチのバージョン更新を行う自動PRです。 - 公開APIや内部実装の変更、互換性への影響、セキュリティ修正に関する情報は提供されていません。
#135302 Support GetMethod with genericParameterCount in System.Reflection.Context
- 作成者: @caraioniurie47
- 作成日時: 2026年10月06日 18:56:45(UTC)
- マージ日時: 2026年10月09日 00:07:02(UTC)
- ラベル: area-System.Reflection linkable-framework community-contribution
概要
CustomReflectionContext でマップされた型に対する Type.GetMethod の genericParameterCount を受け取るオーバーロードが、GetMethodImpl(string, int, ...) の未実装により NotSupportedException を投げる問題を修正します。GetMethodImpl を(個数なしで)オーバーライドしていた3つの型クラスに、このオーバーロードのオーバーライドを追加しています。
変更内容
DelegatingType.cs: ラップ対象の型のGetMethod(name, genericParameterCount, ...)へ転送。ProjectingType.cs: パラメーター型を unproject し、結果を project して返す。CustomType.cs: コンテキストが追加するプロパティのアクセサーを追加。個数なしのオーバーロードとコードを共有。アクセサーはジェネリックではないため、個数 0 の場合のみ追加。ILLink.Suppressions.xml: 12行追加(内容の詳細は提供情報に記載なし)。ExtendedTypeTests.cs: 射影されたジェネリック/非ジェネリックメソッド(個数 0, 1, 2)と、基底型・派生型で追加された getter/setter(個数 0, 1)のテストを追加。これらは変更なしでは失敗する。- setter のテストは
ActiveIssuedotnet/runtime#135298 により Mono で無効化(Mono のDefaultBinderが非ランタイムのMethodInfoサブクラスに対してNotImplementedExceptionを投げるため)。同 Issue で提案されている修正を適用すれば Mono でも通過。
- setter のテストは
パフォーマンスへの影響
影響なし
関連Issue
その他
- 作成者によると、テストはローカルの Windows x64 の
mainビルド(CoreCLR Checked, Debug libraries)で実施。関連変更をマージした状態で NativeAOT および browser-wasm (V8) でも通過し、Mono 修正適用+ActiveIssue除去の状態で Mono (JIT) でも通過したとのことです。 - 作成者の記載によれば、本PRの説明は AI により生成され、作成者がレビューしています。
#135286 Fix Delegate.Method reflection cache pollution for private generic-base methods
- 作成者: @Copilot
- 作成日時: 2026年10月06日 16:39:21(UTC)
- マージ日時: 2026年10月09日 00:50:48(UTC)
- ラベル: area-System.Reflection
概要
Delegate.Method を、ジェネリック基底クラスの private メソッドを指すオープンデリゲート(open delegate)に対して読み取ると、Checked CoreCLR では assert が発生し、Release では派生型のリフレクションキャッシュ経由でそのメソッドが露出してしまう問題の修正です。
修正後は、デリゲートの第1引数に由来する派生型ではなく、そのメソッドが属する正確なジェネリック基底のインスタンス化に対してメソッドを解決します。
変更内容
src/coreclr/System.Private.CoreLib/src/System/Delegate.CoreCLR.cs(+29/-31)Delegate.Methodのメソッド解決ロジックを変更し、メソッドを正確なジェネリック基底のインスタンス化に対して解決するようにしました。
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DelegateTests.cs(+39/-0)- リグレッションテストを追加しました。
- メソッドの reflected type が正しいことを検証します。
- 派生型のメソッド一覧(リフレクションキャッシュ)が変化しないことを検証します。
影響範囲は CoreCLR 固有の Delegate 実装(CoreLib 内部)で、公開 API の変更はありません。
パフォーマンスへの影響
影響なし(ベンチマーク結果の記載はありません)
関連Issue
その他
なし
#135233 Remove support for rollForwardOnNoCandidateFx and applyPatches
- 作成者: @elinor-fung
- 作成日時: 2026年10月05日 18:53:55(UTC)
- マージ日時: 2026年10月09日 19:27:13(UTC)
- ラベル: breaking-change area-Host
概要
従来の framework 解決設定である rollForwardOnNoCandidateFx と applyPatches のサポートを削除します。あわせて、roll-forward の優先順位処理を「最も優先度の高い設定を先にチェックする」方式に単純化しました(従来は最も低い優先度の設定から始めて、より高い設定で上書きしていく方式)。
Resolves #131611。
変更内容
- ドキュメント
docs/design/features/framework-version-resolution.md: 当該設定に関する記述を削減(+18/-54)。docs/design/features/host-component-dependencies-resolution.md、docs/design/features/host-error-codes.md: 軽微な修正。docs/design/features/roll-forward-on-no-candidate-fx.md、docs/design/features/sharedfx-lookup.md: 各 +5 行の追記。
- ネイティブホスト (
src/native/corehost)fx_definition.cpp/.h、fx_reference.cpp/.h:fx_reference関連の設定・処理を削除(fx_reference.cppは +1/-18、fx_reference.hは +1/-14)。fxr/command_line.cpp/.h: 関連するコマンドライン処理を削除。fxr/files.cmake: 2 行削除。fxr/fx_muxer.cpp: roll-forward 優先順位の判定ロジックを整理(+15/-43)。
- テスト (
src/installer/tests)- 削除:
ApplyPatchesSettings.cs、RollForwardOnNoCandidateFx.cs、RollForwardOnNoCandidateFxMultipleFrameworks.cs、RollForwardOnNoCandidateFxSettings.cs、RollForwardAndRollForwardOnNoCandidateFxSettings.cs。 - 修正:
FrameworkResolutionBase.Settings.cs、FxVersionCLI.cs、RollForwardPreReleaseOnly.cs、RollForwardReleaseAndPreRelease.cs、RollForwardReleaseOnly.cs、RollForwardSettings.cs(+16)、IncludedFrameworksSettings.cs、HostContext.cs、FrameworkResolutionCommandResultExtensions.cs。 TestUtils/Constants.cs、TestUtils/RuntimeConfig.csから関連する定義・ヘルパーを削除。
- 削除:
- その他
src/libraries/System.Net.Http/tests/StressTests/HttpStress/load-corefx-testhost.ps1: 1 行修正。- ほか 12 ファイルが変更対象(詳細は提供情報になし)。
パフォーマンスへの影響
影響なし
関連Issue
その他
- 互換性: レガシー設定のサポート削除であり、これらの設定に依存する構成には影響する可能性があります。ただし、具体的な破壊的変更の扱い(警告・エラーなど)は提供情報からは確認できません。
- 変更の大半はテストコードの削除(
rollForwardOnNoCandidateFx関連テストだけで約 1,600 行超)です。
#135140 [cDAC][wasm] Continue stack walks from a TransitionFrame into its R2R caller
- 作成者: @lewing
- 作成日時: 2026年10月02日 22:55:34(UTC)
- マージ日時: 2026年10月09日 13:57:05(UTC)
- ラベル: area-Diagnostics-cdac
概要
WASM上でcDACのIStackWalkが、R2Rコードがトランジションヘルパー(例: WasmR2RToInterpreterThunk → ExecuteInterpretedMethodWithArgs_PortableEntryPoint)経由でインタプリタに入った場合に、InterpreterFrameから次の明示的Frameまでの間のR2Rフレームを取りこぼす問題を修正します。ヘルパーはTransitionBlock.m_StackPointerにR2R呼び出し元のリニアスタックポインタを記録し、m_ReturnAddressを0のままにすることがありますが、cDACはこれを扱えず、生の戻りアドレス(0)とTransitionBlock末尾を使っていたため、エラーなくフレームが欠落していました。ネイティブ側(GetWasmVirtualIPFromStackPointer、TransitionFrame::GetSP等)と同じ挙動に揃え、TransitionFrameからR2R呼び出し元へスタックウォークを継続します。
変更内容
datadescriptor.inc/data-descriptor-meanings.json/TransitionBlock.cs:TARGET_WASMでTransitionBlock.StackPointer(オプションのフィールド)を記述・公開。FrameHelpers.GetTransitionBlockReturnAddress: 戻りアドレスが0でStackPointerが設定されている場合、WasmUnwinder.GetVirtualIPでR2Rの仮想IPを導出。GetReturnAddressが全TransitionFrame型でこれを使用。WasmFrameHandler.HandleTransitionFrame:StackPointerと戻りアドレスがある場合、呼び出し元のSPをStackPointer、FPをその位置のWASM論理フレームポインタにする。それ以外はSP=TransitionBlock末尾、FP=null。InterpreterFrame配下のインタプリタチェーンが尽きた場合(InterpreterVirtualUnwind→ApplyInterpreterFrameTransition)も同じ経路を通る。WasmContext.Unwind: ネイティブのWasmUnwindStackFrameと同様に、各呼び出し元のスタックポインタからフレームポインタを再計算(従来は最初以降のR2R呼び出し元が直前フレームのFPを引き継いでいた)。- 関数(funclet)対応の論理フレームポインタ(ネイティブ
GetWasmFramePointerFromStackPointerに対応、#133890から流用):IWasmR2RInfo.TryIsFunclet:RUNTIME_FUNCTIONのfuncletビットを読む(WasmFunctionTableIndexLookup.cs、WasmR2RInfo.cs)。WasmUnwinder.TryGetLogicalFramePointer: 通常メソッドは自身のフレームベースを返し、funcletは確立元フレーム(親メソッド/funclet、またはCallFuncletWith[out]Throwable経由の場合はTERMINATE_R2R_STACK_WALKマーカー横に保存されたFP)まで遡る。WasmContext.Unwindと、R2Rのシード2経路(InlinedCallFrameマーカーとHandleTransitionFrame)で使用。
StackWalk.mdのTransitionFrameの節を更新。生成テーブルを再生成。
パフォーマンスへの影響
影響なし(ベンチマークの記載なし)。デバッグ/診断用のスタックウォーク処理の変更です。
関連Issue
#135137(本PRで解決)。 関連: #133890(重複する修正と論理フレームポインタを含み、リベース時に該当部分を削除予定)、#134608(funclet配置が変わる可能性)、#135147(funclet内部からウォークを開始する場合、リーフFPがフレームベースから取られる件)。
その他
- 検証: cDACユニットテスト3266/3266成功、
generate-docs.ps1 -Check成功、./build.sh -os browser -c Debug -subset clr.runtime成功(TransitionBlockはReturnAddress@0、StackPointer@4、サイズ8)。 - 新規テスト:
UpdateContextFromFrame_WasmTransitionFrame_MirrorsNativeTransitionBlock(戻りアドレス/スタックポインタの有無の4ケース)、CreateStackWalk_WasmInterpreterFrameEnteredFromR2R_ContinuesIntoR2RCaller、WasmUnwinderTests.Unwind_ProducerLayout_*(6ケース)、UpdateContextFromFrame_WasmFuncletCaller_ReportsEstablishingFramePointer。各テストは対応する修正を外すと失敗することを確認済み。 - ブラウザWASMでの実機検証(Blazor-Playground/nesm): 欠落していたR2R CoreLibフレーム8個が正しい順序で復元され、
NativeMarker ip=0が消えることを確認。funcletシナリオでも全ウォークが完了。 - 未対応: 呼び出しを行わないリーフfuncletにはフレームレコードがなく、ネイティブ/cDACともにウォーク不可。
- Copilotレビュー指摘(中程度、未解決): funcletや後続のR2R呼び出し元でFPの復元が不正確になる可能性(
#135115 Emit pseudoattributes as metadata in managed ilasm
- 作成者: @jkoritzinsky
- 作成日時: 2026年10月02日 18:06:32(UTC)
- マージ日時: 2026年10月09日 18:51:33(UTC)
- ラベル: area-ILTools-coreclr
概要
マネージド版 ilasm(src/tools/ilasm)に、ネイティブ版 ilasm が持つ「擬似カスタム属性(pseudoattributes)」のサポートを移植する PR です。一部の属性は通常のカスタム属性としてではなく、メタデータとして直接出力される必要があります。本 PR では該当する属性をデコード・検証し、対応するメタデータのフラグ、レイアウト、インポート情報、マーシャリング記述子として出力します。
変更内容
- 擬似属性の処理基盤(新規):
PseudoCustomAttributes.cs(lowering の調整と診断)、.Decoding.cs(属性 blob のデコード)、.Identity.cs(属性・対象の解決)、.KnownAttributes.cs(認識対象の属性定義)、.Application.cs(メタデータへの反映)、.MarshalAs.cs(マーシャリング記述子の構築)を追加。 - 文法アクション側の変更:
GrammarActions.BuildImage.cs: イメージ出力前に lowering を実行。GrammarActions.CustomAttributes.Actions.cs/GrammarActions.Manifest.Typedefs.cs: 属性のソース位置を保持。GrammarActions.Members.Class.cs: 明示的なクラスレイアウトを追跡。GrammarActions.Members.Fields.cs: フィールド関連の小変更。
- 基盤コード:
EntityRegistry.cs(エンティティの変更と属性の除去に対応)、Diagnostic.cs(lowering 用の診断を追加)、MetadataExtensions.cs(必要なメタデータ定数を追加)。 - オプション/CLI:
Options.cs、IlasmRootCommand.cs、Program.csに新オプションを追加(CommandLineTests.cs、CompilerOptionsTests.csにテスト)。 - ドキュメント:
KNOWN-ISSUES.md、MANAGED-ILASM-FIXES.mdを更新。 - テスト:
AssemblyTests、CustomAttributeTests、FieldTests、InteropTests、MethodTests、ParameterTests、PropertyEventTests、TypeDefinitionTestsに広範な回帰テストを追加。
パフォーマンスへの影響
影響なし(記載された情報の範囲では、パフォーマンスに関する変更やベンチマーク結果はありません)。
関連Issue
なし
その他
- Copilot レビューでは、疑似
FieldOffsetAttributeの lowering が明示的な.field [offset]を上書きしてしまい、ネイティブ ilasm と挙動が異なる点が指摘され、その後解決済みとされています。 - 最新のレビューでは、外部アクセサが未解決のまま残る場合に、プロパティのマーシャリングメタデータが同名・同シグネチャのローカルメソッドに誤って適用される可能性が指摘されています("Previously missed")。この fallback は、親が
ModuleTypeで実体化される「所有者のない(ownerless)アクセサ参照」に限定すべきとされています。 - 変更規模は約 3,000 行超の追加で、大半が新規ファイルとテストです。
#135073 Simplify metadata imports for single-module assemblies
- 作成者: @davidwrighton
- 作成日時: 2026年10月01日 23:30:26(UTC)
- マージ日時: 2026年10月09日 18:47:09(UTC)
- ラベル: area-VM-coreclr
概要
単一モジュールのアセンブリを前提に、メタデータのシグネチャ/型インポート用ヘルパーを簡素化するPRです。インポートヘルパーが「1つのソースモジュールと1つのデスティネーションモジュール」のみを扱う形になり、到達不能なマルチモジュール用のパスや ModuleRef 作成パスが削除されました。公開メタデータAPIのシグネチャは維持されますが、従来のアセンブリ/ハッシュ関連パラメータは無視され、AssemblyRef.HashValue は空のBLOBとして出力されます。
変更内容
src/coreclr/md/compiler/importhelper.cpp/importhelper.h: 型・シグネチャのインポート処理を単一ソース/単一デスティネーションモジュール前提に簡素化し、マルチモジュールおよびModuleRef作成の到達不能パスを削除(大部分の削減: +47/-469、+4/-41)src/coreclr/md/compiler/emit.cpp,helper.cpp: 上記ヘルパー変更に伴う呼び出し側の整理(レガシーなアセンブリ/ハッシュ関連パラメータの無視、空のAssemblyRef.HashValueの出力)src/coreclr/inc/metadata.h,src/coreclr/md/compiler/regmeta.h,src/coreclr/md/inc/liteweightstgdb.h,src/coreclr/md/inc/mdinternalrw.h,src/coreclr/md/runtime/mdinternalro.h: 不要になった宣言の削除src/coreclr/md/enc/mdinternalrw.cpp,src/coreclr/md/runtime/mdinternalro.cpp: 関連する内部実装の削減src/coreclr/vm/commodule.cpp: 不要コードの削除(-9)
影響範囲は CoreCLR のメタデータ(md)実装と VM 側の一部で、公開APIのシグネチャは維持される内部実装の簡素化です。なお、レガシーなアセンブリ/ハッシュ関連パラメータが無視されるようになる点は、挙動面での互換性に関わる変更です。
パフォーマンスへの影響
実行速度への影響に関する情報は提供されていません。バイナリサイズについては、クリーンな Release の browser-Wasm ビルド(同一ベースコミット b9bafb9d14e)で corerun.wasm が 4,381,222 bytes → 4,378,619 bytes と 2,603 bytes(-0.0594%) 縮小しています。
関連Issue
なし
その他
検証結果:
./build.sh clr -rc checked: 警告0・エラー0で成功System.Reflection.Emit.Tests: 2,640 件成功、失敗0、スキップ0- ベースラインおよび変更後の
./build.sh clr -os browser -c Releaseビルドも成功
#134848 Package DiaSymReader native assets with ILLink
- 作成者: @Copilot
- 作成日時: 2026年09月29日 10:05:36(UTC)
- マージ日時: 2026年10月09日 15:50:30(UTC)
- ラベル: linkable-framework area-Tools-ILLink
概要
ILLinkツールのパッケージに、Windows向けのDiaSymReaderネイティブアセット(DLL)を同梱するようにする変更です。既存の共有パッケージング用targetsをインポートして再利用し、x86・amd64に加えてARM64のDLLも対象に含めます。
変更内容
eng/DiaSymReaderNative.targets(+5/-0): DiaSymReaderのARM64用ネイティブバイナリを出力にコピーする設定を追加src/tools/illink/src/ILLink.Tasks/ILLink.Tasks.csproj(+1/-0): Windows向けに共有のDiaSymReaderパッケージング用targetsをインポートし、ILLinkのツールと一緒にDLLが配布されるようにした
影響範囲はビルド/パッケージング設定であり、公開APIやランタイム/コンパイラの実装コードの変更はありません。
パフォーマンスへの影響
影響なし
関連Issue
その他
- 作成者はCopilot(Copilot coding agent)です。
- Copilotによるレビュー概要では「Approval recommended」で、未解決の指摘(open findings)は0件とされています。
- 破壊的変更や互換性への影響についての記載はありません。
#134623 Deduplicate identical Wasm method bodies
- 作成者: @davidwrighton
- 作成日時: 2026年09月24日 22:28:48(UTC)
- マージ日時: 2026年10月09日 18:01:22(UTC)
- ラベル: area-ReadyToRun
概要
Wasm R2Rイメージでは、コンパイルされた全メソッドごとに個別のWasmモジュール関数定義が出力されていました。これを改め、シグネチャ・関数本体・リロケーションが完全に一致する場合は、1つの正規(canonical)なモジュール関数定義を共有する重複排除を導入します。
- 各マネージドメソッドは、固有のR2R runtime-functionインデックスとelement-tableスロットを維持します(ポータブルエントリポイント、
call_indirect、スタックウォーク、MethodDesc検索のメソッド同一性を保持)。 - 複数のtableスロットが1つの正規モジュール関数を参照でき、直接呼び出しは正規関数インデックスを対象にします。
- 重複排除はR2R WebCILオブジェクトライター内で完結し、NativeAOTのWasmオブジェクトライターでは有効化されません。
変更内容
WasmFunctionBodyDeduplicator.cs(新規, +247): ローワリング後のシグネチャ・関数バイト列・リロケーションとその対象が同一であることを条件に重複を判定する重複排除ロジック。安全な自己参照は正規化して比較し、tableスロットの同一性を露出する自己リロケーションがある場合は統合を禁止。funclet付きメソッドは対象外(各R2R runtime functionがtableスロットを保持するため)。ObjectWriter.cs/WasmObjectWriter.cs/WebCilObjectWriter.cs: 重複する関数定義の出力を省略し、直接呼び出しの関数インデックスを正規定義へエイリアスしつつ、必要なR2Rのtableスロットはすべて出力するよう変更。ILCompiler.Compiler.csproj/ILCompiler.ReadyToRun.csproj: 新規ファイルの組み込み。WasmModuleInfoReader.cs,ComposeWasiReadyToRun.cs,WasiApp.CoreCLR.targets: 重複排除後のモジュール構造に対応するための読み取り・合成処理の調整。- テスト(
R2RTestSuites.cs,WasmWebcilModule.cs,WasmR2RAssert.cs): 同一の通常メソッドが1つのモジュール定義を共有しつつ個別のtableスロットを保持すること、funclet付きの同一メソッドは別定義と全スロットを保持することを検証。 WebcilInWasmSizesTests.cs: サイズ関連のテストを追加。docs/workflow/building/coreclr/wasi-r2r.md: ドキュメント更新。
パフォーマンスへの影響
Release browser CoreLibビルドでの、重複排除無効時との比較:
| 項目 | 前 | 後 | 差 |
|---|---|---|---|
System.Private.CoreLib.wasm |
26,733,587 bytes | 25,238,139 bytes | -1,495,448 bytes (-5.594%) |
| モジュール関数定義数 | 57,722 | 48,251 | -9,471 (-16.408%) |
| Element/tableスロット数 | 57,722 | 57,722 | 変化なし |
実行速度は、転送用関数を生成しないためフォワーディングのオーバーヘッドはなく、7回実行のホットループ比較で以下の結果でした(作成者はいずれも高速化/ノイズ範囲としている)。
Vector128<sbyte>.op_UnsignedRightShift: 中央値で1.995%高速/ノイズVector.Log(Vector<double>): 中央値で2.566%高速/ノイズ
関連Issue
#134598(Resolves)
その他
- エイリアスとなったメソッドについて、エンジンレベルのWasmサンプルとWasm name sectionでは正規関数名が使われます。Perfmap出力では共有アドレス上でも各マネージドメソッド名が保持されます。
- 既存のNativeAOTのメソッド本体重複排除はシンボルをオブジェクト書き出し前に統合し、ランタイムメタデータやリロケーションの同一性まで1つにまとめてしまうため、各メソッドが独立にアドレス指定可能であるべきR2Rでは使えません。また、WebCILは最終的なWasmモジュールそのものであり、後段のCOMDAT/リンカ処理がなく、関数セクションとコードセクションが位置で1対1に対応するため、Wasm専用の変換として実装されています。
- 検証:
./build.sh tools+tools.ilasm(警告・エラーなし)、clr.r2rtests(browser, Release)、clr+libsビルド、async/式/JSON/ArrayPool<T>/SIMDジェネリクス/Vector.Logを含むブラウザR2Rスモーク、Perfmap生成がいずれも成功。
#134167 Run some libraries tests in jitstress isas pipelines
- 作成者: @dhartglassMSFT
- 作成日時: 2026年09月17日 23:23:26(UTC)
- マージ日時: 2026年10月09日 20:33:40(UTC)
- ラベル: area-Infrastructure-coreclr
概要
CoreCLRのjitstress-isas-*アウターループパイプラインに、ライブラリの一部テストを追加するPRです。これまでJIT stress ISAs用のライブラリテストが存在せず、例えばSystem.Numerics.VectorのテストとjitstressISAsの組み合わせで検出できたはずのバグ(fuzzingで検出)を取りこぼしていました。
ライブラリ全体用のパイプラインを3つ追加するほどの価値はないと判断し、関連性の高い以下のテストのみを既存のISAパイプラインに追加しています。
- System.Numerics.Vectors
- System.Numerics.Tensors
- System.Runtime.Intrinsics
- System.Linq
- System.Memory
変更内容
src/libraries/tests.proj:RunVectorTestsOnlyを追加し、対象のライブラリテストプロジェクトのみをビルドする条件付きリストを定義。有効時は通常のテストプロジェクトのglobをゲートする。eng/pipelines/coreclr/templates/jit-isas-libraries.yml(新規): 限定したライブラリテストをビルド・アーカイブし、ISA-stressシナリオでHelixに投入するステージテンプレート。eng/pipelines/coreclr/templates/jit-outerloop-pipeline.yml:isaScenariosのデフォルト値を追加し、ISA-stress実行時にシナリオ一覧を渡すよう変更。新しいライブラリステージも組み込む。eng/pipelines/common/templates/runtimes/run-test-job.yml: ハードコードされていたISA-stressシナリオ一覧を、パラメータjitIsaStressScenarios経由で受け取る形に置き換え(+4/-32)。
パフォーマンスへの影響
影響なし(CIパイプラインの変更であり、ランタイム/ライブラリの実行時性能には関係しません)。
関連Issue
なし
その他
- Copilotのレビューでは、
jit-outerloop-pipeline.ymlのisaScenariosデフォルトマッピングのインデントが不正でYAMLとして無効であり、ISA-stressパイプラインのシナリオ選択が壊れる可能性があるとの指摘(High severity)が出ています。これは未解決(Open)です。
#133606 Populate RemoteIdentity SID claims from the Kerberos PAC on Unix
- 作成者: @rzikm
- 作成日時: 2026年09月10日 15:37:09(UTC)
- マージ日時: 2026年10月09日 07:49:29(UTC)
- ラベル: area-System.Net.Security
概要
Unix上のNegotiate認証(NegotiateAuthentication)で、サーバー側のRemoteIdentityにKerberos PAC(urn:mspac:logon-info)由来のSIDクレームを追加するPRです。WindowsではWindowsIdentityによりユーザー/グループSIDが取得できますが、Unixではgss_display_nameによる表示名のみでした。本PRではGSSAPI経由でPACのlogon-infoを取得・デコードし、GenericIdentityにPrimarySid、PrimaryGroupSid、GroupSidクレームを追加します(SIDはWindows専用のSecurityIdentifierではなく文字列で保持)。
PACは、KDCが発行しない、クライアントが拒否する、Windowsグループを持たないレルムなど、存在しないのが通常のケースもあるため、PACがなくても認証は失敗しません。クレームはGSSAPIが「authenticated」と報告した場合のみ追加され、不正なバッファの場合は例外ではなくクレームなしにフォールバックします。
変更内容
- ネイティブ(System.Net.Security.Native)
pal_gssapi.c/.h、entrypoints.c: 名前属性を取得するNetSecurityNative_GetNameAttributeを追加。gss_get_name_attributeはすべてのGSSAPI実装にあるわけではないため、オプション関数の一覧を導入し、存在しない場合は初期化失敗ではなくポインタをnullのままにする。configure.cmake、pal_config.h.in:HAVE_GSS_GET_NAME_ATTRIBUTEを追加。ライブラリはdlopenされるため、プローブはリンクしない構成。
- マネージド/Interop
Interop.NetSecurityNative.cs(GetNameAttributeのLibraryImport)、Interop.NetSecurityNative.IsNtlmInstalled.csを更新。
- PACデコーダ
Common/src/System/Net/Security/KerberosPacLogonInfo.cs(新規、+512行):KERB_VALIDATION_INFOをデコードしてユーザー/プライマリグループ/グループのSIDを文字列化。
- System.Net.Security
NegotiateAuthenticationPal.Unix.cs:RemoteIdentityをキャッシュし、サーバー側でPACクレームを追加。System.Net.Security.csprojにデコーダをリンク。
- テスト基盤
FakeKdcServer.cs、FakeKerberosPrincipal.cs、KerberosExecutor.cs: PAC付きチケットを生成するAddUserWithPacなどを追加。Capability.Security.*にGSS機能判定を追加。KerberosPacLogonInfoTest.cs(デコーダの正常/切り詰め/破損入力)、NegotiateAuthenticationKerberosTest.cs(PACあり/なしでのクレーム検証)、NegotiateStreamLoopbackTest.cs(EnterpriseTests)を追加。
- ファジング
KerberosPacLogonInfoFuzzer.cs、System.Net.Security.Fuzzingプロジェクト、OneFuzz配備パイプライン、CollectCoverage.ps1、READMEを追加/更新。
パフォーマンスへの影響
影響なし(ベンチマーク結果の記載なし)。サーバー側でPAC取得のためのGSSAPI呼び出しとデコード処理が追加されます。レビューでは、NTLMはPACを運ばないためこの処理を省略すべきとの指摘がありました。
関連Issue
なし
その他
- 既知の制限:
GenericIdentityはRoleClaimTypeをGroupSidにできないため、IsInRoleはグループSIDにマッチしません(WindowsIdentityとは異なる)。 - Copilotレビューでは、
complete == 0(不完全な属性値)の扱い、SIDのリビジョン/サブオーソリティ数の検証、cmakeプローブがリンクしないこと、テストのガード条件(Linux限定の解除、PAC属性の対応有無の判定)、RemoteIdentityキャッシュのタイミングなどが指摘されていました。 README.mdの更新とEnterpriseTests向けのドキュメント追加も含まれます。
#133263 Move runtime test build into product jobs
- 作成者: @jkoritzinsky
- 作成日時: 2026年09月04日 21:13:14(UTC)
- マージ日時: 2026年10月09日 22:50:57(UTC)
- ラベル: area-Infrastructure
概要
src/tests 配下のランタイムテストについて、これまで独立していた「テストビルドジョブ」と「テスト実行ジョブ」をやめ、プロダクトビルドジョブの中でテストのビルドと Helix への送信まで実行するように変更します。NativeAOT と Mono のレグでは既に同様の構成になっており、一部プラットフォーム(特に macOS)でビルドマシンのキュー待ちが非常に長くなっているため、新規ビルドマシンのキュー待ちを省き、1 台のマシンで処理を完結させることで高速化を狙っています。src/tests のビルドは増えますが、全体では速くなる見込みとのことです。
今回は Pri0 のテストビルドである runtime.yml パイプラインのみが対象で、Pri1 など他のテストビルドは対象外です。最終的には全テストビルドを同様の構成にして、関連インフラを削除することが目標とされています。
変更内容
eng/pipelines/runtime.yml(+77/-172): CoreCLR の独立したランタイムテストのビルド/実行ジョブブロックを削除し、複数のプロダクトビルドジョブ内でbuild-runtime-tests-and-send-to-helix.ymlを呼び出す構成に変更。影響するジョブマトリクスの Helix キューセットアップや、複数ジョブのタイムアウト値も調整。eng/pipelines/common/templates/runtimes/build-runtime-tests-and-send-to-helix.yml(+16/-8):conditionを build ステップへ引き渡し、追加の AOT ステップや send ステップも呼び出し側の condition を尊重するよう変更。eng/pipelines/common/templates/runtimes/build-runtime-tests.yml(+2/-0): 「Build Tests」ステップにconditionパラメーターを渡せるように変更。eng/pipelines/common/templates/runtimes/send-to-helix-inner-step.yml(+3/-3):conditionパラメーターを bool の既定値付きで定義し、succeeded()および送信パラメーターが空でない条件と組み合わせて適用するよう修正。eng/pipelines/common/templates/runtimes/send-to-helix-step.yml(+1/-1): 内部ステップへ委譲する際のステップレベルのconditionの適用方法を調整。src/tests/Common/helixpublishwitharcade.proj(+3/-5): 変更あり(提供情報からは詳細不明)。
パフォーマンスへの影響
ビルドマシンのキュー待ち時間を削減することによる CI のエンドツーエンドの所要時間短縮が目的です。具体的なベンチマーク数値は提供されていません。一方で、プロダクトビルドジョブ内で src/tests をビルドする回数が増えるため、ジョブ単体の処理量は増加します(そのため複数ジョブのタイムアウトが延長されています)。ランタイムの実行性能への影響はありません。
関連Issue
なし
その他
- Copilot のレビューでは、新規の CoreCLR 呼び出し箇所で
build-runtime-tests-and-send-to-helix.ymlの既定値(runtimeFlavor: mono/runtimeVariant: monointerpreter)が上書きされていない点が指摘されました(その後のレビューで解決済みとされています)。 - 最新のレビューでは、テンプレート側で
conditionパラメーターが宣言されておらず、true を既定値として宣言する必要があるという指摘が未解決として残っています。また、パイプライン構成が大きく変わるため、人間による動作確認が望ましいとされています。
#132347 Update guidelines for C++ standard library usage and build against libc++ w/ libstdc++ ABI for linux arm/arm64/x64
- 作成者: @jkoritzinsky
- 作成日時: 2026年08月14日 23:20:49(UTC)
- マージ日時: 2026年10月09日 23:24:37(UTC)
- ラベル: area-Infrastructure
概要
Linux の arm/arm64/x64 向けビルドを、サービス可能な C++ 標準ライブラリ(libc++ + libstdc++ ABI)に対してビルドするようパイプラインを更新し、C++ 標準ライブラリ利用に関する CoreCLR のコーディングガイドラインをそれに合わせて改訂する PR です。#101088 および #101773 のフォローアップで、関連する dotnet/dotnet 側の PR は https://github.com/dotnet/dotnet/pull/8608 です。
変更内容
eng/pipelines/common/platform-matrix.yml: Linux arm/arm64/x64(およびlinux_x64_sanitizer)のジョブにcxxStandardLibrary、cxxStandardLibraryStatic、cxxAbiLibraryパラメータを追加(+9)docs/coding-guidelines/clr-code-guide.md: 標準ヘッダー/型の利用方針、Linux での C++ ライブラリ構成、DAC/cDAC の制約に関するガイダンスを改訂(+20/-10)src/coreclr/utilcode/cxxexception.cpp(新規, +184)およびsrc/coreclr/utilcode/CMakeLists.txt: C++ 例外の変換処理を行うコードを追加。Copilot のレビューコメントによるとstd::current_exception/std::rethrow_exceptionを使用しているsrc/coreclr/inc/ex.h、src/coreclr/vm/excep.cpp、src/coreclr/vm/exceptmacros.h: 例外処理まわりの調整src/coreclr/pal/tests/palsuite/threading/QueryThreadCycleTime/test1/test1.cpp: 出力フォーマット指定をPRIu64系に変更
パフォーマンスへの影響
影響なし(提供された情報にベンチマーク等の記載なし)
関連Issue
その他
Copilot のレビューで以下の指摘があります。
- ガイドラインは「
MODE_COOPERATIVEで呼び出して安全な C++ 標準ライブラリ API は現状ない」としているが、本 PR で追加された例外変換処理がMODE_ANYで標準ライブラリ API を呼び出しており、ガイドラインと矛盾しうる。例外として明記するか、MODE_PREEMPTIVE/GCX_PREEMPに制約する必要がある。 test1.cppでは、符号付きLONG64に対し符号なし用のPRIu64が使われており、負値の出力が不正になる可能性がある。PRId64とint64_tへのキャストが推奨されている。
#131502 docs: remove RuntimeFrameworkVersion dogfooding guidance now that we have VMR daily builds
概要
dogfooding(最新ビルドの試用)に関するドキュメントから、RuntimeFrameworkVersion を手動でピン留めする手順を削除するPRです。dotnet/dotnet(VMR)による統一的なランタイムビルドフローが整備されたため、この手順は想定される標準的な方法ではなくなった、というのが作成者の説明です。
変更内容
docs/project/dogfooding.md(+0/-57)RuntimeFrameworkVersionを使ったdogfoodingガイダンスを削除(57行の削除のみ、追加なし)
パフォーマンスへの影響
影響なし(ドキュメントのみの変更)
関連Issue
なし
その他
- コードやAPIへの変更はなく、互換性への影響もありません。
- 削除されたセクションの具体的な内容や、代替として案内される手順はPRの提供情報からは確認できません。
- Copilotがレビュー対象として割り当てられていますが、課金対象ユーザーがいないためレビューは実施されていません。