Ruby 3.4.8 upgrade

[Irving-Betterment]

Summary

• Add Ruby 3.4 to the CI matrix to confirm compatibility
• Bump ruby/setup-ruby to v1.288.0 (bringing prebuilt Ruby 3.4)
• Fix Warning#warn caller frame resolution on Ruby 3.4 + Rails 8.0
• Fix Deprecatable reporting deprecatable.rb as the caller for non-rubygems installs (bonus).

Test plan

• CI passes with Ruby 3.4 in the matrix
• Installed in a Rails application to ensure no regressions.

[Irving-Betterment]

On Ruby 3.4 + Rails 8.0, caller_locations(1..1).first from inside Uncruft::Warning#warn returns a frame pointing to warning.rb itself instead of the actual caller. This causes strip_caller_info to try
to strip warning.rb's path from the warning string — which doesn't match — leaving the original caller info intact in the message passed to Uncruft.deprecator.warn.

Root cause

Uncruft::Warning is prepended onto Warning, Kernel, and Object. On Ruby 3.4 + Rails 8.0, the prepend chain adds an extra frame, shifting caller_locations(1..1).first from the actual caller to warning.rb itself.

How it was proven

1. Added an unstubbed spec that lets the full chain run: warn("DEPRECATION: ... #{path}:#{lineno}") → warning.rb → deprecator.warn, then asserts the message passed to deprecator.warn has the caller path
   stripped.
2. Temporarily reverted the fix to caller_locations(1..1).first and pushed to CI
3. Result: Ruby 3.4 + Rails 8.0 failed, all other matrix combinations passed
4. Restored the fix, CI passes

The fix

Instead of assuming a fixed frame depth, search frames 1–5 for the one whose path appears in the warning string. This is resilient to frame depth changes across Ruby/Rails versions. Falls back to the
first frame if no match is found.

[Irving-Betterment]

We moved away from the dynamic search (clocs.detect { |cl| str.include?(cl.path) }) because while it works, it's the equivalent of Van Halen's crew just sorting through the candy bowl and quietly removing any brown M&Ms — the show goes on, but you never find out whether the promoter actually read the rider.

The dynamic search silently adapts to any frame layout change. If Ruby 3.5 shifts the callstack in a way that happens to still have a matching path somewhere in frames 1–5, it would find it and we'd never know the layout changed. Subtle issues downstream could go unnoticed.

Instead, find_caller_location now checks a version-pinned map (EXPECTED_INTERNAL_FRAMES) that catalogs exactly which internal frames are allowed at clocs[0] for each Ruby/Rails combo. It only skips a frame if it's explicitly expected for that version — no silent adaptation. If a brown M&M shows up (an unexpected frame, or an unknown Ruby/Rails combo), the code doesn't quietly handle it. CI goes red, a developer investigates, adds the entry, and we're back to green.

The tradeoff is intentional: on an uncataloged combo, path stripping degrades benignly (extra path info in the message) rather than silently masking a frame layout change. The brown M&M catches the problem before anything subtler slips through.

[Irving-Betterment]

When uncruft is installed via any non-rubygems method (vendored path, GitHub/git source, local path, or custom BUNDLE_PATH), calling a deprecated method reports deprecatable.rb as the caller instead of
the actual call site:

RuntimeError:
  DEPRECATION WARNING: Please stop using a_method from MyCode.
  (called from block (2 levels) in deprecate_method at
  ../../../vendor/gems/uncruft/lib/uncruft/deprecatable.rb):19

This is not a regression — it's a gap that has always existed, masked by rubygems installs.

Root cause

Uncruft.deprecator.warn(message) without an explicit callstack lets ActiveSupport compute one via caller_locations(2)
(https://github.com/rails/rails/blob/main/activesupport/lib/active_support/deprecation/reporting.rb#L21). ActiveSupport's extract_callstack then picks the first frame not matching RAILS_GEM_ROOT or
LIB_DIR:

def ignored_callstack?(path)
  path.start_with?(RAILS_GEM_ROOT, LIB_DIR) || path.include?("<internal:")
end

• Rubygems install: uncruft's path lives under LIB_DIR (e.g. ~/.mise/installs/ruby/3.4.8/lib/ruby/gems/...), so deprecatable.rb is skipped — bug is masked
• Any other install: the path doesn't match either ignore pattern, so extract_callstack picks deprecatable.rb as the "offending line"

Why a fixed frame depth isn't enough

Nested deprecated method calls (e.g. deprecated_method_a calls deprecated_method_b) add multiple deprecatable.rb frames to the callstack. caller_locations(1) only skips the current frame, leaving frames from outer wrappers' super calls:

FRAME 0: deprecatable.rb:18  ← current warn call (skipped by caller_locations(1))
FRAME 1: deprecatable.rb:20  ← super from outer deprecated method wrapper
FRAME 2: my_code.rb:10  ← actual caller
FRAME 3: deprecatable.rb:20  ← super from yet another wrapper

How it was proven

1. Applied caller_locations(1) fix and vendored into an application — CI still failed with deprecatable.rb as the caller
2. Added debug logging (caller_locations(0, 10)) to the vendored gem and pushed to application's CI
3. Debug output revealed nested deprecatable.rb frames from chained deprecated method calls
4. Applied reject fix — application's CI passed

The fix

This removes all deprecatable.rb frames from the callstack. extract_callstack still runs its filtering logic on the remaining frames — we're not bypassing anything, just giving it a cleaner input.

Why the gem's own specs don't catch this

When running uncruft's test suite, the gem is loaded from its own source tree via bundler/setup. The path resolves under LIB_DIR, so ignored_callstack? skips deprecatable.rb and the correct caller is
reported. The bug only surfaces when the gem is loaded from a path outside LIB_DIR.

Precedent in ActiveSupport

ActiveSupport itself passes explicit caller_locations to deprecator.warn in multiple places:

• https://github.com/rails/rails/blob/main/activesupport/lib/active_support/deprecation/proxy_wrappers.rb — 5 call sites
• https://github.com/rails/rails/blob/main/activesupport/lib/active_support/deprecation/constant_accessor.rb#L13 — 1 call site

[Irving-Betterment]

Pivoted from filtering by filename (end_with?("deprecatable.rb")) to filtering by gem root path (start_with?(Uncruft::GEM_ROOT)), following the same pattern ActiveSupport uses for its own deprecation reporting.

This filters ALL uncruft frames from the callstack (not just deprecatable.rb), making it resilient to file renames and covering edge cases like nested deprecated method calls that chain through multiple gem files.

[smudge]

domain LGTM && platform LGTM -- thanks for the rework to encode a bit more of the known behaviors rather than relying on filtering logic every time 👍