Pull Request on 2026年10月18日

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

注意点

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

#136023 Add ILVerify tests for exception-handling errors

概要

ILVerify (ILVerification.Tests) に、例外処理関連の VerifierError コード5件のテストを追加するPRです。main 時点で、どの _Invalid_ / _InvalidType_ テスト名にも含まれていない42件のエラーコードを埋める小規模バッチの第1弾です。本番コードの変更はなく、テストILのみの追加です。

変更内容

src/coreclr/tools/ILVerification.Tests/ILTests/ExceptionRegionTests.il（+112行）に以下を追加しています。

追加テスト 期待されるエラー
Rethrow.InFinally_Invalid_Rethrow Rethrow
Catch.EndsWithEndfinally_Invalid_Endfinally Endfinally
Catch.BranchOut_Invalid_BranchOutOfHandler BranchOutOfHandler
Filter.HandlerEndsWithEndfilter_Invalid_Endfilter Endfilter
Filter.ExceptionLeftOnStack_Invalid_EndfilterStack EndfilterStack
Rethrow.InCatch_Valid（有効ケース） エラーなし
  • 各 Invalid テストは「ちょうど1つのエラー」を期待します。そのため、期待エラーが出ない場合や他のエラーも同時に報告される場合は失敗します。
  • 追加前は rethrow を使うテストがなく、catch ハンドラ内の rethrow が受理されることは検証されていませんでした。Rethrow.InCatch_Valid はこれを補います。

対象外としたコード（再現するILを書けなかったもの）:

  • FilterOrCatchUnexpectedStack / FinOrFaultNonEmptyStack: ハンドラ先頭への有効な分岐はハンドラ内部からのみで、その時点では入口スタックが設定済みのため、深さの不一致は PathStackDepth として報告されます。
  • CatchByRef: catch 句の型トークンが byref 型に解決されず、先に BadTypeSpec で拒否されます。

パフォーマンスへの影響

影響なし（テストのみの追加）。

関連Issue

なし

その他

  • 検証結果（linux-x64、SDK 11.0.100-rc.1.26420.103、main 42118298a26 ベース）:
    • 変更前 502/502、変更後 508/508 で成功。
  • 各新規テストが失敗し得ることの確認（一時的な編集のため PR には含まれません）:
    • ILImporter.Verify.cs で該当エラーの検出を無効化すると、各回 507/508 でそのテストのみ失敗します。
    • ImportRethrow の catch ハンドラ用の早期 return を無効化すると、Rethrow.InCatch のみ Rethrow エラーで失敗します。
    • テスト名の期待エラーを別コードに変えると、各回 507/508 でそのテストのみ失敗し、元のエラーが報告されます。
  • 作成者は、AI支援（Anthropic Claude、OpenAI Codex）を用いて作成し、投稿前にレビューしたと記載しています。
  • Copilotのレビューでは、未解決の指摘なしで承認推奨とされています（ビルドとテストはレビュー中には再実行していません）。

#136019 Report byref-like struct arguments to the GC in helper-based tail calls

  • 作成者: @EgorBo
  • 作成日時: 2026年10月18日 02:26:19(UTC)
  • マージ日時: 2026年10月18日 18:47:30(UTC)
  • ラベル: area-VM-coreclr

概要

ヘルパーベースの末尾呼び出し（tail call）で、Span<T> のような byref-like 構造体の引数が GC に報告されない問題を修正します。

TailCallHelp::GenerateGCDescriptor は GC シリーズを持たない値型をスキップしていましたが、Span<T> などの byref-like 構造体は GC シリーズを持たないものの内部ポインタ（interior pointer）を含みます。そのため、tail call の引数バッファに格納されている間は GC に報告されず、IL_STUB_StoreTailCallArgs と IL_STUB_CallTailCallTarget の間で GC が発生すると、呼び出し先が配列の旧位置を指す古いポインタを受け取る可能性がありました。

修正では、GC ディスクリプタ構築時に byref-like 構造体を GC ポインタを持つ構造体と同様に扱います。getClassGClayoutStatic はすでに byref フィールドを TYPE_GC_BYREF として報告するため、それを利用できます。

変更内容

  • src/coreclr/vm/tailcallhelp.cpp（+2/-1）: GenerateGCDescriptor で byref-like 構造体を GC ポインタを持つ構造体と同様に扱うよう条件を変更
  • src/tests/JIT/Regression_2/Runtime_136010/Runtime_136010.il（+117/-0）: Span<int> 引数を持つヘルパーベースの tail call を行う最小限の IL 回帰テストを追加
  • src/tests/JIT/Regression_2/Runtime_136010/Runtime_136010.ilproj（+9/-0）: 上記テスト用のプロジェクトファイルを追加

パフォーマンスへの影響

影響なし（提供された情報にベンチマーク結果の記載はありません）

関連Issue

#136010（本PRで修正）

その他

  • ランタイム内部（CoreCLR VM）の実装修正であり、公開 API や互換性への影響に関する記載はありません。
  • 追加された回帰テストは、tail call のスタブ間で GC が発生しないと失敗を再現できないため、主に GC ストレス実行のテスト構成で検出されるとのことです。

#136018 Fix malformed XML doc comments under src/coreclr/tools

概要

src/coreclr/tools 配下の7ファイルにある、XMLドキュメントコメント9箇所の不正なXMLや無効な参照を修正するクリーンアップPRです（コメントのみの変更で、コード変更はありません）。これらのプロジェクトは GenerateDocumentationFile を有効にしていないため現在は無視されますが、有効化すると警告となり、警告をエラー扱いにしている場合はビルドが失敗します。作成者はドラフトの任意クリーンアップとしており、不要であればクローズしてよいとしています。

変更内容

  • MethodIL.cs: MethodILScope.OwningMethod の空の cref に MethodILScope を指定
  • DefType.FieldLayout.cs: コメント内の Vector<T> を Vector&lt;T&gt; にエスケープ（2箇所）
  • CustomAttributeTypeNameParser.cs: CustomAttributeTypeNameFormatter への cref を <c> テキストに変更（ILVerificationがパーサーをフォーマッタなしでコンパイルするため）
  • CustomAttributeTypeNameFormatter.cs: GetTypeByCustomAttributeTypeName への cref に4つのパラメータをすべて明記
  • UnmanagedPdbSymbolReader.cs: <paramref="punk" /> を <paramref name="pUnk"/> に修正
  • ILEmitter.cs: オーバーロードが複数ある ILEmitter.NewToken への曖昧な cref を、ILEmitter へのリンクと NewToken の <c> テキストに変更
  • AccessVerificationHelpers.cs: paramref の currentClass を正しいパラメータ名 currentType に修正（2箇所）

パフォーマンスへの影響

影響なし（コメントのみの変更）

関連Issue

#136017

その他

  • 検証: -p:GenerateDocumentationFile=true -p:TreatWarningsAsErrors=false を指定して ILVerification と ILCompiler.TypeSystem をReleaseビルドした結果、src/coreclr/tools 配下のファイルにドキュメント関連の診断は出ませんでした。通常のReleaseビルドは警告0・エラー0で、ILVerification.Tests は501件中501件が成功しています。
  • ILCompiler.TypeSystem のビルドで参照される src/tools/illink には別のドキュメントコメント問題が残っていますが、本PRの対象外です。
  • 背景: #135989 での、Microsoft.ILVerification にXMLドキュメントファイルを同梱すべきかという議論の中で見つかったものです。メンテナーからは、共有型システムは他者が依存できるものとして文書化すべきではないとの説明がありました。

#136014 [wasm] Bump chrome for testing - linux: 155.0.8059.84, windows: 155.0.8059.85, mac: 155.0.8059.85

概要

WebAssembly（wasm）テストで使用する Chrome for Testing のバージョンを更新する自動PRです（作成者: github-actions[bot]）。各OS向けの更新後バージョンは以下のとおりです。

  • Linux: 155.0.8059.84
  • Windows: 155.0.8059.85
  • macOS: 155.0.8059.85

変更内容

  • eng/testing/BrowserVersions.props（+6/-6）
    • ブラウザテストで利用する Chrome のバージョン定義を、上記の値に更新しています。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

なし

#136013 Use memory.copy for the memmove QCall on browser-wasm

概要

browser-wasm 向け CoreCLR で、memmove の QCall を emscripten libc (musl) の memmove 直結から、__builtin_memmove を呼ぶ小さなラッパーに切り替える変更です。

  • 従来の emscripten libc (6.0.2) の memmove は、非オーバーラップ時は memcpy（n >= 512 で memory.copy）に転送しますが、オーバーラップ時は -mbulk-memory の有無にかかわらず常にスカラーループで処理していました。
  • SpanHelpers.Memmove はオーバーラップするバッファを memmove QCall に渡すため、CoreCLR wasm 上の Span<T>.CopyTo / Array.Copy のオーバーラップ時が Mono インタープリター（jiterpreter が memory.copy を出力）より大幅に遅くなっていました（Mono interpreter と CoreCLR composite R2R の比較で Span<Char>.CopyToOverlap(Size: 3000) が約20倍、Span<Byte>.CopyToOverlap(Size: 3000) が約13.6倍遅い）。
  • __builtin_memmove は -mbulk-memory 有効時に memory.copy へ lowering されます。
  • ブラウザ専用の変更で、wasi-sdk 34.0 は memmove に既に memory.copy のパスがあるため影響を受けません。

変更内容

  • src/coreclr/vm/qcallentrypoints.cpp（+21/-0）: browser 向けの memmove QCall を __builtin_memmove を呼ぶラッパーにバインドするよう変更。emsdk に emscripten-core/emscripten#27654（__builtin_wasm_memory_copy による memmove、emscripten 6.0.10+）が入ったらラッパーを削除する旨の TODO を記載。
  • src/libraries/System.Private.CoreLib/src/System/SpanHelpers.ByteMemOps.cs（+2/-0）: 変更行数は +2 のみで、内容は提供情報からは不明です。

パフォーマンスへの影響

composite R2R の browser-wasm publish（PublishReadyToRun=true）、Release、node 上で、オーバーラップするバイト CopyTo（dest = src + 1）を計測した結果（1呼び出しあたり ns）:

Size Before After
1024 292 29
3000 782 44
6000 1520 74
12000 3030 136
  • 非オーバーラップの対照ケースは変化なし（3000で約43ns、6000で約125ns）。
  • ベンチマークは dotnet/performance の Span<T>.CopyToOverlap 形式です。
  • 計測は arm64 macOS 1台のみで、同一マシン上で Mono は計測していません。

関連Issue

#136012（emsdk のバンプを追跡）

その他

  • 検証内容: browser-wasm Release で clr.native と clr+libs+packs をビルドし、オブジェクトに memory.copy が含まれることを確認。上記の R2R publish ベンチマークも実行。
  • 未実施: ライブラリ／ランタイムのテストスイートの実行、WASI のビルド・テストは行っていません。
  • 本PRの説明文は GitHub Copilot の支援で作成されたものです。

#135994 ilverify: allow ldsflda of initonly static fields outside the cctor

概要

ILVerifyにおいて、initonly な静的フィールドに対する ldsflda を、静的コンストラクタ（cctor）外でも許可するよう変更するPRです。インスタンスフィールドの ldflda と同様に InitOnly チェックを外し、ストア命令（stsfld 等）のチェックは従来どおり維持されます。

変更内容

  • src/coreclr/tools/ILVerification/ILImporter.Verify.cs: ldsflda に対する InitOnly チェックを削除（+1/-2）
  • src/coreclr/tools/ILVerification.Tests/ILTests/FieldTests.il: 新しいテストケースを追加（+9/-1）。作成者によると、このケースは main では失敗し、修正後は成功します
  • docs/design/specs/Ecma-335-Augments.md: 仕様の補足ドキュメントを追記（+5）

影響範囲は ILVerify（検証ツール）の内部実装であり、ランタイムの実行時動作や公開APIの変更は提供情報からは確認できません。

パフォーマンスへの影響

影響なし

関連Issue

  • #94090（この変更で修正）
  • #57444（ldflda で同様の対応を行った先行変更）
  • #112081（本PRの方針が提案されたIssue）

その他

  • ldsflda で initonly フィールドのアドレスを取得する場合、cctor外でも検証エラーにならなくなります。書き込み（ストア）側のチェックは維持されます。
  • 提供情報からは、互換性への影響（破壊的変更・非推奨化）、セキュリティ修正、ベンチマーク結果の有無は確認できません。

#135993 Managed ilasm: do not refer to native ilasm in comments

概要

managed ilasm（src/tools/ilasm）のコメントから、ネイティブ ilasm への言及を取り除く変更です。#135932 のレビューで @jkotas が「コメントはネイティブ ilasm を参照せず、それ単体で理解できるようにすべき（互換性のために残している不自然な挙動を除く）」と指摘したことを受け、#135311、#135297、#135289 で追加したコメントに適用しています。 ネイティブ ilasm との比較で説明していたコメントは、コードが従うルールそのものを記述する形に書き換え、単なる補足（「As in native ilasm, ...」など）だった記述は削除しています。互換性維持のための挙動を説明していたコメントは対象に含まれていません。

変更内容

  • ILAssembler 配下: GrammarActions.BuildImage.cs、GrammarActions.MethodBodies.Locals.cs、ILAssemblerPEBuilder.cs、Options.cs、PdbDocumentTable.cs のコメントを修正
  • ilasm 配下: OutputFileWriter.cs、Program.cs のコメントを修正
  • テスト: CompilerOptionsTests.cs、LocalScopeTests.cs、LocalTests.cs、PdbDocumentTests.cs、SourceDirectiveTests.cs、および GeneratedCases/LocalScopeCaseGenerator.cs、GeneratedCases/PdbCaseGenerator.cs のコメントを修正
  • テスト名の変更: SlotGapReusedSlotAndShadowedNameInTryAndCatchBodies_GiveTheRowsOfNativeIlasm の接尾辞を GiveARowForEachScope に変更（他にこの名前を参照する箇所はないとのこと）
  • 上記のテスト名変更を除き、コメントのみの変更です。

パフォーマンスへの影響

影響なし（コメントとテスト名の変更のみで、動作の変更はありません）

関連Issue

その他

  • 同種のコメント 12 行は本 PR の対象外です。うち 6 行は #135312 に含まれる変更に関わるため同 PR 側で修正済みとされ、残り 6 行は #135932 ですでに同様の修正が行われています。
  • 作成者によれば、この変更は AI（Anthropic Claude と OpenAI Codex）の支援のもとで作成され、投稿前に作成者本人がレビューしています。

#135974 Use geometric body buffer growth in HTTP loopback servers

  • 作成者: @agocke
  • 作成日時: 2026年10月16日 19:53:17(UTC)
  • マージ日時: 2026年10月18日 01:05:46(UTC)
  • ラベル: area-System.Net.Http

概要

HTTP/1.1のチャンク形式リクエストおよびHTTP/2のDATAフレームのボディ受信バッファを、チャンク／フレームごとに正確なサイズで再確保する方式から、容量を幾何級数的に拡大する方式へ変更しています。従来は固定サイズの断片を受信するたびに蓄積済みボディ全体をコピーしていたため、2次関数的なコピーコストが発生していました。この変更により、ループバックサーバーで大きなペイロードを扱う一部のテストが、作成者の環境で「数分から数秒」に短縮されたとのことです。

変更内容

  • src/libraries/Common/tests/System/Net/Http/GenericLoopbackServer.cs (+13/-0): バッファ拡張用の共通処理が追加されています（詳細な実装内容は提供情報からは不明）。
  • src/libraries/Common/tests/System/Net/Http/Http2LoopbackConnection.cs (+9/-6): HTTP/2のDATAフレームのボディバッファを幾何的に拡張する方式に変更しています。
  • src/libraries/Common/tests/System/Net/Http/LoopbackServer.cs (+9/-6): HTTP/1.1のチャンク形式リクエストのボディバッファを幾何的に拡張する方式に変更しています。

主な技術的ポイント:

  • 使用済み長と容量を別々に管理します。
  • 容量が不足する場合は倍増させ、より大きな断片が来た場合は必要サイズまで直接拡張します。
  • 戻り値を返す直前に1回だけトリミングします。
  • 返却されるボディの長さ、および null と空の扱いは従来どおり維持されます。
  • 投機的な容量は配列長の上限で頭打ちにし、必要長の計算にはcheckedな算術を使用します。

なお、変更対象はすべてテスト用ヘルパー（Common/tests配下）であり、公開APIやランタイム／ライブラリ本体の実装への影響はありません。

パフォーマンスへの影響

  • テスト用ループバックサーバーの処理が対象です。ボディ蓄積時のコピーが2次関数的から償却線形へ改善され、大きなペイロードを使うテストが作成者のマシンで数分から数秒に短縮されたと報告されています。
  • 具体的なベンチマーク数値は提供されていません。
  • 容量を投機的に確保するため、一時的に必要量以上のメモリを使用する可能性がありますが、返却前にトリミングされます。
  • ランタイム本体の性能への影響はありません。

関連Issue

なし

その他

  • 互換性への影響（破壊的変更・非推奨化）に関する記載はありません。
  • セキュリティ脆弱性修正やCVEに関する記載はありません。

#135943 [NativeAOT] Hash relocations in method body folding keys

概要

NativeAOT (ILCompiler) のメソッド本体フォールディング（重複排除）において、MethodInternKey のハッシュにリロケーション（再配置情報）を含めるよう変更しました。従来はコードバイト・GC情報・フレーム情報・EHバイトのみをハッシュしていたため、リロケーション先だけが異なるメソッド本体が同一ハッシュ値となり、同じ HashSet バケットに集中して AreSame の比較が O(n²) になっていました。特に最適化済みコードでは、async メソッドごとに生成されるステートマシン構造体のため、AsyncStateMachineBox<TResult, TSM>.MoveNext や AsyncMethodBuilderCore.Start<TSM> などがバイト列同一のコピーとして大量に発生し、この問題が顕著になります。

変更内容

  • src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/MethodBodyDeduplicator.cs (+29/-2)
    • ハッシュ計算にリロケーション情報を追加し、MethodInternComparer.AreSame の比較ロジックと整合させています。
      • リロケーション種別とオフセット: AreSame で厳密比較されるため、そのままハッシュに含めます。
      • MethodReadOnlyDataNode のターゲット: AreSame が内容比較するため、データバイトをハッシュに含めます（比較対象の部分集合）。
      • その他のターゲット: 前回パスのリマッピングを通した後のターゲットの同一性（identity）をハッシュします。AreSame は remapping[t1] == t2（またはその逆）を等価とみなしますが、リマッピングの値はキーにならない（キーになるのは既存の本体と一致した本体のみで、セット内の本体はキーにならない）ため、双方とも id(t2) をハッシュします。
    • Equals が受理するペアの集合は不変で、バケット分布のみが変わります。反復順序は従来どおりソート済みの GetCompiledMethodBodies() で、ISymbolNode はすでに identity でハッシュされます。そのため出力は変わりません。

パフォーマンスへの影響

コンパイル時間（ILC実行時間）が大幅に改善されます（v10.0.13 に同変更を適用、osx-arm64 ホスト・M1 Pro での計測）。

変更前 変更後
iOSアプリ（約12,000 async メソッド）ILC実行時間 約1200秒 247〜252秒
同、--methodbodyfolding:none 252秒
8000個の async Task<int> メソッドのサンプル dotnet publish 271秒 16秒
同サンプル、4000メソッド 47秒 9秒
  • すべてのケースで、生成されるオブジェクトファイルは未修正コンパイラとバイト単位で同一でした（iOSアプリの 1.19 GB の .o（2回実行）およびサンプルの .o）。
  • __managedcode はフォールディングによるサイズ削減効果を維持しています（フォールディングなし 80.0 MB に対し 69.3 MB）。

関連Issue

その他

#135911 Remove support for BigInteger in generated ASN types

  • 作成者: @bartonjs
  • 作成日時: 2026年10月16日 00:39:04(UTC)
  • マージ日時: 2026年10月18日 21:17:13(UTC)
  • ラベル: area-System.Security

概要

生成されるASN.1型における BigInteger のサポートを削除するPull Requestです。DssParms を除けば、基本的に Int32 または ReadOnlyMemory が必要とされるため、BigInteger を必要とする箇所（DSAキー処理）のみで変換を行い、ジェネレーター側のコードを削減しています。

変更内容

  • asn.xslt: BigInteger 用の生成テンプレートを削除
  • asn.xsd: 整数フィールドに対して明示的なバッキング型の指定を必須化
  • DssParms.xml / DssParms.xml.cs: DSAパラメーターをエンコード済み整数のバイト列（span）として保持・デコードするよう変更
  • DSAKeyFormatHelper.cs: エンコード済みDSAパラメーターを、この箇所でローカルに BigInteger へ変換するよう変更
  • CertificationRequestInfoAsn.xml / CertificationRequestInfoAsn.xml.cs: 証明書要求のバージョンを int として扱い、整数のバッキング型を指定

パフォーマンスへの影響

影響なし（提供された情報にはパフォーマンスに関する記述やベンチマーク結果はありません）。

関連Issue

なし

その他

  • Copilotのレビューでは、コレクション用スキーマ（IntegerCollectionType）がジェネレーターで非対応となった BigInteger 定義を依然として受け付けてしまう点が指摘されています（重要度: High）。バッキング型を int または ReadOnlyMemory に制限することが推奨されています。
目次