注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
- #123359 Fix typo in ifdef for Rune
- #123353 Fix WASM debugger breakpoints not hitting after Terser 5.39+.
- #123335 [browser] Fix NETSDK1022: Duplicate 'Content' items for Microsoft.Extensions.Configuration.Functional.Tests
- #123333 [NativeAOT] Source to native mapping fix for out-of-order code
- [#123332 browser][coreCLR] fix streaming instatiation for NodeJS
- [#123331 browser][coreCLR] apply runtime options
- #123288 Fix BFloat16.Significand to be byte-sized and correct TryWriteSignificand methods
- #123235 Simplify branching in ILImporter.Scanner.cs with Debug.Assert
- #119840 [S390X] remove redundant load
- #105403 SunOS process and thread support
#123359 Fix typo in ifdef for Rune
- 作成者: @vcsjones
- 作成日時: 2026年01月19日 18:21:45(UTC)
- マージ日時: 2026年01月19日 20:39:10(UTC)
- ラベル: area-System.Runtime
概要
Rune.cs のプリプロセッサディレクティブに存在するタイポを修正しました。SYSTEM_PRIVATE_CORLIB が誤った表記で、正しくは SYSTEM_PRIVATE_CORELIB です。このタイポにより、System.Private.CoreLib ビルド時に ArgumentException が期待されたカスタム例外メッセージを使用できていませんでした。
変更内容
- src/libraries/System.Private.CoreLib/src/System/Text/Rune.cs
- プリプロセッサディレクティブの修正(1行追加、1行削除)
#if SYSTEM_PRIVATE_CORLIB→#if SYSTEM_PRIVATE_CORELIBに変更
パフォーマンスへの影響
影響なし
関連Issue
なし
その他
- このタイポは軽微な問題で、ビルド時のプリプロセッサディレクティブの評価に影響するのみ
- System.Private.CoreLib のビルド時に条件付きコンパイルが正常に機能するようになり、適切な例外メッセージが使用される
- 例外メッセージ自体のテストについては、通常ユニットテストの対象外だが、必要に応じて追加可能
#123353 Fix WASM debugger breakpoints not hitting after Terser 5.39+.
- 作成者: @ilonatommy
- 作成日時: 2026年01月19日 15:40:28(UTC)
- マージ日時: 2026年01月19日 20:40:13(UTC)
- ラベル: area-Debugger-mono
概要
Terser 5.39+による最適化により、WASM デバッガのブレークポイントが機能しなくなっていた問題を修正します。Terser が console.assert(true, ...) を不要な処理として削除していたため、デバッガプロキシがポーズ中のスコープから変数を読み取ることができなくなっていました。true を !!Date.now() に置き換えることで、Terser による静的最適化を回避しつつ、ランタイムでは true として評価されます。
変更内容
- src/mono/browser/runtime/debug.ts
console.assert(true, ...)の呼び出し 2 箇所をconsole.assert(!!Date.now(), ...)に変更- Terser の静的最適化を回避するための説明コメント追加
- 計 10 行の変更(追加 6 行、削除 4 行)
パフォーマンスへの影響
軽微な影響あり:Date.now() の呼び出しが追加されますが、この処理はデバッガ機能の初期化フェーズでのみ実行されるため、実行時のパフォーマンス低下は無視できるレベルです。むしろデバッガの正常動作によるアプリケーション開発効率の向上が得られます。
関連Issue
#123353
その他
- このバグは .NET 11 のデバッグに影響します(.NET 10 では正常に動作)
- 根本原因は外部ツール(Terser)の仕様変更であり、ビルドチェーンの脆弱性を露呈させています
- 本修正は、ツールの静的解析を逃れる常套手段(
!!Date.now()による動的評価)を採用しています
#123335 [browser] Fix NETSDK1022: Duplicate 'Content' items for Microsoft.Extensions.Configuration.Functional.Tests
- 作成者: @pavelsavara
- 作成日時: 2026年01月18日 20:28:24(UTC)
- マージ日時: 2026年01月19日 13:28:53(UTC)
- ラベル: area-Build-mono os-browser
概要
Microsoft.Extensions.Configuration.Functional.Tests プロジェクトにおいて、NETSDK1022 ビルド警告(重複した 'Content' アイテム)を修正しました。SDK がデフォルトで .json と .xml ファイルを Content アイテムとして自動インクルードするのを防ぐため、プロジェクトファイルに <EnableDefaultContentItems>false</EnableDefaultContentItems> を追加しています。
変更内容
- Microsoft.Extensions.Configuration.Functional.Tests.csproj (+6/-1)
<EnableDefaultContentItems>false</EnableDefaultContentItems>を追加して、SDK のデフォルト Content アイテム自動インクルード機能を無効化- これにより、手動で指定された Content アイテムとの重複を防止
パフォーマンスへの影響
影響なし
関連Issue
https://github.com/dotnet/runtime/issues/123237
その他
- この変更は破壊的変更ではなく、ビルド警告を解決する軽微な修正
- プロジェクトファイルの設定変更のみで、ランタイム動作への影響はない
- テスト プロジェクトの構成最適化であり、必要に応じて明示的に Content アイテムを指定する必要がある場合がある
#123333 [NativeAOT] Source to native mapping fix for out-of-order code
- 作成者: @rcj1
- 作成日時: 2026年01月18日 18:22:42(UTC)
- マージ日時: 2026年01月19日 07:00:40(UTC)
- ラベル: area-NativeAOT-coreclr
概要
NativeAOTにおいて、非順序なコード配置時のソース行属性の誤りを修正するPRです。コンパイラ最適化により、IL オフセットが低いコードが高いネイティブオフセットに配置される場合、デバッガの行マッピングが不正になる問題を解決しています。CoreCLR のデバッガアルゴリズムと同様に、IL オフセットの低下を検出した際にシーケンスポイントを挿入することで、ソース行の正確な属性付けを実現します。
// 例:async/await メソッドで suspension コードが誤った行に属していた問題
static async Task DoWork(int i)
{
Task worker1 = BackgroundWorker1();
Task worker2 = BackgroundWorker2();
Task worker3 = BackgroundWorker3();
await Task.WhenAll(worker1, worker2, worker3); // 修正前:ここより後のコードが次の行に誤属性
Console.WriteLine("All background workers completed.");
}
変更内容
- ファイル:
src/coreclr/tools/aot/ILCompiler.RyuJit/Compiler/DependencyAnalysis/MethodCodeNode.csGetNativeSequencePoints()メソッドの改修(+20/-3)- IL オフセットの低下検出時にネイティブシーケンスポイントを挿入
IsBackedSequencePointフラグの導入で、実際のシーケンスポイントと伝播されたシーケンスポイントを区別
パフォーマンスへの影響
影響なし。本変更はデバッグ情報のメタデータのみに関わり、ランタイム実行速度やメモリ使用量に影響しません。
関連Issue
なし(PR番号 #123333)
その他
- 互換性: 破壊的変更なし。デバッグ情報の精度向上のみ
- テスト環境: Windows x64 Debug、.NET 11.0.100-alpha.1.25618.104 で検証
- 具体例: Native offset 431 以降の suspension コードが、修正前は行 85 に誤属性されていたのに対し、修正後は行 84 に正しく属性されるようになった
- 技術背景: async/await パターンで Task.WhenAll 等の await 後のコードが最適化により IL オフセット上は低い位置に生成されるが、ネイティブコードでは高いオフセットに配置される現象に対応
#123332 [browser][coreCLR] fix streaming instatiation for NodeJS
- 作成者: @pavelsavara
- 作成日時: 2026年01月18日 17:43:18(UTC)
- マージ日時: 2026年01月19日 14:33:40(UTC)
- ラベル: arch-wasm area-Host os-browser
概要
このPRはNode.js環境でのストリーミングインスタンシエーション処理を修正します。ネイティブResponseクラスが利用可能な場合はそれを使用し、WebAssemblyのストリーミング有効化に必要な適切なContent-Typeヘッダーをアセットに付与するようになりました。
// 概念的な変更イメージ
// 修正前: フォールバック実装のみ
// 修正後: 実環境で利用可能なResponseクラスを優先使用
var response = responseLike(body, {
headers: { 'Content-Type': 'application/wasm' }
});
変更内容
| ファイル | 変更内容 |
|---|---|
src/native/corehost/browserhost/loader/polyfills.ts |
responseLikeヘルパー関数を新規追加。ネイティブResponseコンストラクタが利用可能な場合はそれを使用、不可能な場合はフォールバック実装を提供。fetchLike関数を更新しexpectedContentTypeパラメータを受け取り、レスポンス作成時に活用 |
src/native/corehost/browserhost/loader/assets.ts |
behaviorToContentTypeMapを新規追加してアセット動作とMIMEタイプのマッピングを実装。runtimeToBlazorAssetTypeMapをbehaviorToBlazorAssetTypeMapに名前変更。loadResourceFetchを更新してコンテンツタイプとresponseLikeを使用 |
パフォーマンスへの影響
WebAssemblyモジュールのストリーミングインスタンシエーションが正常に動作することで、従来のバッファリング方式との比較において、メモリ効率の向上と初期化時間の短縮が期待されます。ただし、具体的なベンチマーク数値は提供されていません。
関連Issue
なし
その他
- この変更はブラウザ環境とNode.js環境の両方に対応するポリフィル実装です
- TypeScriptで実装され、Blazor/WebAssemblyランタイムのローダー部分に関わる重要な修正です
- Content-Typeヘッダーの適切な設定により、WebAssemblyの効率的なストリーミング読み込みが実現されます
#123331 [browser][coreCLR] apply runtime options
- 作成者: @pavelsavara
- 作成日時: 2026年01月18日 17:40:13(UTC)
- マージ日時: 2026年01月19日 15:22:11(UTC)
- ラベル: arch-wasm area-Host os-browser
概要
このPRは、WebAssembly/ブラウザ環境におけるCoreQLの初期化プロセスをリファクタリングし、ランタイム設定オプションを環境変数ではなく関数パラメータとして直接渡すように変更しています。これにより、リンカー機能が正常に動作するようになります。
// 変更前: 環境変数を経由してランタイムオプションを設定
// 変更後: initializeCoreCLRが直接プロパティをC++層に渡す
変更内容
- browserhost.cpp: 環境変数の読み込みからパラメータベースの構成に変更(-32行)
- host.ts: ランタイムプロパティを構築し、C++層にパラメータとして渡す新しいinitializeCoreCLR実装を追加(+51行)
- config.ts: runtimeConfig.runtimeOptions.configPropertiesの統合・正規化ロジックを追加
- libBrowserHost.footer.js: JS層から環境変数セットアップを削除し、依存関係を更新
- ems-ambient.ts: BrowserHost_CreateHostContractおよび更新されたInitializeCoreQLRの型定義を追加
パフォーマンスへの影響
環境変数を経由した文字列ベースの設定から、構造化されたパラメータによる直接的な設定に変更されるため、初期化時のオーバーヘッドが削減される可能性があります。ただし、具体的なベンチマーク数値は提供されていません。
関連Issue
なし
その他
- BrowserHost_CreateHostContract: 新しい関数が導入され、ホストコントラクト作成を初期化から分離
- 互換性: これはブラウザ/WASM専用の内部実装変更であり、公開APIへの影響はなし
- リンカー機能: 主な目的は、リンカーが初期化段階で利用可能なランタイムオプションを正しく処理できるようにすること
#123288 Fix BFloat16.Significand to be byte-sized and correct TryWriteSignificand methods
- 作成者: @Copilot
- 作成日時: 2026年01月16日 20:57:02(UTC)
- マージ日時: 2026年01月19日 17:28:22(UTC)
- ラベル: 指定なし
概要
BFloat16のSignificandプロパティとTryWriteSignificandメソッドのバグを修正しました。Significandが不正にushort型(16ビット)で定義されていたため、TryWriteSignificandBigEndianおよびTryWriteSignificandLittleEndianがbytesWritten = 4を誤って報告していました。BFloat16フォーマット(1ビット符号 + 8ビット指数 + 7ビット仮数)では、暗黙の先頭1ビットを含めると仮数部は8ビット(1バイト)となるため、Significandをbyte型に修正しました。
変更内容
BFloat16.cs
Significandプロパティをushortからbyte型に変更(正確には8ビット表現)GetSignificandByteCount()の戻り値をsizeof(ushort)(2)からsizeof(byte)(1)に修正TryWriteSignificandBigEndianとTryWriteSignificandLittleEndianを1バイト直接書き込みに変更(1バイトではエンディアンは無関係)
BFloat16Tests.cs
TryWriteSignificandBigEndianとTryWriteSignificandLittleEndianに包括的なテストカバレッジを追加[Theory]と[MemberData]を使用して複数のBFloat16テスト値(NegativeInfinity、MinValue、NaN、Epsilon、Zero、MaxValue、PositiveInfinity)でテスト- バイト数が1であることと出力値の正確性を検証
- 空の宛先エッジケースを別の
[Fact]メソッドで検証
パフォーマンスへの影響
影響なし。本変更は意味論的な修正で、実行時パフォーマンスには影響しません。ただし、メモリレイアウトは変わります(Significandは2バイトから1バイトに縮小)。
関連Issue
#123286(BFloat16.TryWriteSignificand{Big,Little}Endianが4をbytesWrittenとして報告する問題)
その他
- 修正により、BFloat16の
Significandプロパティが数値フォーマット仕様に正確に準拠するようになりました - テストでは
[MemberData]を使用してBFloat16オブジェクトを直接渡し、float-to-BFloat16変換の問題を回避しています - C#の最新コレクションリテラル構文
[ ... ]を使用してコードの保守性を向上させています
#123235 Simplify branching in ILImporter.Scanner.cs with Debug.Assert
- 作成者: @Copilot
- 作成日時: 2026年01月15日 23:38:05(UTC)
- マージ日時: 2026年01月19日 07:35:05(UTC)
- ラベル: 指定なし
概要
ILImporter.Scanner.cs の条件分岐を簡潔化するリファクタリングです。共有ジェネリックメソッドのコンテキスト取得方法が相互排他的な3つのパス(メソッド辞書、型辞書、thisポインタ)のいずれか一つであるという不変条件を強化するため、明示的な else if (targetMethod.AcquiresInstMethodTableFromThis()) を else { Debug.Assert(...); } に置き換えています。機能的な動作変更はありません。
変更内容
ファイル: src/coreclr/tools/aot/ILCompiler.Compiler/IL/ILImporter.Scanner.cs
変更箇所: exactContextNeedsRuntimeLookup ブランチ内の directCall パス
// Before
else if (targetMethod.AcquiresInstMethodTableFromThis())
{
_dependencies.Add(_factory.ShadowNonConcreteMethod(concreteMethod), reason);
}
// After
else
{
Debug.Assert(targetMethod.AcquiresInstMethodTableFromThis());
_dependencies.Add(_factory.ShadowNonConcreteMethod(concreteMethod), reason);
}
- 3行の変更(追加2行、削除1行)
- AOT コンパイラ内のジェネリックコンテキスト取得ロジックを整理
- 既存パターン(
CorInfoImpl.GetGenericRuntimeLookupKindなど)と統一
パフォーマンスへの影響
影響なし
Debug.Assert は DEBUG ビルドのみで評価されるため、Release ビルドのパフォーマンスに変化ありません。むしろコンパイラが冗長な条件分岐を最適化できる可能性があります。
関連Issue
なし
その他
- コードの意図をより明確にするリファクタリング(内部実装の変更、公開API変更なし)
- 不変条件を
Debug.Assertで明示することで、ジェネリックコンテキスト取得方法の排他性を検査時に強化 - codebase 全体の一貫性向上
#119840 [S390X] remove redundant load
- 作成者: @saitama951
- 作成日時: 2025年09月18日 09:43:11(UTC)
- マージ日時: 2026年01月19日 19:36:43(UTC)
- ラベル: area-Build-mono runtime-mono community-contribution
概要
S390Xアーキテクチャの命令生成コードから冗長なロード命令を削除しました。ins->dreg(浮動小数点レジスタ)とsreg(r13)は絶対に競合しないため、不要なロードが削除されています。
変更内容
- src/mono/mono/mini/mini-s390x.c: 冗長なロード命令を1行削除
- 変更内容:
ins->dregがFPR(浮動小数点レジスタ)で、sregがr13固定であることから、レジスタエイリアシングが発生しないため、不要なロード命令を削除
- 変更内容:
パフォーマンスへの影響
改善あり
- 不要な命令削除によりコード生成サイズが削減
- S390Xアーキテクチャにおける命令実行数が減少
- ロード命令が1つ削除されることで、わずかながら実行速度が向上
関連Issue
なし
その他
本変更はMonoランタイムの最適化であり、S390X固有の命令生成ロジックの改善です。変更は内部実装の最適化であり、APIやランタイム挙動への影響はありません。
#105403 SunOS process and thread support
- 作成者: @gwr
- 作成日時: 2024年07月24日 14:38:56(UTC)
- マージ日時: 2026年01月19日 11:23:00(UTC)
- ラベル: area-System.Diagnostics.Process port os-SunOS community-contribution
概要
このPRはSunOS(Solaris/illumos)プラットフォームに対するSystem.Diagnostics.Processのサポートを実装しています。procfsから読み取ったバイナリプロセス情報を利用して、プロセスとスレッドの情報取得機能を追加します。System.Diagnostic.Process.Testsでは大量のスキップがありますが、失敗は報告されていません。
変更内容
新規追加ファイル
Process.SunOS.cs:開始時刻、CPU時間計算などSunOS固有のプロセスプロパティ実装(136行)ProcessManager.SunOS.cs:SunOS上のプロセス管理と列挙処理(254行)ProcessThread.SunOS.cs:SunOS上のスレッド情報取得とプロパティマッピング(131行)Interop.ProcFs.GetProcessInfoById.cs:procfsからのプロセス情報読取(74行)Interop.ProcFs.GetThreadInfoById.cs:procfsからのスレッド情報読取(53行)
修正・削除ファイル
pal_io.c/h:SunOS向けのネイティブI/O処理追加(86行/42行)PlatformDetection.cs:SunOS検出ロジック追加Environment.SunOS.cs:作業セット取得をSunOS向けに更新Interop.ProcFsStat.TryReadProcessStatusInfo.cs:レガシーコード削除(37行)
パフォーマンスへの影響
影響なし。本変更はプラットフォーム固有の実装追加であり、既存プラットフォームのコードパスに変更はありません。SunOS上ではprocfsからのバイナリ読取により効率的な情報取得が可能になります。
関連Issue
なし
その他
- 大規模なレビュー履歴あり(100以上のレビュアーアクション)、特にjkotas、AustinWise、am11による詳細レビューあり
- 本実装はSunOS/illumosプラットフォームのみに影響し、既存のLinux/Windows向けコードへの破壊的変更なし
- Copilotの指摘として、
IsillumosのネーミングをIsIllumosに統一することが推奨されています