[tannevaled]

rbgo reports RUBY_VERSION 4.0.9, the latest MRI release, and the one
behaviour that could not land without the bump lands with it.

Measured before it was made

Both engines built from one commit minus the version string, each from a
clean distinct revision so the provenance gate added in #874 is satisfied
rather than waived, over core and language together — the whole surface
the move touches, which #875 made expressible:

2206 file(s): control 23528 passing, treatment 23672 passing, +144
45 file(s) moved, 13 regressed, 27 example(s) WENT RED

+144 is not progress and 13 regressed is not 13 defects. Six of the
thirteen lost only examples the corpus stops asking for — each has a CLOSED
guard in the census and no WENT RED line. The clearest case is
core/objectspace/_id2ref_spec.rb, which reads 10 → 0: below 4.0 the file
holds eleven examples and rbgo passes ten; at 4.0.9 that block closes and a
single one opens. The work there is one example, not ten.

The real remaining work of the move is 27 named examples, listed per item
in #799.

The one behaviour that comes with the bump

compiler.go already said so: hiding _1 from a Binding "belongs with the
RUBY_VERSION bump". Below 4.0 ruby/spec asserts the opposite
(numbered_parameters_spec.rb:93, ruby_version_is ""..."4.0"), so doing it
alone would have traded four passing examples for four failing ones.

The asymmetry is the whole change

proc { _1 }.parameters                        # [[:opt, :_1]]  -- UNGATED, every version
-> { _1; binding.local_variables }.call("a")  # [:_1] below 4.0, [] from 4.0

numbered_parameters_spec.rb:85 carries no version guard, so blanking
b.params as well would have traded four examples for two. it is blanked
from both, because MRI gives it no name in #parameters either. So:
b.locals for both kinds, b.params for it only.

Refusing by name, before any lookup

MRI tests rb_numparam_id_p at the top of all three methods (proc.c
v4.0.9:549, 602, 649), which has two consequences that are easy to miss and are
both tested:

• it raises in a binding that has no numbered parameter, and at the top
  level — _1 is not a local being hidden, it is not a local variable name;
• #local_variable_defined? raises rather than answering false.

And it uses rb_numparam_id_p, not rb_implicit_param_p (proc.c:517),
which also covers it. That narrowing is necessary: it is a legal local
variable name — it = 5 compiles — so widening the refusal would break every
binding holding a variable called it. There are controls for that and for the
_0 / _10 / _ boundary.

Measured on its own, control and treatment both at 4.0.9: +4, 0 regressed, 0
WENT RED. core/proc is in the measured set deliberately — blanking
b.params would have shown up there as a loss.

What the bump breaks

go test ./... across the repository: four assertions, every one a
deliberate pin of the pre-4.0 behaviour, and nothing else in a 210-second VM
suite. Each is rewritten to the 4.0 behaviour with its comment, not flipped
silently.

BASELINE, recorded where it is enforced

Not recorded on a laptop — this machine reads +9 against CI for no change
in the code. Recorded by the rubyspec-baseline lane (#877) on the pinned
ubuntu-24.04, and downloaded as its artefact. 23,511 → 23,673.

The lane was dispatched without -absorb first, because the #876 gate had
only ever refused a synthetic loss:

::error::REFUSING to re-record: 11 file(s) went backwards -- named above

Both of the lane's asymmetries held on that run: the diffstat step ran, the
artefact step was skipped, so no unchanged BASELINE was offered under the
name "the re-recorded baseline". The second dispatch passed -absorb, and the
baseline now carries the stamp naming all eleven.

⛔ Comparing the sets, not the counts, found a hole in the gate

Local predicted 13 going backwards; CI named 11. Both missing entries matter:

• language/numbered_parameters_spec.rb is absent because this branch fixes
  it — independent confirmation in CI of the +4 measured locally;
• language/variables_spec.rb is absent because the baseline was stale. CI
  reported 118 passing, baseline 115 (+3) — an improvement — while the file
  has passed 119 since deps: go-ruby-parser v0.14.0 closes the last defect of #799 #871, and the move genuinely costs one example there. A
  real regression reported as a gain.

A per-file floor cannot see a regression smaller than a file's unbanked
improvement. Filed as #881; it is the exact complement of #876. This fresh
measurement clears the accumulated slack as a side effect.

Not changed on a hunch

RbConfig::CONFIG["ruby_version"] may be the API version in MRI (4.0.0 for
every 4.0.x) rather than the full one. Nothing in ruby/spec asserts that key, so
the corpus cannot settle it, and a version bump is not the place to change
behaviour on a guess. Filed as #878.

Refs #799
Refs #878, #881

🤖 Generated with Claude Code