core_ext/benchmark.rbを非推奨から無言のshimに復帰

rails/rails

Rails 8.1では、active_support/core_ext/benchmark.rbの非推奨警告が削除され、空のファイルとして維持されるようになりました。これにより、既存コードへの影響を最小限に抑えつつ、将来の拡張の余地を残しています。

背景

core_ext/benchmark.rbは、唯一残っていた拡張メソッドBenchmark.msの削除に伴い、Rails 8.1で非推奨となっていました。このファイルをrequireすると、Rails 8.2での削除を予告する非推奨警告が表示される状態でした。

#56831のディスカッションでは、このファイルがbenchmarkの拡張を配置する場所として今後も存在し続けるべきであり、たまたま現時点で拡張が存在しないだけだという判断が示されています。非推奨警告を出し続けることで、将来の拡張追加時に混乱を招く可能性がありました。

技術的な変更

2つのファイルが変更され、非推奨の仕組みが完全に削除されました。

activesupport/lib/active_support/core_ext/benchmark.rbの変更:

非推奨警告のコード全体が削除され、frozen_string_literalコメントのみを残す空のファイルになりました。

# frozen_string_literal: true

activesupport/lib/active_support/core_ext.rbの変更:

core_ext/benchmark.rbを除外していたロジックが削除され、他のcore_extファイルと同様に自動的に読み込まれるようになりました。

変更前:

(Dir.glob(File.expand_path("core_ext/*.rb", __dir__)).sort - [File.expand_path("core_ext/benchmark.rb", __dir__)]).each do |path|
  require path
end

変更後:

Dir.glob(File.expand_path("core_ext/*.rb", __dir__)).sort.each do |path|
  require path
end

配列の減算演算子による除外処理が不要になり、シンプルなイテレーションに戻りました。

設計判断

完全削除ではなく空のshimとして維持する方式が採用されました。

このアプローチには3つの利点があります。第一に、require 'active_support/core_ext/benchmark'を明示的に呼び出している既存コードとの互換性を保ちます。第二に、将来benchmarkの新しい拡張が追加された際に、このファイルが自然な配置場所として機能します。第三に、非推奨警告を削除することで、ユーザーに誤った「削除予定」のシグナルを送らずに済みます。

ファイル自体は空ですが、その存在がAPI拡張ポイントの予約という設計上の役割を果たしています。これは、Active Supportのモジュール構造における一貫性を維持するための判断といえます。

まとめ

本PRは、非推奨警告を削除してcore_ext/benchmark.rbを無言のshimに変更した、Rails 8.1ブランチへのバックポートです。現時点で拡張メソッドは含まれませんが、ファイルの存在を維持することで、既存コードとの互換性と将来の拡張性の両方を確保しています。

記事メタデータ

Generated by:
Claude Sonnet 4.5 for DiffDaily

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
承認済み
Review Count:
1回
Reviewed by:
Gemini 2.5 Pro for DiffDaily

Review Criteria:

記事構成 ✓ PASS

Title, Context, Technical Detailの存在と明確さ

「リード文→背景→技術的な変更→設計判断→まとめ」という総論→各論→結論の構成が明確に守られています。各セクションが期待される役割を適切に果たしています。

カスタムMarkdown構文 ✓ PASS

シンタックスハイライト・GitHubリンク記法の正確性

ファイル名付きシンタックスハイライト(```言語:ファイルパス)とGitHubのPR番号リンク([#123](URL))の両方が正しく使用されています。

対象読者への適合性 ✓ PASS

エンジニア向けの適切な技術レベルと表現

Railsの内部構造に関する知識を持つエンジニアを対象としており、専門用語が適切に使用されています。冗長な説明がなく、簡潔です。

パラグラフ・ライティング ✓ PASS

トピックセンテンス・1段落1トピック・段落長

各セクション、各パラグラフが「総論→各論」の構造で書かれており、トピックセンテンスが明確です。1段落1トピックの原則も守られており、非常に読みやすいです。

Diff内容との照合 ✓ PASS

コードブロックとDiff内容の一致

記事内のコードブロックは、提供されたDiff情報を正確に反映しています。変更前後のコードスニペットとファイルパスがすべて一致しています。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

「shim」「core_ext」「バックポート」といった技術用語が、PRの文脈に沿って正確に使用されています。

説明の技術的正確性 ✓ PASS

技術的主張の正確性と論理性

コード変更の意図や影響についての説明は、Diffの内容と論理的に整合しており、技術的に正確です。

事実の突合 ✓ PASS

PR情報による主張の裏付け(ハルシネーション検出)

記事内のすべての主張は、PRのタイトル、Description、Diff、または参照されているPRの内容によって裏付けられています。ハルシネーションは見られません。

数値・固有名詞の確認 ✓ PASS

PR番号・コミットID・バージョン等の正確性

PR番号(#56832, #56831)やバージョン番号(Rails 8.1, 8.2)などの数値・固有名詞はすべて正確です。

タイトル・説明との一致 ✓ PASS

記事タイトル・説明とPR内容の一致

記事のタイトルはPRのタイトル「Restore core_ext/benchmark.rb as a silent shim (8-1-stable)」の内容を的確に要約しており、主題のズレはありません。

外部知識の正確性 ✓ PASS

PRに記載のない外部知識(LTS、サポート状況など)の不使用

PR情報に含まれない外部知識(LTS、EOL情報など)の追記はなく、提供された情報源に忠実です。

時間表現の正確性 ✓ PASS

時間表現がPR情報と一致しているか

「非推奨となっていました」「今後も存在し続けるべき」といった時間表現が、PRの文脈と正確に一致しています。