注意点
このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。
目次
- #123206 [main] Source code updates from dotnet/dotnet
- #123199 Update remaining efteam ownership area. Fix capitalization.
- #123193 [clr-interp] Fix linux x64 Interop test suite, and in general improve SysV struct classification
- #123180 Remove Debug.Assert from metadata entity struct constructors
- #123127 JIT: Remove unused isRecompute parameter from lvaMarkLclRefs
- #123084 Fix up hijacking on x86 (preserve async continuation register)
- #123020 [clr-interp] Improve the performance of ByteMark
- #122973 JIT: Make GS cookie phase run on LIR and move it after async phase
- #122917 Fix IndexOutOfRangeException when sending >2GB files on Windows
- #122389 Add coalescence optimization for AsyncEnumerable Append/Prepend/Concat operations
- #122012 ILC: track concrete dependencies of open generic methods
- #111101 ConfigurationBuilder.AddJsonFile can't fire OnChange event using relative paths
#123206 [main] Source code updates from dotnet/dotnet
- 作成者: @dotnet-maestro[bot]
- 作成日時: 2026年01月15日 08:52:28(UTC)
- マージ日時: 2026年01月15日 23:48:34(UTC)
- ラベル: needs-area-label
概要
このPRは、dotnet/dotnetリポジトリからの定期的なCodeflow更新です。複数の依存パッケージがバージョンアップされ、主にコンパイラツール(Roslyn、CodeAnalysis)、ビルドタスク、NuGetツール、ランタイムコンポーネントが更新されています。破壊的な変更はなく、主にメンテナンスと最新化を目的とした更新です。
変更内容
- ビルド設定ファイル:
Directory.Build.props、global.json、バージョン定義ファイルを更新 - コンパイラ・解析ツール: Microsoft.CodeAnalysis系パッケージを5.4.0-2.26062.101→5.4.0-2.26064.120へ更新
- ビルドタスク: Microsoft.DotNet.Build.Tasks.*パッケージを11.0.0-beta.26062.101→11.0.0-beta.26064.120へ更新
- ランタイム関連: Microsoft.NETCore.App.Ref、System.Reflection.Metadata、System.Text.Jsonを11.0.0-alpha.1系へ更新
- NuGetツール: NuGet.Frameworks、NuGet.Packaging等を7.3.0-preview.1.6301→7.3.0-preview.1.6520へ更新
- プロジェクトファイル: AOT compiler、Crossgen2、WebAssemblyなど複数の.csproj/.propsファイルのバージョン参照を更新
- 関連リポジトリの変更: efcore、fsharp、msbuild、nuget.client、razor、roslyn、runtimeの各リポジトリからの変更を統合
パフォーマンスへの影響
影響なし。本PRは依存パッケージの定期更新であり、パフォーマンス関連の変更は含まれていません。
関連Issue
なし
その他
- このPRはCodeflow自動化システムにより生成されたメンテナンスPRです
- ビルド日時: 2026年1月15日 2:56 UTC
- 8つのソースリポジトリからの変更が統合されています
darc vmr diffコマンドで詳細な差分を確認可能
#123199 Update remaining efteam ownership area. Fix capitalization.
- 作成者: @jeffhandley
- 作成日時: 2026年01月14日 23:55:54(UTC)
- マージ日時: 2026年01月15日 00:25:43(UTC)
- ラベル: documentation area-Meta
概要
Entity Framework チーム(@dotnet/efteam)の所有権情報を更新するフォローアップPRです。GitHub ユーザー名の大文字小文字の統一(@sammonort → @SamMonoRT)と、System.Transactions エリアの所有者を個別メンテナーから @dotnet/efteam チームに統一しました。これは前回の PR #122357 のマージ後に受け取ったレビューフィードバックに対応するものです。
変更内容
- docs/area-owners.md: System.Data、System.Data.Odbc、System.Data.OleDB、System.Transactions エリアのリード名を大文字小文字で統一。System.Transactions の所有者を
@rojiと@cincuranetから@dotnet/efteamに変更 - .github/policies/resourceManagement.yml: ドキュメント変更と同期させるため、通知購読者のユーザー名大文字小文字を修正し、チーム参照を統一
パフォーマンスへの影響
影響なし
関連Issue
#122357(Sync area notification subscribers with area-owners.md)
その他
この変更は内部的なメタデータ・自動化設定の更新であり、ランタイム機能やAPI には直接影響しません。ドキュメントと自動化設定の整合性を確保するメンテナンス作業です。
#123193 [clr-interp] Fix linux x64 Interop test suite, and in general improve SysV struct classification
- 作成者: @davidwrighton
- 作成日時: 2026年01月14日 20:01:40(UTC)
- マージ日時: 2026年01月15日 03:39:30(UTC)
- ラベル: area-VM-coreclr area-CodeGen-Interpreter-coreclr
概要
Linux x64上の相互運用テストスイートの失敗を修正するため、SystemV ABI struct分類メカニズムを改善しました。ArgIteratorがマーシャルされた構造体のSysV struct分類を正しく計算できていなかった問題をPInvokeArgIteratorの使用により解決。さらに分類データのキャッシング効率を向上させ、EEClassOptionalFieldsのサイズを40バイトから24バイトに削減しています。
変更内容
- ArgIterator修正: managed-to-native/native-to-managed遷移でSysV struct分類が正しく行われるよう修正
- 新規構造体導入:
SystemVEightByteRegistersInfoを導入し、複数の分類フィールドを単一構造体に統合(class.hで複数フィールドから1フィールドに削減) - キャッシング最適化: JITが構造体の分類キャッシュを活用し、再計算を回避(
jitinterface.cpp) - 呼び出しスタブ生成: PInvokeArgIteratorを用いてアンマネージ呼び出し規約に対応(
callstubgenerator.cpp) - 各種呼び出し側更新:
method.cpp、comdelegate.cpp、argdestination.hなど14ファイルを修正
パフォーマンスへの影響
改善点:
- メモリ削減: EEClassOptionalFieldsが40バイトから24バイトに縮小(Unix AMD64平台、40%削減)
- 計算効率化: JITが分類キャッシュを再利用するため、構造体分類の繰り返し計算が削減
- struct passageの最適化: SystemV ABI準拠で、レジスタ経由の構造体引き渡しが効率化
関連Issue
#123193(タイトルから確認可能)
その他
- 内部実装の改善であり、公開APIへの破壊的変更なし
- Linux x64相互運用テストの回帰修正を主目的とした変更
- PInvokeArgIteratorクラスが新規導入され、arg iteration処理が統一化
#123180 Remove Debug.Assert from metadata entity struct constructors
- 作成者: @Copilot
- 作成日時: 2026年01月14日 16:10:51(UTC)
- マージ日時: 2026年01月15日 12:44:01(UTC)
- ラベル: area-System.Reflection.Metadata
概要
ref-emitted(動的生成)コード内のスタックトレース生成失敗を解決するため、30個のメタデータエンティティ構造体コンストラクタからDebug.Assert(!handle.IsNil)を削除しました。XUnitが例外スタックトレースをキャプチャする際、動的生成メソッドからnilハンドルが返されると、デバッグビルドでアサーション失敗によりスタックトレース生成が中断されていました。
修正により、構造体をnilハンドルで作成可能になり、プロパティアクセス時にBadImageFormatExceptionがスローされるようになります(AssemblyReference.VersionはWinMD mscorlib参照向けの特別な処理により、nilハンドルで4.0.0.0を返します)。
変更内容
- TypeSystem (23ファイル): AssemblyFile, AssemblyReference, Constant, CustomAttribute, DeclarativeSecurityAttribute, EventDefinition, ExportedType, FieldDefinition, GenericParameter, GenericParameterConstraint, InterfaceImplementation, ManifestResource, MemberReference, MethodDefinition, MethodImplementation, MethodSpecification, ModuleReference, Parameter, PropertyDefinition, StandaloneSignature, TypeDefinition, TypeReference, TypeSpecification
- PortablePdb (7ファイル): CustomDebugInformation, Document, ImportScope, LocalConstant, LocalScope, LocalVariable, MethodDebugInformation
各ファイルからDebug.Assert(!handle.IsNil)とDebug.Assert(reader != null)を削除し、不要なusing System.Diagnostics;ディレクティブをクリーンアップしました。
パフォーマンスへの影響
影響なし。本変更はアサーションの削除(デバッグビルドのみ)と不使用ディレクティブの削除であり、実行時コードパスに変更はありません。
関連Issue
dotnet/runtime#26440 - Assert in MethodDebugInformation ctor when generating stack in invalid generated code
その他
- 30個の新規テストを追加(各構造体ごとに1つ)してnilハンドル動作を検証
- PortablePdb: 7テスト (
GetMethodDebugInformation_InvalidHandleなど) - TypeSystem: 23テスト (
GetAssemblyFile_InvalidHandleなど) - テストはnilハンドルで作成された構造体のプロパティアクセス時に
BadImageFormatExceptionがスローされることを確認
#123127 JIT: Remove unused isRecompute parameter from lvaMarkLclRefs
- 作成者: @Copilot
- 作成日時: 2026年01月13日 14:37:33(UTC)
- マージ日時: 2026年01月15日 13:13:39(UTC)
- ラベル: 指定なし
概要
JIT コンパイラの lvaMarkLclRefs および lvaMarkLocalVars メソッドから、常に false で渡されていた未使用の isRecompute パラメータを削除しました。この変更は、既存のアサーション("Stop passing isRecompute once we are sure that this assert is never hit")で確認された死コードの削除です。
変更内容
- compiler.h:
lvaMarkLclRefsおよびlvaMarkLocalVars(BasicBlock*, bool)の関数シグネチャからbool isRecomputeパラメータを削除(+2/-2 行) - lclvars.cpp:
lvaMarkLclRefsとlvaMarkLocalVarsの実装からisRecomputeパラメータを削除if (!isRecompute)条件分岐を削除(条件付きコードが無条件実行に変更)MarkLocalVarsVisitorクラスからm_isRecomputeメンバ変数を削除lvaComputeRefCountsの呼び出しサイトを更新(+65/-74 行)
- importer.cpp: 上流の main ブランチからのマージにより、
impGetNodeAddrの欠落パラメータに関する修正を組み込み
パフォーマンスへの影響
影響なし。本変更は死コードの削除であり、実行時の動作に変化はありません。
関連Issue
なし
その他
- 破壊的変更: なし。公開 API ではなく内部実装の変更です
- 互換性: 完全に後方互換性を維持します
- リスク評価: 最小限。パラメータが証明可能な未使用状態(assert で確認)であるため、純粋な形式的変更です
#123084 Fix up hijacking on x86 (preserve async continuation register)
- 作成者: @eduardo-vp
- 作成日時: 2026年01月12日 11:28:52(UTC)
- マージ日時: 2026年01月15日 23:44:41(UTC)
- ラベル: area-NativeAOT-coreclr runtime-async
概要
x86プラットフォームにおいて、GC(ガベージコレクション)実行時に非同期継続(async continuation)を保持するレジスタ(ecx)をマーク対象に追加する修正です。.NET CLRのABI仕様に定義されている非同期呼び出し規約に準拠し、GCプローブ中にecxレジスタが保護されるようになります。
変更内容
- src/coreclr/nativeaot/Runtime/i386/GcProbe.asm (+13/-8): GC実行時にecxレジスタをマーク対象に追加し、非同期継続値の破壊を防止
- src/coreclr/nativeaot/Runtime/i386/AsmMacros.inc (+1/-0): GC関連マクロ定義の追加または修正
- src/coreclr/nativeaot/Runtime/inc/rhbinder.h (+2/-2): ヘッダーファイルの軽微な変更
パフォーマンスへの影響
GC実行時のレジスタ保護範囲が拡大されることで、わずかなオーバーヘッドが生じる可能性がありますが、非同期操作の正確な実行を保証するための必須の修正です。パフォーマンス回帰は軽微と予想されます。
関連Issue
- #122492 に貢献(x86での非同期継続に関する問題に対応)
その他
- x86(i386)プラットフォーム限定の修正
- NativeAOTランタイムに関連
- CLRのABI仕様「async calling convention」に準拠
#123020 [clr-interp] Improve the performance of ByteMark
- 作成者: @davidwrighton
- 作成日時: 2026年01月09日 00:56:33(UTC)
- マージ日時: 2026年01月15日 03:40:42(UTC)
- ラベル: area-CodeGen-Interpreter-coreclr
概要
ByteMarkベンチマークのインタープリター実行パフォーマンスを改善するPRです。チェックビルドで2~3倍の高速化を実現しています。主な改善は、(1) 配列アクセス時のOBJECTREFオーバーヘッド削減、(2) IL stubから呼び出されるインタープリターコードの直接キャッシング、の2つです。
変更内容
- src/coreclr/vm/interpexec.cpp: 配列要素アクセス(LDELEM/STELEM)でOBJECTREFの代わりに
ArrayBase*ポインタを使用し、必要な箇所でのみVALIDATEOBJECTを手動呼び出しに変更。検証オーバーヘッドを削減 - src/coreclr/vm/prestub.cpp: FixupPrecodeがInterpreterPrecodeを指す場合、バイトコードアドレスをMethodDescに直接キャッシュ。IL stub経由でのインタープリターコード呼び出し時の遷移コストを削減
- src/coreclr/vm/eventtrace.cpp: イベントトレース処理の調整(-16行削減)
パフォーマンスへの影響
改善あり(複数の側面)
- チェックビルド: ByteMarkの大部分で2~3倍の高速化。OBJECTREF削除によるバリデーション呼び出しの削減が主因
- リリースビルド: IL stubキャッシング機能により、解釈コードと非解釈コード間の遷移回数を削減。多次元配列アクセッサーで特に効果あり
- 懸念点: インタープリター実行パスは頻繁に実行されるため、検証ロジック削減の影響が累積。ただし手動VALIDATEOBJECT呼び出しにより検証自体は保持
関連Issue
なし
その他
- これは主にインタープリター実行エンジンに関連する最適化で、JIT実行パスには影響なし
- IL stubとインタープリターの相互作用パターンを最適化することで、アーキテクチャレベルでの効率改善を実現
- チェックビルド(デバッグ用の検証ビルド)での顕著な改善から、本来の問題がOBJECTREFの過度な検証オーバーヘッドであることが明確
#122973 JIT: Make GS cookie phase run on LIR and move it after async phase
- 作成者: @jakobbotsch
- 作成日時: 2026年01月07日 15:20:46(UTC)
- マージ日時: 2026年01月15日 19:28:08(UTC)
- ラベル: area-CodeGen-coreclr
概要
このPRは、GS(Guard Stack)クッキーのセキュリティチェック処理をJITコンパイラのパイプラインで後期段階(LIR)に移動させ、非同期変換の後に実行するように改善しています。従来はIR段階で実行されていたため、非同期メソッドの暗黙的なbyref パラメータとの組み合わせで、サスペンションポイントを越えて無効なポインタが生存する問題が発生していました。LIR段階での実行により、この問題を解決します。
変更内容
src/coreclr/jit/gschecks.cpp (+369/-340, 709行)
- GS cookie処理のロジックをLIR互換に全面的に書き換え
- 解析処理をLIR段階での実行に適応させ、IR挿入/書き直し処理も対応
- パラメータのシャドウイング処理をLIRで実行可能に修正
src/coreclr/jit/compiler.h (+13/-8, 21行)
- GS cookie処理の呼び出し順序制御に必要なインターフェース変更
src/coreclr/jit/compiler.cpp (+4/-4, 8行)
- コンパイルパイプラインでGS cookie処理の実行タイミングを非同期変換後に移動
パフォーマンスへの影響
影響なし。本PR は機能正確性の改善(バグ修正)であり、パフォーマンス上の変更は意図されていません。
関連Issue
#122954 - 非同期メソッドにおけるGS cookie処理と暗黙的byrefパラメータの組み合わせによる無効IR生成の問題
その他
- 互換性: 公開APIの変更なし。JIT内部の処理順序変更のため、ユーザーコードへの影響なし。
- セキュリティ: GS cookie自体の検証ロジックは変更なし。セキュリティ機能の有効性は維持されます。
#122917 Fix IndexOutOfRangeException when sending >2GB files on Windows
- 作成者: @Copilot
- 作成日時: 2026年01月06日 15:00:46(UTC)
- マージ日時: 2026年01月15日 17:06:01(UTC)
- ラベル: area-System.Net.Sockets
概要
PR #120634 で導入された >2GB ファイルのパーティショニング機能にIndexOutOfRangeExceptionバグが存在していました。パーティショニングにより1つのファイルが複数のSendPacketsElementに展開されるとき、_sendPacketsFileHandles配列のインデックス追跡が誤っていたため発生していました。修正では、パーティショニング時に並列配列_sendPacketsElementsFileHandleIndicesを構築し、各要素がどのファイルハンドルを使用するかを追跡するようにしました。
// 修正前: インデックスカウンタがファイルハンドル数を超える
// File 2.1GB → 2要素に展開, File 1MB → 1要素
// カウンタ: 0, 1, 2 に対して _sendPacketsFileHandles は長さ2
// 修正後: 並列配列で正確にマッピング
// _sendPacketsElementsFileHandleIndices: [0, 0, 1]
// 各要素が正しいハンドルインデックスを記録
変更内容
- ファイル:
src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncEventArgs.Windows.cs- 並列追跡配列
_sendPacketsElementsFileHandleIndicesを新規追加 SetupPinHandlesSendPacketsメソッドで、ファイルパーティショニング時にハンドルインデックスを正確にマッピング- ファイル要素に対して
Debug.Assertを追加し、ハンドルインデックスが有効(-1でない)ことを検証 - パーティショニングがない場合は元のカウンタベースロジックへフォールバック
- 並列配列のクリーンアップ処理を実装
- 並列追跡配列
パフォーマンスへの影響
影響なし。パーティショニング時のみ追加メモリ(配列)を使用しますが、SetupPinHandlesSendPackets内のみの一時的な割り当てです。>2GBファイル送信時のみ実行される限定的なパスであり、通常のファイル送信(<2GB)は元のコード経路を使用するため、既存パフォーマンスへの影響はありません。
関連Issue
- Issue #122916:
[Test Failure] System.Net.Sockets.Tests.SendFile_NonParallel_Task.GreaterThan2GBFile_SendsAllBytes on Windows - PR #120634: ファイルパーティショニング機能の導入(12月1日マージ)
その他
- 回帰テスト: PR #120634 で追加された
GreaterThan2GBFile_SendsAllBytesテストで本修正を検証 - リスク評価: 低。変更がWindows特有のパーティショニングパスに限定され、複数ファイル、重複パス、混合要素タイプなどエッジケースに対応
- Windows CI: >2GBファイルシナリオを検証予定
#122389 Add coalescence optimization for AsyncEnumerable Append/Prepend/Concat operations
- 作成者: @Copilot
- 作成日時: 2025年12月10日 15:52:59(UTC)
- マージ日時: 2026年01月15日 14:46:39(UTC)
- ラベル: area-System.Linq tenet-performance
概要
AsyncEnumerable の Append、Prepend、Concat 操作のパフォーマンス低下を解決するために、同期LINQ実装と同様の coalescence(合体)最適化を導入しました。これにより、連鎖した Append 操作で約900msから280μsへの大幅な性能改善が実現されます。
// 最適化前:深いネストされたイテレータ構造
var enumerable = AsyncEnumerable.Empty<int>();
for (int i = 0; i < 10000; i++)
enumerable = enumerable.Append(i); // 毎回新しいイテレータを生成
// 最適化後:操作が自動的に合体される
return await enumerable.SumAsync(); // 900ms → 280μs
変更内容
- AsyncIterator.cs (+90行):同期版
Iteratorクラスを非同期向けに移植した基底クラス - SingleLinkedNode.cs (+127行):単一リンクリスト構造の非同期実装(複数の操作を効率的に鎖状に管理)
- Append.cs (+220行):
AppendPrependAsyncIteratorを実装し、連鎖した Append/Prepend 操作を自動合体 - Prepend.cs (+3行):新しいイテレータパターンを使用するよう簡潔化
- Concat.cs (+216行):
ConcatAsyncIteratorを実装し、連鎖した Concat 操作を合体 - テストファイル (+416行):AppendTests、ConcatTests、PrependTests に1万個の操作チェーン、多重列挙、エッジケースなどを含む包括的テストを追加
パフォーマンスへの影響
大幅な改善: ベンチマーク結果では、10,000個の連続 Append 後の SumAsync が以下の通り改善されました:
- .NET 10(改善前):904.1 ms
- 本PR適用後:282.0 μs
- 改善率:約3,200倍
メモリ割り当ても 1.83MB から 1.34MB に削減。これは coalescence 最適化により、深いネストされたイテレータチェーンの代わりに、単一の効率的なリンクリスト構造を使用することで実現されます。
関連Issue
Issue #121542「Performance regression with AsyncEnumerable - Append, followed by SumAsync」
その他
- コード品質: CodeQL セキュリティチェック合格、テストカバレッジ 97.16%(行)、89.99%(分岐)、96.88%(メソッド)
- テスト検証: 613個の全テスト合格
- 互換性: 既存の public API に破壊的変更なし。この最適化は内部実装で自動的に適用されるため、ユーザーコードの変更は不要です
#122012 ILC: track concrete dependencies of open generic methods
- 作成者: @sbomer
- 作成日時: 2025年11月27日 01:24:19(UTC)
- マージ日時: 2026年01月15日 18:04:57(UTC)
- ラベル: area-NativeAOT-coreclr
概要
ILC(IL Compiler)において、RyuJitがジェネリックメソッドをインライン化する際に、部分的にインスタンス化された(open generic)メソッドの具体的な依存関係を追跡できていない問題を修正します。ShadowConcreteMethodNodeをShadowGenericMethodNodeに拡張し、完全にインスタンス化されていない一般的なメソッドの依存関係も追跡するようにしました。これにより、AOT コンパイル時にコード生成に必要な依存関係が確実に利用可能になります。
// 修正の対象例:Callee<object, T>がCaller<string>にインライン化される場合、
// Container<object>の依存関係が追跡されるようになります
static string Caller<T>() => Callee<object, T>();
変更内容
主要な変更:
ShadowConcreteMethodNode.cs→ShadowGenericMethodNode.csにリネーム、具体的メソッドのみという制限を削除ShadowNonConcreteMethodNode.csを新規追加し、部分的にインスタンス化されたジェネリックメソッドを追跡ReadyToRunGenericHelperNode.csで非具体的なインスタンス化の処理を追加
追跡対象の拡張(3つのエントリーポイント):
- リフレクション経由のジェネリックメソッドアクセス(
ReflectionInvokeMapNode.cs) - ジェネリック仮想メソッド(GVM)呼び出し(
GenericVirtualMethodImplNode.cs) - 直接呼び出し(
ILImporter.Scanner.cs)
参照更新: NodeFactory.cs、GenericDictionaryNode.cs、ILScanner.cs、RyuJitCompilation.cs の関連参照を更新
テスト追加: Generics.cs に GVM インライン化と異なる継承パターンをカバーする5つの包括的なテストケースを追加
パフォーマンスへの影響
影響なし。本変更は依存関係追跡の精度向上であり、スキャン時の追加処理により若干のコンパイル時間増加の可能性がありますが、実行時パフォーマンスには影響を与えません。むしろ、従来は実行時エラーで失敗していたケースがコンパイルできるようになります。
関連Issue
#120847 - Generic virtual method inlining with concrete dependencies
その他
INodeWithRuntimeDeterminedDependencies.csの軽微な変更(リネーム対応)GenericLookupResult.csが大幅拡張(163行追加)され、ジェネリック依存関係の処理ロジックが強化されました- 破壊的変更なし:既存の具体的メソッド追跡機能は継続して機能
#111101 ConfigurationBuilder.AddJsonFile can't fire OnChange event using relative paths
- 作成者: @pedrobsaila
- 作成日時: 2025年01月05日 22:18:35(UTC)
- マージ日時: 2026年01月15日 19:36:32(UTC)
- ラベル: area-Extensions-FileSystem community-contribution
概要
ConfigurationBuilder.AddJsonFileで相対パスを使用した際、ファイル変更時のOnChangeイベントが発火しない問題を修正しました。PhysicalFilesWatcherの相対パス処理を改善し、ファイル監視が正常に動作するようになります。
変更内容
- PhysicalFilesWatcher.cs: 相対パスの処理ロジックを改善(+7行)
- ConfigurationTests.cs: 相対パスでのOnChangeイベント発火を検証するテストケースを追加(+26行)
- testFileToReload.json: テスト用の設定ファイルを新規追加(+3行)
- Microsoft.Extensions.Configuration.Functional.Tests.csproj: テストプロジェクト構成を更新(+8行)
パフォーマンスへの影響
影響なし。ファイル監視機能の動作修正であり、パフォーマンス面での変更はありません。
関連Issue
#71386
その他
- このPRはファイル監視機能の機能修正です
- テスト実装により、相対パス使用時のOnChangeイベント動作が保証されます
Microsoft.Extensions.FileProviders.Physicalライブラリに関連する修正のため、ファイル監視を利用しているアプリケーションに影響する可能性があります