注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
- #135992 Re-enable BFloat16 Int128/UInt128 conversion tests on WASI ReadyToRun
- #135975 Fix Android HTTP certificate validation tests
- #135951 Fix NativeAOT test layout's CoreCLR runtime dependency
- #135947 [QUIC] Disable the test on JitStress
- #135898 Fix Unix mutex directory validation and default-scope test expectations
- #135897 [browser][coreclr] Stage composite R2R image for library tests
- #135890 Fix double GC relocation of overlapping byrefs
- #135881 Change more IndexOf == -1 checks into Contains
#135992 Re-enable BFloat16 Int128/UInt128 conversion tests on WASI ReadyToRun
- 作成者: @lewing
- 作成日時: 2026年10月17日 04:03:45(UTC)
- マージ日時: 2026年10月17日 05:53:22(UTC)
- ラベル: arch-wasm area-System.Numerics
概要
WASI ReadyToRun向けに無効化されていた BFloat16Tests.ExplicitConversion_FromInt128 と ExplicitConversion_FromUInt128 のテストを再有効化します。#134813で追加された ActiveIssue 属性を削除する変更です。
原因はBFloat16の変換バグではなく、Int128/UInt128 を含むauto layout構造体のアラインメント不一致でした。ランタイムは8バイト、crossgen2は16バイトでアラインしていたため、R2Rコードとランタイムでレイアウトが食い違い、Int128 の入力値が破損していました(例: (0, BFloat16.Zero) の行が i: 336347874021343232, expected: 0 となる)。この問題は #135481([wasm] Keep larger field alignment for Align8 auto-layout structs)で修正済みです。
変更内容
src/libraries/System.Runtime/tests/System.Runtime.Tests/System/Numerics/BFloat16Tests.cs(+0/-2)- WASM ReadyToRun向けの
ActiveIssue属性を2箇所削除
- WASM ReadyToRun向けの
パフォーマンスへの影響
影響なし(テスト変更のみ)
関連Issue
- Resolves #135116
- 原因修正: #135481、無効化の経緯: #134813
その他
作成者によるbisect結果(macOS arm64ホスト、wasmtime、CoreCLR WASI composite ReadyToRun):
| ビルド | 実行数 | 失敗数 |
|---|---|---|
| #135116の元のHelixペイロード | 1608 | 3 |
| e6482f46d52(#135481の直前) | 1631 | 3 |
| 7b82a69e6b7(#135481マージ) | 1631 | 0 |
| 109674e8cdc、50131be5c3d、main(2026-10-16時点) | 1631–1634 | 0 |
この変更を含むmainベースのビルドでのSystem.Runtime.Tests WASI R2Rスイート全体は、78,321件実行・78,151件成功・失敗0・スキップ170件でした。
#135975 Fix Android HTTP certificate validation tests
- 作成者: @MihaZupan
- 作成日時: 2026年10月16日 20:47:58(UTC)
- マージ日時: 2026年10月17日 22:44:56(UTC)
- ラベル: area-System.Net.Http
概要
Android上のHTTP証明書検証テストの失敗(dotnet/runtime#123572、#135618以降に報告)と、新しいOpenSSLバージョンでの残存失敗を修正するテスト専用の変更です。プロダクションコードの変更はありません。
主な原因と対応は次のとおりです。
- Androidのトラストアンカー: Androidはトラストアンカーの有効期限を検査しないため、期限切れの自己署名サーバー証明書を信頼すると検証が成功してしまい、サーバーが応答せずに閉じてクライアントの再試行と100秒タイムアウトが発生していました。期限切れ/ホスト名不一致のリーフ証明書は、別の有効なCAから発行する方式に変更されました。
- Androidのチェーン構築: 空のカスタムトラストストアは未サポートのため、自己署名で未信頼のケースでは空でない無関係なトラストストアを使用します。期限切れ/未信頼の証明書を経由するパスをAndroidが構築できない場合は
PartialChainを期待します。 - OpenSSLのBasic Constraints: 自己署名サーバー証明書が
KeyCertSignなしのCAとしてマークされていたため、厳格なOpenSSLでは期待値のUntrustedRootではなくUntrustedRoot | InvalidBasicConstraintsが報告されていました。サーバー証明書は常にエンドエンティティとなり、CA用ヘルパーはCA制約と署名用途を保持します。 - 失敗の決定性: 証明書検証が想定外に成功した場合にも応答を返すため、アイドル状態のリスナーに対するタイムアウトではなく、アサーションが直接失敗します。
ポリシーエラーの厳密なアサーションは維持されています。
変更内容
src/libraries/Common/tests/System/Net/Http/TestHelper.cs(+17/-4)- 発行者署名によるサーバー証明書の生成を追加(自己署名もサポート継続)
- サーバー証明書は常にエンドエンティティとし、CA用ヘルパーはCA制約と署名用途を維持
src/libraries/Common/tests/System/Net/Http/HttpClientHandlerTest.ServerCertificates.cs(+46/-21)- 空でないカスタムトラストストアの利用
- Android向けのチェーンステータス期待値の調整
- 期限切れとホスト名不一致を組み合わせたテストの追加
- 自己署名とCA発行の両サーバー証明書がエンドエンティティであることを検証する回帰テストの追加
- 想定外に検証が成功した場合に応答を返す処理の追加
パフォーマンスへの影響
影響なし(テストのみの変更)。なお、Android上で検証が誤って成功した際に発生していた再試行による100秒超のタイムアウトは解消されます。
関連Issue
- #123572(汎用的なタイムアウト追跡Issueには無関係な失敗も含まれるため、このPRでは自動クローズされません)
- 関連PR: #135618
その他
- Helix上で286件の対象テスト実行が成功(失敗0、スキップ0)。内訳は、Windows 11 x64 (CoreCLR) 86、Windows 10 .NET Framework 4.8.1 15、Ubuntu 22.04 33、Ubuntu 26.04 33、Alpine 3.24 33、Android 10/API 29 28、macOS 26 arm64 32、macOS 15 x64 (Mono) 26です。
- 修正前の再現も確認されています。未修正のAndroidベースラインでは、101秒の期限切れ証明書タイムアウトを含む4件の失敗が再現しました。OpenSSL 3.5.5では余分な
InvalidBasicConstraintsフラグが再現し、新しい回帰テストが修正前に失敗することも確認されています。 - ブラウザ/WASIの証明書テストは未サポートのため対象外です。
#135951 Fix NativeAOT test layout's CoreCLR runtime dependency
- 作成者: @MichalStrehovsky
- 作成日時: 2026年10月16日 13:57:24(UTC)
- マージ日時: 2026年10月17日 02:41:59(UTC)
- ラベル: arch-wasm area-NativeAOT-coreclr
概要
NativeAOTテストレイアウト(Core_Root)生成が、意図せずCoreCLRランタイムのファイルに依存していた問題を修正します。これまでNativeAOT WASIのテストビルドでは、NativeAOT SDKとコンパイラが利用可能でも、Core_Root生成時に「The 'coreclr' subset must be built before building this project」というエラーで失敗していました。
原因は、デスクトップ向けNativeAOTビルドでは sharedFramework にターゲットJITが配置されるため、このチェックを偶然満たしていた点です。WASMのクロスJITは別の場所にあるため、この条件を満たせませんでした。
変更内容
src/tests/Common/Directory.Build.targets(+8/-4)- NativeAOTモードではCoreCLRランタイムファイルの解決をスキップします。
- 残りのレイアウト生成とNativeAOTツールのステージングは維持します。
- 同モードでは、未使用のWASMホスト/runtimepackアセットと、WASIのReadyToRunコンポーザー要件を除外します。
- CoreCLRのテストレイアウトは従来の挙動のままです。
パフォーマンスへの影響
影響なし(テストレイアウト生成のビルド時の変更であり、ランタイムの性能に関わる変更ではありません)。
関連Issue
なし
その他
- 作成者による検証(未マージの他の有効化変更を含むローカルのNativeAOT WASIブリングアップツリー上):
- テスト成果物を削除後、
.\src\tests\build.cmd nativeaot checked tree nativeaot wasm wasiでレイアウトが再生成され、無関係なテストコンパイルエラーの段階まで進みました。 .\src\tests\build.cmd nativeaot checked test nativeaot\SmokeTests\AttributeTrimming\AttributeTrimming.csproj wasm wasiは成功しました。- AttributeTrimmingはWasmtime上でexit code 100で実行されました。コピーされたNativeAOT SDK/コンパイラのファイルは、プロダクトの出力と一致しています。
- テスト成果物を削除後、
- このブランチは
mainからcherry-pickした本コミットのみを含み、単独ではビルドされていません。 - WASIテストの自動実行とUnixホストでのブリングアップは含まれていません。
#135947 [QUIC] Disable the test on JitStress
- 作成者: @ManickaP
- 作成日時: 2026年10月16日 13:38:06(UTC)
- マージ日時: 2026年10月17日 02:40:33(UTC)
- ラベル: area-System.Net.Quic
概要
System.Net.Quic の機能テストを JitStress 環境で無効化する変更です。JitStress では、オブジェクトのルート解除・解放を確認するテストにおいて、20回のイテレーションでは GC によるクリーンアップが間に合わないことがあり、不安定になっていました(dotnet/runtime#134828 の修正)。
作成者によると、ActiveIssue を付けて Issue を開いたままにする案もありましたが、他のシナリオではテストが成功しオブジェクトが正しく解放されることが確認できているため、テスト無効化により Issue をクローズする方針を選んだとのことです。
変更内容
src/libraries/System.Net.Quic/tests/FunctionalTests/MsQuicTests.cs(+1/-0)- 対象テストを JitStress 環境で実行しないよう、1行を追加(具体的な属性名は提供情報からは不明)
パフォーマンスへの影響
影響なし(テストコードのみの変更で、ランタイム・ライブラリの実装や公開 API には影響しません)。
関連Issue
その他
- 本変更はテストの安定化のみを目的としており、互換性や公開 API への影響はありません。
- JitStress 以外のシナリオではテストが引き続き実行され、オブジェクトの解放が検証されます。
#135898 Fix Unix mutex directory validation and default-scope test expectations
- 作成者: @Copilot
- 作成日時: 2026年10月15日 21:59:57(UTC)
- マージ日時: 2026年10月17日 00:20:35(UTC)
- ラベル: area-System.IO
概要
Unixにおける名前付きMutex(共有メモリ)のディレクトリ検証を緩和し、named-mutexのスコープ変更後もテストの期待値が旧仕様(グローバルスコープ)のまま残っていた不整合を修正するPRです。既存の共有メモリ用ディレクトリのうち、実際には利用可能なものが所有者・権限チェックで拒否されてしまう問題に対応しています。内部実装(System.Private.CoreLibのUnix共有メモリ管理)とテストの変更で、公開APIの変更はありません。
変更内容
src/libraries/System.Private.CoreLib/src/System/IO/SharedMemoryManager.Unix.cs(+2/-104)- 既存ディレクトリに対する所有者・パーミッションの検証を削除し、ファイルシステムのアクセスエラーに依存する方式に変更
- 安全な作成モード、シンボリックリンクを辿らないオープン、ファイルの所有者・パーミッションチェックは維持
src/libraries/System.Private.CoreLib/src/Resources/Strings.resx(+0/-12)- 削除された検証ロジックに対応する不要なリソース文字列を削除
src/libraries/System.Threading/tests/MutexTests.cs(+52/-4)NameOptionsApiCompatibilityTestの期待値を、Unixではユーザースコープ、Windowsでは従来どおりの既定に更新- 所有者のみアクセス可能なディレクトリと、全員書き込み可能なディレクトリの既存ケースで、作成・再オープンを行い、ディレクトリのパーミッションが変更されないことを検証する回帰テストを追加
パフォーマンスへの影響
影響なし(提供された情報にパフォーマンスに関する記載はありません)。
関連Issue
- #135887(本PRで修正)
その他
- 互換性:既存ディレクトリの所有者・パーミッション検証が削除されるため、これまで拒否されていた既存ディレクトリが利用可能になります。アクセス可否は通常のファイルシステムのエラーで判断されます。
- 本PRはCopilotコーディングエージェントによって作成されています。
#135897 [browser][coreclr] Stage composite R2R image for library tests
- 作成者: @lewing
- 作成日時: 2026年10月15日 21:29:04(UTC)
- マージ日時: 2026年10月17日 19:02:06(UTC)
- ラベル: arch-wasm area-Infrastructure-libraries os-browser
概要
Browser CoreCLR のライブラリテストで PublishReadyToRunComposite=true を指定すると、起動時に Assembly not found: 'System.Memory.Tests.r2r.wasm' で失敗する問題の修正です。
原因は、ライブラリテストが入れ子の publish 内で crossgen を実行する一方、実際には build 出力(bin/)を配信している点にあります。build 時の webcil ステージングは obj/R2R を読むためコンポーネントスタブは配置されます。しかし、コンポジットのオーナー(<entry>.r2r.wasm)はアセンブリではなく、WebAssembly SDK では ProcessPublishFilesForWasm 内で publish 用の静的 Web アセットとしてのみ定義されます。この処理がここでは実行されないため、オーナーが wwwroot/_framework にコピーされず、build 用のブート設定にも列挙されていませんでした。
修正は、入れ子の publish がコンポジットイメージを出力として返し、外側の build が静的 Web アセットとして定義する方式です(WasmNativeAsset や WasmAssembliesFinal が外側へ戻る流れと同様)。
変更内容
docs/workflow/testing/libraries/testing-wasm.md- コンポジット構成のライブラリテスト実行コマンドを追記(+15)。
src/mono/browser/build/BrowserWasmApp.CoreCLR.targetsWasmNestedPublishAppが、生成したイメージ(CreateCompositeImage=trueの_ReadyToRunCompileList)を_WasmNestedPublishCompositeR2RImageとして返すように変更。WasmTriggerPublishAppがそのアイテムを収集。
src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets- 上記アイテムが存在する場合、
_ResolveWasmOutputsが既存のWasmResource=readyToRunCompositeトレイト付きの build 用静的 Web アセットとして定義。 - これにより
GenerateWasmBootJsonがcoreAssemblyにisCompositeImage付きで列挙し、他のフレームワークアセットと同様にコピー・フィンガープリント付与される。
- 上記アイテムが存在する場合、
通常の dotnet publish では、外側の build が WasmTriggerPublishApp 実行前にアセットを解決するため、このアイテムは空になり、既存の publish 用アセット定義だけが残ります。eng/testing/tests.browser.targets は変更されていません。
パフォーマンスへの影響
影響なし(ビルド/テスト基盤の修正であり、実行時性能に関する記載はありません)。
関連Issue
なし
その他
検証結果(macOS arm64, Release):
- ライブラリテスト
- System.Memory.Tests(コンポジット、クリーン): 52254 件実行、失敗 0
- 同(増分再実行): 52254 件実行、失敗 0
- System.Memory.Tests(per-assembly、クリーン): 52254 件実行、失敗 0(コンポジットイメージは配置されない)
- per-assembly からクリーンせずコンポジットへ切り替え: 52254 件実行、失敗 0
- System.Runtime.Tests(コンポジット、クリーン): 78303 件実行、失敗 0
- アプリ
Wasm.Build.Tests.ReadyToRunTests(CoreCLR): 10/10 成功。これらの publish は入れ子の publish を実行しないため、新ブロックが no-op であることを確認。src/mono/sample/wasm/console-nodeのコンポジット publish(2 回実行): node 上で動作し、コンポジットイメージ 1 つとisCompositeImageエントリ 1 つを確認。binlog 上、外側の_ResolveWasmOutputsが入れ子 publish の返却前に実行されることも確認。
なお、PR 説明は GitHub Copilot によって生成された旨が記載されています。
#135890 Fix double GC relocation of overlapping byrefs
- 作成者: @jkoritzinsky
- 作成日時: 2026年10月15日 19:40:36(UTC)
- マージ日時: 2026年10月17日 03:11:27(UTC)
- ラベル: area-VM-coreclr
概要
明示的レイアウト(StructLayout(LayoutKind.Explicit))の byref-like 値型(ref struct)をGCがスキャンする際、フィールドが重なっていると同じ byref スロットが複数回報告され、コンパクションGCが既に再配置済みの内部ポインタを再度再配置してしまう問題の修正です。各物理 byref スロットを一度だけ報告するようにします。デバッガー固有の問題ではなく、通常の値渡しの ref struct 引数でも Windows x86 + DOTNET_GCStress=1 で破損が再現するとされています(#133659 のレビューで依頼されたスタンドアロンの GC 修正)。
変更内容
src/coreclr/vm/siginfo.cpp(+60/-1)- 囲んでいる重複レイアウトを追跡し、先行フィールドについて「参照先オブジェクトの値」ではなく「スロットのアドレス」そのものを照合して重複報告を防止
- このチェックはスタックのみを使用し、アロケーションなし。重複レイアウトは稀なため、二次的(quadratic)なコストが生じる点をコードで文書化
- GC列挙中に型ロードを引き起こさないよう、既にロード済みの値型フィールドハンドルを使用
src/tests/Loader/classloader/RefFields/Validate.cs(+125/-0)- 既存の ref フィールドテストに回帰テストを追加。重なった2つのビューの両方から4つの期待値を検証
- 非インライン化された呼び出し先により、JIT 遷移をまたいで値渡し引数が保持される構成
- Copilot の概要によると、ネストした重複や共有バッキング配列もカバー
パフォーマンスへの影響
ベンチマークの記載はありません。重複レイアウトのチェックはスタック上のみで行われ、アロケーションは発生しません。ただし重複レイアウトの場合、チェックは二次的なコストとなります(稀なケースとして想定)。
関連Issue
#135245(Resolves)。関連PR: #133659 のレビューでの指摘に基づく修正。
その他
- 検証は Windows x86(Checked ランタイム、Release ライブラリ)のみで実施。その他のアーキテクチャ・プラットフォームは未実施です。
- 修正前:
DOTNET_GCStress=1で再現コードの出力が0 3801155 7536732 2949173(破損)、新規回帰テストは失敗(期待値1、実際6881312) - 修正後: 再現コードは
1 2 3 4、ref フィールドテスト 6/6 パス、既存の InlineArray テスト 11/11 パス(通常/GCStress の両モード)
- 修正前:
- GCのスキャナーに関わる安全性重視の変更のため、ランタイムオーナーによるスキャナー不変条件の確認と、Windows x86 以外のプラットフォームでのカバレッジ確認が必要とされています。
- 本実装とPR説明は GitHub Copilot により作成されています。
#135881 Change more IndexOf == -1 checks into Contains
- 作成者: @MihaZupan
- 作成日時: 2026年10月15日 18:32:04(UTC)
- マージ日時: 2026年10月17日 22:54:45(UTC)
- ラベル: area-Meta
概要
IndexOf(...) == -1(および < 0 など)形式の判定を Contains(...) 呼び出しへ置き換えるリファクタリングです。既存の同種変更の続きとして、ライブラリ全体の該当箇所を追加で変換しています。提供された情報からは、公開APIの変更や動作変更の記載は確認できません。
// 変更イメージ(一般的なパターン)
// 変更前
if (span.IndexOf(value) == -1) { ... }
// 変更後
if (!span.Contains(value)) { ... }
変更内容
Common/src/Polyfills/MemoryExtensionsPolyfills.cs(+2/-2)- Cryptography 関連(X25519 の Windows 実装・ヘルパー、およびテスト)の
IndexOf判定をContainsへ変更X25519DiffieHellmanCng.Windows.csX25519DiffieHellmanImplementation.Windows.csX25519WindowsHelpers.csX25519DiffieHellmanCngTests.Windows.csX25519DiffieHellmanKeyTests.cs
Microsoft.Bcl.Cryptography/.../NetStandardShims.cs(+0/-20):20行を削除Microsoft.VisualBasic.Core/.../TextFieldParser.vb(+3/-3)System.Diagnostics.DiagnosticSource/.../W3CPropagator.cs(+1/-1)System.Net.HttpListener/.../HttpListenerRequest.cs(+1/-1)System.Private.CoreLib内の以下のファイルDiagnostics/Tracing/TraceLogging/Statics.csIO/PathHelper.Windows.csNumerics/TotalOrderIeee754Comparer.cs
System.Text.Json内の以下のファイルJsonReaderHelper.cs(+3/-3)Utf8JsonReader.MultiSegment.cs(+2/-4)Utf8JsonReader.cs(+1/-2)
パフォーマンスへの影響
ベンチマーク結果や具体的な数値は提供されていません。Contains は「見つかったかどうか」だけを判定する意図を表すため、可読性の向上が主な目的と考えられます。
関連Issue
- #135881(本PR自体)
- 「more(さらに)」というタイトルから先行する同種のPRの存在がうかがえますが、具体的なIssue/PR番号は提供情報からは確認できません。
その他
- 変更は広範囲(16ファイル)ですが、1ファイルあたりの変更行数は少なく、機械的な置換が中心とみられます。
NetStandardShims.csのみ削除行が多く(-20)、netstandard 向けシムの一部が不要になった、あるいはPolyfills側へ集約された可能性がありますが、提供情報だけでは確定できません。