Pull Request on 2026年04月11日

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

注意点

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



#126783 Fix code review agent timeouts caused by gpt-5.4

  • 作成者: @danmoseley
  • 作成日時: 2026年04月11日 02:44:04(UTC)
  • マージ日時: 2026年04月11日 04:30:15(UTC)
  • ラベル: area-Infrastructure

概要

dotnet/runtimeのコードレビュー自動化ワークフローで約20%の実行がタイムアウトする問題を修正します。分析結果から、GPT-5.4サブエージェントの無限ハングが93%のタイムアウトの原因であることが判明。SKILL.mdを修正し、GPT-5.4をブロック、GPT-5.3-codexを推奨、サブエージェント数を4から3に削減、レビュー投稿後の即座の終了を実装します。

変更内容

  • .github/skills/code-review/SKILL.md (+6/-4)
    • gpt-5.4をサブエージェント選択時にブロック
    • GPTファミリーの場合はgpt-5.3-codexを推奨
    • 並行実行するサブエージェント数を4から3に削減
    • レビューコメント投稿後に即座に終了する命令を追加(従来は2-3分間、ハングしたサブエージェントを待機していた)

パフォーマンスへの影響

  • タイムアウト削減: 19.7%(43/218実行)のタイムアウトの主因(GPT-5.4ハング)を排除
  • 実行時間短縮: 投稿後の待機時間削減により、1実行あたり2-3分の短縮を見込む
  • リソース効率化: サブエージェント数削減(4→3)により不要な並行実行を削減
  • データベース: 1,000ワークフロー実行の分析で、タイムアウト実行はGPT-5.4が100%(24/24詳細確認)出現、GPT-5.2のみの実行は0%のタイムアウト

関連Issue

#126779(一般的な効率改善)

その他

  • 品質への影響: レビュー品質の低下は見込まれません。分析では、GPT-5.4が発見した唯一のブロッキング結果は0%
  • 実装の仕様:
    • 既存の10分のサブエージェントタイムアウト命令は変更なし
    • ワークフロー全体の20分タイムアウト制限(.lock.ymlに記述)は変更なし
    • レビュー方法論や重要度定義は変更なし
  • 根本原因分析: GPT-5.4は無限にハングするため、単にタイムアウト時間を延長しても解決せず、計算リソースの浪費になるだけ
  • タイムアウト以外の問題: 218実行のうち12実行(~6%)でMCPのadd_commentが失敗する既知のプラットフォーム問題があるが、今回の修正対象外

#126779 Reduce code-review skill token usage (~29% smaller)

  • 作成者: @danmoseley
  • 作成日時: 2026年04月10日 23:52:11(UTC)
  • マージ日時: 2026年04月11日 02:17:09(UTC)
  • ラベル: area-skills

概要

dotnet/runtimeのコードレビュー自動化スキル(SKILL.md)のトークン使用量を削減するため、低価値なコンテンツを除去し、API承認検証手順を独立ファイルに抽出しました。スキルサイズを約29%削減(68.9KB → 48.7KB)し、20分のタイムアウト問題を緩和します。すべてのレビュールールと手順は保持されます。

変更内容

  • SKILL.md: 約150行のメンテナー引用例(フレーズ方法を示す例)を削除(−19KB)。レビュールール、重要度ガイダンス、実行可能な指示は全て保持
  • api-approval-check.md(新規): API承認検証手順を独立ファイル化(−3KB from always-loaded context)。STEP 0とSTEP 2にMUST-load指示を明記し、ロード失敗時は明示的にエラー報告して検証をブロック
  • SKILL.mdで「Always Initialize」がマネージドのみのルールであることを明記

パフォーマンスへの影響

  • 常時ロードトークン数: 約17.2K → 約12.2K(−5K削減)
  • SKILL.mdファイルサイズ: 68.9KB → 48.7KB(−29.3%削減)
  • API承認検証はオンデマンド方式に変更され、不要な場合のトークン消費を回避

関連Issue

なし

その他

  • このPRは自動コードレビュー実行中の20分タイムアウト問題に対処するもので、GitHub agentic workflowsのハードリミット対策です
  • 抽出されたapi-approval-check.mdは自己完結型で、Step 0とStep 2での明示的なロード指示により、ファイル未ロード時は安全にエラー処理されます
  • dotnet/skillsの他スキルファイルの平均サイズ(~10.8KB)と比較して、処理後のruntime code-reviewスキル(48.7KB)はまだ大きいですが、複合的な多段階レビュー手順全体をカバーしています

#126766 Fix result assignment after action execution

  • 作成者: @AaronRobinsonMSFT
  • 作成日時: 2026年04月10日 21:29:13(UTC)
  • マージ日時: 2026年04月11日 01:57:12(UTC)
  • ラベル: test-bug area-Interop-coreclr

概要

STA-thread テストハーネスにおいて、結果がアクション実行後にのみ TestPassed に設定されるよう修正しました。以前は、失敗時に結果が誤って上書きされていました。

変更内容

  • src/tests/Interop/COM/NETClients/Lifetime/Program.cs
    • result = TestPassed;try ブロック内のアクション実行後に移動
    • 例外(アサーション失敗を含む)が発生した場合、resultTestFailed のままに保持

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

この変更は COM Interop テストの結果判定ロジックの修正であり、テスト実行時の終了コード設定の信頼性を向上させるものです。


#126764 Bump actions/github-script from 8 to 9

  • 作成者: @dependabot[bot]
  • 作成日時: 2026年04月10日 21:23:56(UTC)
  • マージ日時: 2026年04月11日 23:00:21(UTC)
  • ラベル: area-codeflow

概要

GitHub Actions のワークフロー内で使用されている actions/github-script を v8 から v9 にアップグレードするメジャーバージョン更新です。v9 では ESM-only な @actions/github v9 への依存関係が変更され、getOctokit がスクリプトコンテキストに直接注入される機能が追加されました。

変更内容

  • .github/workflows/bump-chrome-version.yml: actions/github-script のバージョンをv8からv9に更新
  • .github/workflows/locker.yml: actions/github-script のバージョンをv8からv9に更新

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

破壊的変更への対応注意:

v9 では以下の破壊的変更が含まれており、dotnet/runtime のワークフロー内で該当する記述がある場合は修正が必要です:

  1. require('@actions/github') は廃止 — ESM-only 化に伴い、スクリプト内で const { getOctokit } = require('@actions/github') のようなパターンは動作しなくなります。代わりに直接注入される getOctokit 関数を使用してください。

  2. getOctokit は関数パラメータとして注入 — スクリプト内で const getOctokit = ...let getOctokit = ... として再宣言すると SyntaxError が発生します。注入された getOctokit を直接使用するか、必要な場合は var getOctokit = ... で再宣言してください。

  3. 新機能getOctokit ファクトリ関数により、異なるトークンを使用した複数の認証済み Octokit クライアントの作成が可能になりました。また、user-agent 文字列に ACTIONS_ORCHESTRATION_ID が自動的に追加されます。


#126762 JIT: Disable instrument_if_optimizing in libraries-pgo

  • 作成者: @AndyAyersMS
  • 作成日時: 2026年04月10日 19:50:34(UTC)
  • マージ日時: 2026年04月11日 00:21:51(UTC)
  • ラベル: area-Infrastructure-libraries

概要

libraries-pgo パイプラインから instrument_if_optimizing Helix シナリオを削除し、非常に遅い JIT インストルメンテーションモード(最適化中のインストルメンテーション)がライブラリテストで実行されないようにします。共有シナリオ定義は coreclr テストでは継続して利用可能です。

変更内容

  • eng/pipelines/coreclr/libraries-pgo.yml: instrument_if_optimizing シナリオを削除(1行削除)

パフォーマンスへの影響

テストスイート実行時間の短縮が期待されます。JIT インストルメンテーション中の最適化は著しくパフォーマンスを低下させるため、この遅いモードを libraries-pgo パイプラインから除外することにより、テスト実行時間が改善されます。

関連Issue

#120902

その他

  • この変更はシナリオ定義そのものを削除するのではなく、libraries-pgo パイプラインからの参照のみ削除するため、coreclr テストなど他のテストグループが必要に応じて引き続き利用可能です。

#126761 Remove unused AssemblySpecHash class

  • 作成者: @Copilot
  • 作成日時: 2026年04月10日 19:02:08(UTC)
  • マージ日時: 2026年04月11日 00:26:13(UTC)
  • ラベル: area-AssemblyLoader-coreclr

概要

AssemblySpecHashクラスがコードベース内で呼び出されていないため、削除しました。クラス定義をassemblyspec.hppから、メソッド実装(~AssemblySpecHashCompareSpecs)をassemblyspec.cppから削除します。INITIAL_ASM_SPEC_HASH_SIZEマクロはAssemblySpecBindingCacheで使用されているため保持されます。

変更内容

  • src/coreclr/vm/assemblyspec.hppAssemblySpecHashクラス定義を削除(82行削除)
  • src/coreclr/vm/assemblyspec.cpp~AssemblySpecHashデストラクタとCompareSpecsメソッドの実装を削除(34行削除)

パフォーマンスへの影響

影響なし(不要なコードの削除により、わずかなバイナリサイズ削減)

関連Issue

なし

その他

  • この変更は内部実装(ランタイムVM層)のクリーンアップであり、公開APIへの影響はありません。
  • INITIAL_ASM_SPEC_HASH_SIZEマクロは継続使用されるため保持されました。

#126757 [release/10.0] Fix CLR->COM RCW ownership tracking on the slow path

  • 作成者: @github-actions[bot]
  • 作成日時: 2026年04月10日 17:56:52(UTC)
  • マージ日時: 2026年04月11日 01:10:23(UTC)
  • ラベル: Servicing-approved area-Interop-coreclr

概要

COM オブジェクトの RCW(Runtime Callable Wrapper)所有権追跡のスローパスにおけるバグ修正。#126731 の release/10.0 へのバックポート。アンマネージドスレッドから COM インターオップを使用する際の COM オブジェクトのライフタイム管理に関する問題を解決します。

変更内容

  • src/coreclr/System.Private.CoreLib/src/System/StubHelpers.cs:RCW 所有権追跡ロジックを修正(10行追加、9行削除)
  • src/coreclr/vm/stubhelpers.cpp/h:対応する C++ 実装側のスローパス処理を修正(14行追加、9行削除)
  • COM インターオップテスト群:COM オブジェクトライフタイム管理に関する追加テストを実装
    • Program.cs:テストケース追加(96行追加、16行削除)
    • Servers.cppTrackMyLifetimeTesting.hServer.Contracts.cs/h:テスト用 COM サーバー定義を拡張

パフォーマンスへの影響

影響なし。本修正は正確性(COM オブジェクトのライフタイム管理)に関わるもので、パフォーマンスを変動させません。

関連Issue

#126619#126731#114609#95695

その他

回帰情報:.NET 10 の HELPER_METHOD_FRAME 削除作業(#114609)で導入された回帰。本修正により、削除前の処理ロジックが復元されます。

リスク評価:低。COM インターオップ利用時のライフタイム管理を正しく復元するもので、実測の顧客報告バグに対応しています。


#126753 Update area owners documentation and sync repo automation

  • 作成者: @Copilot
  • 作成日時: 2026年04月10日 16:35:06(UTC)
  • マージ日時: 2026年04月11日 23:05:21(UTC)
  • ラベル: area-System.Threading

概要

dotnet/runtime のリポジトリメンテナンス関連の文書化とリポジトリオートメーション設定を更新するドキュメント変更です。エリアオーナーの整理、エリアラベルの廃止・統合、担当者(Lead)の更新を反映しています。

変更内容

  • docs/area-owners.md: 8つの古いエリア行を削除、area-AssemblyLoader-coreclrarea-assemblyloading に改名、6つのエリアの Lead を更新(@JulieLeeMSFT と @steveisok)
  • .github/policies/resourceManagement.yml: area-assemblyloading への改名を反映、廃止されたエリアの notification ブロック削除、統合されたエリアへの mentionee 更新、area-TieredCompilation-coreclr の新規 trigger と notification ブロック追加
  • .github/skills/issue-triage/references/area-label-heuristics.md: エリアラベルの改名・統合を反映、host/hostfxr/hostpolicy のエリア判定を更新、System.Runtime.InteropServicesarea-Interop-coreclr へリダイレクト、例外処理・PAL 関連を area-vm-coreclr へ統合

廃止エリア (統合先):

  • area-Host + area-HostModelarea-assemblyloading
  • area-R2RDump-coreclr + area-ReadyToRun-coreclrarea-crossgen2-coreclr
  • area-ExceptionHandling-coreclrarea-vm-coreclr
  • その他単独廃止: area-Infrastructure-coreclr, area-System.Runtime.InteropServices, area-PAL-coreclr

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • Markdown テーブル形式と YAML フォーマットを保持、末尾空白なし
  • リポジトリのオートメーション設定と triage 参照文書を同期し、一貫性を確保

#126707 [main] Source code updates from dotnet/dotnet

  • 作成者: @dotnet-maestro[bot]
  • 作成日時: 2026年04月09日 13:23:19(UTC)
  • マージ日時: 2026年04月11日 20:23:21(UTC)
  • ラベル: area-Infrastructure-libraries

概要

このPRは、dotnet/dotnetリポジトリからのコードフロー更新であり、複数の下流リポジトリ(aspnetcore、efcore、roslyn、sdk等)の変更を取り込むものです。主な変更は、ビルドツール・コンパイラ・依存パッケージの更新、およびMicrosoft.Extensions.*ライブラリのプロジェクトファイル構成の更新です。

変更内容

  • 依存パッケージ更新: Microsoft.CodeAnalysis (5.7.0)、Microsoft.DotNet.Arcade.Sdk (11.0.0-beta)、NuGet.* パッケージ (7.6.0-rc)、System.Text.Json (11.0.0-preview.4) など、複数のビルドツール・ライブラリを更新
  • ビルド設定の更新: eng/Version.Details.xml/props、global.json、Signing.props、Publishing.propsなど、ビルド・署名・公開設定を更新
  • ツール更新: eng/common/tools.ps1/sh、sdk-task.ps1/sh のスクリプト更新
  • ライブラリプロジェクト設定: Microsoft.Extensions.Caching.、Microsoft.Extensions.Configuration. 等のプロジェクトファイルに新しいプロパティを追加
  • PackageOverrides.txt: インストーラー用パッケージオーバーライド設定を追加

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 本PRは自動化されたコードフロー更新(dotnet-maestro[bot]による)です
  • aspnetcore、command-line-api、efcore、fsharp、nuget.client、razor、roslyn、runtime、sdk、winforms、wpf など、12のリポジトリからの関連変更が含まれています
  • 詳細な変更内容は、関連するリポジトリのコミット差分で確認可能です

#126699 Implement ProcessStartInfo.KillOnParentExit for Windows

  • 作成者: @Copilot
  • 作成日時: 2026年04月09日 11:20:47(UTC)
  • マージ日時: 2026年04月11日 22:16:46(UTC)
  • ラベル: area-System.Diagnostics.Process

概要

Windows上で子プロセスが親プロセス終了時に自動的に強制終了されるProcessStartInfo.KillOnParentExitプロパティを実装しました。Windows Job Objects (JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE)を利用して、プロセス作成時に子プロセスをジョブオブジェクトに割り当てることで実現しています。

変更内容

  • ProcessStartInfo.cs: KillOnParentExitプロパティ追加([SupportedOSPlatform("windows")]属性)、UseShellExecuteとの併用時にInvalidOperationExceptionをスロー
  • ref/System.Diagnostics.Process.cs: 参照アセンブリにKillOnParentExitプロパティを追加
  • SafeProcessHandle.Windows.cs:
    • 静的なSafeJobHandle(ジョブオブジェクト)を遅延初期化し、全子プロセスで共有
    • CreateProcessパス: PROC_THREAD_ATTRIBUTE_JOB_LISTを拡張スタートアップ情報に設定
    • CreateProcessWithLogonWパス(ユーザー認証情報指定時): プロセスをサスペンド状態で開始→ジョブオブジェクトに割り当て→ResumeThreadで再開(失敗時はプロセス終了)
  • Interop.JobObjects.cs: CreateJobObjectWSetInformationJobObjectAssignProcessToJobObject等のP/Invoke定義とメタル構造体(JOBOBJECT_EXTENDED_LIMIT_INFORMATION等)を追加
  • Interop.ResumeThread.cs: ResumeThread P/Invoke(戻り値uint)を専用ファイルに定義
  • Strings.resx: KillOnParentExitCannotBeUsedWithUseShellExecuteリソース文字列を追加
  • テスト: KillOnParentExitTests.csに7つのテスト(デフォルト値、UseShellExecuteとの併用検証、正常終了/強制終了/クラッシュ時の子プロセス強制終了動作を検証)を追加

パフォーマンスへの影響

  • ジョブオブジェクトの作成は初回のみ(静的遅延初期化)
  • 既存コードパス(KillOnParentExit=false)への影響なし
  • 有効化時のプロセス作成オーバーヘッド:拡張スタートアップ情報の設定により軽微

関連Issue

#125838

その他

  • APIは[SupportedOSPlatform("windows")]でマークされ、Linux対応は別PRで予定
  • CreateProcessWithLogonWパス使用時(ユーザー認証情報指定時)は、プロセスをサスペンド状態で開始する必要があり、失敗時のクリーンアップ処理を厳密に実装
  • 既存テストの重複排除:ProcessHandlesTests.Windows.csのローカルResumeThread P/Invoke定義を削除し、共有のInterop.Kernel32.ResumeThreadを使用

#126670 Update THIRD-PARTY-NOTICES.TXT with opentelemetry license

  • 作成者: @MiYanni
  • 作成日時: 2026年04月08日 22:43:56(UTC)
  • マージ日時: 2026年04月11日 23:03:51(UTC)
  • ラベル: area-Setup

概要

.NET SDK が OpenTelemetry に移行したことに伴い、dotnet インストーラーの第三者ライセンス通知(THIRD-PARTY-NOTICES.TXT)を更新し、OpenTelemetry .NET の Apache 2.0 ライセンス情報を追加しました。これにより、インストーラーの TPN ファイルが CLI の OpenTelemetry ベースのテレメトリ実装と整合性を持つようになります。

変更内容

  • src/installer/pkg/THIRD-PARTY-NOTICES.TXT:OpenTelemetry .NET(opentelemetry-dotnet)のライセンス通知セクションを追加(+17行)

パフォーマンスへの影響

影響なし

関連Issue

dotnet/sdk#53181

その他

このPRは、dotnet/sdk リポジトリでの OpenTelemetry への移行に対応するための、ドキュメント/ライセンス表示の更新です。


#126660 Fix deterministic MountVolume test failures on ARM64 Helix machines

  • 作成者: @danmoseley
  • 作成日時: 2026年04月08日 20:49:54(UTC)
  • マージ日時: 2026年04月11日 07:34:52(UTC)
  • ラベル: area-System.IO

概要

Windows 11 ARM64 Helix マシン上で Directory_Delete_MountVolumeDirectory_ReparsePoints_MountVolume テストが確定的に失敗する問題を修正します。

根本原因: ARM64 Helix マシンの E:\ ドライブ(Azure リソース/一時ディスク)は DriveInfo の検査(固定、NTFS、Ready)には合格しますが、GetVolumeNameForVolumeMountPointERROR_INVALID_PARAMETER (87) を返します。ボリューム GUID がないドライブはボリュームマウントポイント操作をサポートしていません。

修正内容: ドライブ選択時に GetVolumeNameForVolumeMountPoint での成功確認を追加し、マウントポイント操作に対応したドライブのみを使用するようにフィルタリングします。

変更内容

  • IOServices.cs: GetNtfsDriveOtherThan() にボリューム GUID の存在確認を追加。ボリューム GUID を持たない SUBST ドライブや Azure リソースディスクをフィルタリング。
  • DllImports.cs: GetVolumeNameForVolumeMountPointW の P/Invoke を追加(LibraryImport を使用、char[] で実装)。
  • DumpDriveInformation.cs: Helix 専用の診断テストを新規追加。全ドライブとそのボリューム GUID をコンソールログに出力し、将来のドライブ関連 CI 問題の迅速な診断を可能に。
  • プロジェクトファイル: 新規テストファイルをプロジェクトに追加。

パフォーマンスへの影響

影響なし(テスト用コード変更)

関連Issue

#125295#125624#126627

その他

  • 修正前後の動作比較:

    • SUBST E: (ボリューム GUID なし): 修正前は Error 87/DirectoryNotFoundException → 修正後は SUBST フィルタリング、シナリオ 3.x 実行
    • 実際の NTFS E: → 修正前後とも全シナリオ成功
    • シングルドライブマシン → 変更なし
  • Copilot が低信度コメントで指摘: ReparsePointUtilities.csMarshal.GetLastPInvokeErrorMessage() は .NET Framework で未サポートのため、NETFRAMEWORK ビルドが破損する可能性があります。


#126621 Move the cache for the marshaler methods to be stored on the RuntimeType instead of in a ConditionalWeakTable

  • 作成者: @jkoritzinsky
  • 作成日時: 2026年04月07日 23:32:12(UTC)
  • マージ日時: 2026年04月11日 00:19:32(UTC)
  • ラベル: area-System.Reflection

概要

Marshal メソッドのマーシャラーキャッシュを ConditionalWeakTable から RuntimeType の汎用キャッシュインフラに移動し、相互運用パフォーマンスの回帰を改善します(#126608の修正)。検証処理をキャッシュ作成時に一度だけ実行し、レイアウト検証を毎回繰り返さないようにしています。

変更内容

  • RuntimeType.GenericCache.cs: RuntimeType.CompositeCacheEntryLayoutTypeMarshalerMethods 専用ストレージを追加し、既存の RuntimeType 汎用キャッシュに統合
  • Marshal.CoreCLR.cs: LayoutTypeMarshalerMethodsRuntimeType.IGenericCacheEntry<T> を実装するよう重構築。デリゲート作成から関数ポインタのキャッシュに切り替え、型のレイアウト検証をキャッシュ作成時に一度だけ実行
  • StubHelpers.cs: Blittable フォールバックの呼び出し最適化

パフォーマンスへの影響

  • キャッシュ構造の変更により、メモリ効率が向上(ConditionalWeakTable オーバーヘッド削減)
  • 検証ロジックをキャッシュ作成時に移動することで、同じ型での繰り返しの Marshal 呼び出しのオーバーヘッド削減
  • Blittable フォールバックは関数ポインタ経由となるため、直接呼び出しと比べ若干のコスト増加の可能性があるが、既存実装より大幅に高速化

関連Issue

#126608

その他

  • 内部実装の変更(ランタイムキャッシュメカニズム)であり、公開API への破壊的変更なし
  • StructureMarshaler<T> および LayoutClassMarshaler<T> のBlittable フォールバック実装により、マーシャリング処理の効率化を実現

#126592 [cDAC] Fix bug in GetThreadData

  • 作成者: @rcj1
  • 作成日時: 2026年04月06日 23:14:47(UTC)
  • マージ日時: 2026年04月11日 21:00:04(UTC)
  • ラベル: area-Diagnostics-cdac

概要

cDACのスレッド"dead"セマンティクスを修正するPRです。ThreadState.ReportDeadを列挙とIsThreadMarkedDeadで"dead"として扱うように改善しながら、DeadReportDeadを区別する必要な場合(例:GetThreadOwningMonitorLock)では区別できるようにしています。ランタイム状態ビットからコントラクトフラグへの変換が追加され、マネージドスレッドコントラクトも拡張されています。

変更内容

  • スレッド列挙と判定ロジック: ReportDeadをdead状態として扱うよう修正(dacdbiimpl.cpp、threads.cpp、threads.h)
  • Thread契約の拡張: ランタイムのThread::Stateビット(TS_ReportDead含む)をコントラクトThreadStateにマッピング(Thread_1.cs)
  • 公開契約enum: ThreadState.ReportDeadを追加(IThread.cs)
  • ドキュメント更新: Thread::Stateはraw整数ではなくコントラクトenumに変換すべきことを記載(Thread.md)
  • 各種呼び出し元の更新: comsynchronizable.cpp、eedbginterfaceimpl.cpp、profilingenumerators.cpp、dacdbiimplstackwalk.cpp等でスレッド状態チェック処理を適切に調整
  • テスト更新: DacDbiThreadDumpTestsを調整

パフォーマンスへの影響

影響なし

関連Issue

#126592

その他

この変更はデバッグ・診断機能(cDAC、DAC)に関連する内部実装の修正です。スレッド状態のセマンティクス統一により、デバッガやプロファイラ、診断ツールがスレッド情報をより正確に取得できるようになります。


#121880 Haiku: Initial managed libraries support

  • 作成者: @trungnt2910
  • 作成日時: 2025年11月21日 14:26:56(UTC)
  • マージ日時: 2026年04月11日 07:16:29(UTC)
  • ラベル: area-System.Runtime community-contribution os-haiku

概要

Haiku OSのランタイムサポートを追加するPRで、マネージドランタイムライブラリ(System.Private.CoreLib)をHaiku向けにビルドするために必要なコードを実装しています。Haiku OS検出、環境情報取得、ネイティブ相互運用層の初期サポートを提供します。

変更内容

  • Interop層: Interop.OS.cs でHaiku向けのOS相互運用定義を追加
  • Environment API: System/Environment.Haiku.cs でHaiku固有の環境情報取得ロジックを実装
  • OS検出: OperatingSystem.cs にHaiku OSの検出ロジックを追加
  • ネイティブライブラリ:
    • pal_getosinfo.c/h でHaiku向けのOS情報取得関数を実装
    • CMakeビルドスクリプトにHaiku関連の設定を追加
  • ビルド設定: プロジェクトファイルとPAL設定ファイルを更新してHaikuビルドをサポート

パフォーマンスへの影響

影響なし

関連Issue

#55803

その他

このPRはHaiku OSへの.NETランタイムポーティングの初期段階の一部です。


目次