Skip to content

deps: go-ruby-parser v0.14.0 closes the last defect of #799 - #871

Merged
tannevaled merged 1 commit into
mainfrom
bump-parser-v0.14.0
Nov 2, 2026
Merged

tannevaled merged 1 commit into
mainfrom
bump-parser-v0.14.0

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

go-ruby-parser v0.14.0 carries token.IsConstStart, which decides the
constant/local distinction the way MRI's rb_sym_constant_char_p does — by
Unicode case, not by 'A' <= c && c <= 'Z'. Titlecase letters count as
uppercase, and caseless scripts (CJK, Hebrew, Arabic) as lowercase, so Ἅbb is
a constant and μm is a local.

Measured

Same corpus, same host, three passes, cmd/specdelta between a main binary
and a branch binary built from this commit:

language/   +2, no regression
core/       1 file moved, 0 regressed   (core/random/bytes_spec, known flaky)

language/variables_spec.rb   118/1  ->  pass=119 fail=0

variables_spec.rb is clean. That was the fifth and last of the five
defects #799 held — the file had been failing on a non-ASCII constant
assignment since the issue was opened.

Closes #799

🤖 Generated with Claude Code

v0.14.0 carries `token.IsConstStart`, which decides the constant/local
distinction the way MRI's `rb_sym_constant_char_p` does: by Unicode case, not by
`'A' <= c && c <= 'Z'`. Titlecase letters count as uppercase, and caseless
scripts (CJK, Hebrew, Arabic) are lowercase — so `Ἅbb` is a constant and `μm` is
a local.

Measured on this branch against `main`, same corpus, same host, three passes:

    language/   +2, no regression
    core/       1 file moved, 0 regressed  (core/random/bytes_spec, known flaky)

    language/variables_spec.rb   118/1  ->  pass=119 fail=0

`variables_spec.rb` is now clean, which was the fifth and last of the five
defects #799 held. The file had been failing on a non-ASCII constant assignment
since the issue was opened.

Closes #799

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@tannevaled
tannevaled merged commit 050855b into main Nov 2, 2026
26 checks passed
@tannevaled
tannevaled deleted the bump-parser-v0.14.0 branch November 2, 2026 20:22
tannevaled added a commit that referenced this pull request Nov 3, 2026
Recorded by the rubyspec-baseline lane (#877) on the pinned ubuntu-24.04 --
the same runner the ratchet gates on -- and downloaded as its artefact. Not
recorded here: this machine reads +9 against CI for no change in the code.

    23,511 -> 23,673 passing examples

## The refusal was exercised on the real case first

The lane was dispatched WITHOUT -absorb before it was dispatched with it,
because the gate added in #876 had only ever refused a synthetic loss:

    re-record: 2206 files measured, 2206 in the baseline being replaced
    -- REGRESSED (11) --
       core/objectspace/_id2ref_spec.rb: 0 passing, baseline 10 (-10)
       core/set/flatten_merge_spec.rb: 0 passing, baseline 3 (-3)
       ...
    ::error::REFUSING to re-record: 11 file(s) went backwards -- named above

Both of the lane's deliberate asymmetries held on that run: the diffstat step
ran (it carries always()) and the artefact step was SKIPPED (it does not), so
no unchanged BASELINE was offered as "the re-recorded baseline".

The second dispatch passed -absorb, and the baseline now carries the stamp:

    # ⛔ ABSORBED 11 file(s) that went backwards, recorded with -absorb on 2026-11-03:
    #     core/gc/config_spec.rb: 7 passing, baseline 8 (-1)
    #     ...

Six of the eleven are guards CLOSING -- examples 4.0 stops asking for, each
with a `ruby_version_is ""..."4.0"` site in the census -- and not defects.

## ⛔ What comparing the SETS found, which the counts hid

The local sweep predicted 13 files going backwards; CI named 11. Both missing
entries are informative:

  - 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 #871 and the move genuinely costs one example
    there. A real regression reported as a gain.

That is a structural blind spot in the gate: a per-file floor cannot see a
regression smaller than the file's unbanked improvement. Filed as #881. It is
the exact complement of #876, which stops a re-record banking a LOSS; this is
the cost of not banking a WIN -- and it existed because until #877 there was no
correct way to re-record at all.

This fresh measurement clears the accumulated slack as a side effect.

## README

TestReadmeConformanceCountMatchesTheBaseline named all three stale sites and
the new figure, which is how the README was updated rather than by hand. The
dated table is left as the 3.4.1 sweep it is and now says so.

Refs #799
Refs #881

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tannevaled added a commit that referenced this pull request Nov 3, 2026
* Ruby 4.0.9: the version rbgo reports, and the numbered parameters

RUBY_VERSION moves from 3.4.1 to 4.0.9, and the one behaviour that could not
land without it lands with it.

## Why these two are one commit

compiler.go said so already: hiding `_1` from a Binding "belongs with the
RUBY_VERSION bump". Below 4.0 ruby/spec asserts the OPPOSITE --
language/numbered_parameters_spec.rb:93 is `ruby_version_is ""..."4.0"` and
pins `binding.local_variables == [:_1]` -- so doing it alone would have traded
four passing examples for four failing ones.

## The asymmetry is the whole change

`_1` leaves the LOCAL TABLE and stays in #parameters:

    proc { _1 }.parameters                        # [[:opt, :_1]]  -- UNGATED
    -> { _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 trade 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 #local_variable_get, #local_variable_set
and #local_variable_defined? (proc.c v4.0.9:549, 602, 649):

    if (rb_numparam_id_p(lid)) {
        rb_name_err_raise("numbered parameter '%1$s' is not a local variable", ...)
    }

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. "Not defined"
    is the natural reading and the wrong one.

And it uses rb_numparam_id_p, NOT rb_implicit_param_p (proc.c:517-521), which
also covers `it`. That narrowing is deliberate in MRI and necessary here: `it`
is a LEGAL local variable name -- `it = 5` compiles -- so widening the refusal
would break every binding holding a variable called `it`. There is a control
for it, and for the `_0` / `_10` / `_` boundary.

## What the bump breaks, measured

`go test ./...` over the whole repository: FOUR assertions, every one of them a
deliberate pin of the pre-4.0 behaviour, and nothing else in a 210-second VM
suite.

    internal/compiler  TestImplicitBlockParamsAreHidden    "want the numbered names kept"
    internal/vm        TestImplicitItIsInvisible           "_1 is a binding local"
    internal/vm        TestImplicitParametersAreNotLocalVariables
                         subtest: "while _1 stays visible at the version rbgo reports"
    internal/vm        TestPBRbConfigKeys                  the version string

Each is updated to the 4.0 behaviour with its comment rewritten, not flipped
silently. The third gains a case for the point that `it` and `_1` are refused
by DIFFERENT messages.

The fourth raises a question this commit does not answer: MRI may report the
API version ("4.0.0") rather than the full one for
RbConfig::CONFIG["ruby_version"]. Nothing in ruby/spec asserts that key, so the
corpus cannot settle it. Filed as #878 rather than changed on a hunch.

Refs #799
Refs #878

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* BASELINE re-recorded at 4.0.9, on the machine that enforces it

Recorded by the rubyspec-baseline lane (#877) on the pinned ubuntu-24.04 --
the same runner the ratchet gates on -- and downloaded as its artefact. Not
recorded here: this machine reads +9 against CI for no change in the code.

    23,511 -> 23,673 passing examples

## The refusal was exercised on the real case first

The lane was dispatched WITHOUT -absorb before it was dispatched with it,
because the gate added in #876 had only ever refused a synthetic loss:

    re-record: 2206 files measured, 2206 in the baseline being replaced
    -- REGRESSED (11) --
       core/objectspace/_id2ref_spec.rb: 0 passing, baseline 10 (-10)
       core/set/flatten_merge_spec.rb: 0 passing, baseline 3 (-3)
       ...
    ::error::REFUSING to re-record: 11 file(s) went backwards -- named above

Both of the lane's deliberate asymmetries held on that run: the diffstat step
ran (it carries always()) and the artefact step was SKIPPED (it does not), so
no unchanged BASELINE was offered as "the re-recorded baseline".

The second dispatch passed -absorb, and the baseline now carries the stamp:

    # ⛔ ABSORBED 11 file(s) that went backwards, recorded with -absorb on 2026-11-03:
    #     core/gc/config_spec.rb: 7 passing, baseline 8 (-1)
    #     ...

Six of the eleven are guards CLOSING -- examples 4.0 stops asking for, each
with a `ruby_version_is ""..."4.0"` site in the census -- and not defects.

## ⛔ What comparing the SETS found, which the counts hid

The local sweep predicted 13 files going backwards; CI named 11. Both missing
entries are informative:

  - 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 #871 and the move genuinely costs one example
    there. A real regression reported as a gain.

That is a structural blind spot in the gate: a per-file floor cannot see a
regression smaller than the file's unbanked improvement. Filed as #881. It is
the exact complement of #876, which stops a re-record banking a LOSS; this is
the cost of not banking a WIN -- and it existed because until #877 there was no
correct way to re-record at all.

This fresh measurement clears the accumulated slack as a side effect.

## README

TestReadmeConformanceCountMatchesTheBaseline named all three stale sites and
the new figure, which is how the README was updated rather than by hand. The
dated table is left as the 3.4.1 sweep it is and now says so.

Refs #799
Refs #881

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The conformance population is pinned to 3.4.1 while the project measures against MRI 4.0: 294 examples are never reached

1 participant