Skip to content

deps: parser v0.2.0 — the syntax that made 13 language spec files unparseable (+333) - #625

Merged
tannevaled merged 1 commit into
mainfrom
wave26/parserbump
Sep 23, 2026
Merged

tannevaled merged 1 commit into
mainfrom
wave26/parserbump

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

Bumps github.com/go-ruby-parser/parser to v0.2.0 (go-ruby-parser/parser#28, issue #27).

The point is not the fourteen constructs themselves. Thirteen language/*_spec.rb files of the pinned corpus could not be parsed at all, so they contributed zero to both columns of the conformance measurement — they were not failing, they were invisible.

Measurement

language/ swept with the pre-bump and post-bump binaries, same corpus, same timeout:

passing fail+error
parser v0.1.9 1443 283
parser v0.2.0 1776 436

+333 passing. fail+error rises at the same time because the files that now parse bring their own failures with them, having previously contributed neither. That is the same arithmetic variables_spec produced when it was unblocked: it had 113 passing examples nobody had ever counted.

Per file, from no result at all to a result: pattern_matching 95 · predefined 68 · class 32 · hash 29 · string 23 · alias 22 · metaclass 18 · assignments 18 · undef 6.

Two of the fourteen were silent mis-parses

Worse than a refusal, because nothing diagnoses them:

o.s (:a){ 1 }          # the brace block bound to :a, not to the call
case [0,1,2,3]
in [0, 1, ]            # the trailing comma was dropped, so a partial pattern
  :partial             # became an exact one and this fell through to else
else
  :exact
end

Both verified against ruby 4.0.5 through the rbgo binary built on this bump.

Not included

Four files parse now but stop in rbgo's own compiler, and are consumer work tracked separately from this bump: for_spec (the new additive For.Target field — For.Vars is empty exactly when it is set), block_spec (block-local slots, now carried on Block.Locals), defined_spec (defined?(a += 1) declares a local no slot is allocated for — reproduces on the old parser too), variables_spec (cannot compile *ast.SplatArg).

Gates

CGO_ENABLED=0 go build ./..., full CGO_ENABLED=0 GOWORK=off go test ./... green (exit 0, no pinned test needed updating), gofmt clean, wasip1 builds.

🤖 Generated with Claude Code

…arseable

go-ruby-parser v0.2.0 closes fourteen grammar gaps, and the point of them is
not the constructs themselves: thirteen language/*_spec.rb files of the pinned
corpus could not be parsed at all, so they contributed ZERO to both columns of
the measurement. They were not failing, they were invisible.

Sweeping language/ with the pre-bump and post-bump binaries against the same
corpus, same timeout:

  parser v0.1.9   pass=1443   fail+error=283
  parser v0.2.0   pass=1776   fail+error=436

+333 passing. fail+error rises at the same time because the files that now
parse bring their own failures with them — they previously contributed neither.
That is the same arithmetic variables_spec produced when it was unblocked.

Among the fourteen, two were SILENT mis-parses rather than refusals: a brace
block written after a space, `o.s (:a){ 1 }`, bound to the argument instead of
the call; and the trailing comma of `in [0, 1, ]` was dropped, turning a partial
pattern into an exact one so `case [0,1,2,3]` fell through to `else`. Both are
verified against ruby 4.0.5 through the rbgo binary here.

Four files parse now but stop in rbgo's own compiler — for_spec (the new
For.Target field), block_spec (block-local slots), defined_spec (`defined?(a +=
1)`) and variables_spec (*ast.SplatArg). They are consumer work, tracked
separately; this commit is the bump alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@tannevaled
tannevaled merged commit 097d86a into main Sep 23, 2026
7 checks passed
@tannevaled
tannevaled deleted the wave26/parserbump branch September 23, 2026 05:56
tannevaled added a commit that referenced this pull request Sep 23, 2026
Seven units since the last bump:

  #617  core/process: spawn, exec, the rlimits, priorities, process groups,
        kill, the wait family                     (pass 20 -> 165)
  #618  core/kernel + core/string: require_relative with an absolute path,
        the require/load argument contract, LoadError#path, byteindex/
        byterindex, split, chop/chars/each_char   (kernel 233 -> 184,
                                                   string 179 -> 153 failing)
  #620  language: compound assignment evaluation order, the flip-flop
        operator, magic-comment encodings, loop break values
                                                  (pass 1308 -> 1443)
  #622  object: Float#to_s laid out by MRI's rule rather than Go's %g  (+11)
  #624  the mspec shim: a nested describe can see the helpers of the one
        around it                                                     (+28)
  #625  deps: parser v0.2.0                        (language +333)
  #626  compiler: for-loop targets, block-local variables, what defined?
        declares                                   (language +382)

Measured with scripts/conformance/rubyspec/run.sh against the pinned corpus at
87b1631, 16-way, TIMEOUT=25, three consecutive runs: 21749, 21750, 21750. The
floor is set nine below the lowest, the same margin rule as the last bump: it
absorbs the run-to-run jitter without being wide enough to hide the loss of a
whole spec file, which is what the ratchet exists to catch. #615 (an
intermittent frame-pop crash) is still open and can cost a file when it fires.

TWO OF THESE ARE NOT VM CONFORMANCE, and the number should not be read as if
they were. #624 fixed our own mspec shim: core/string/valid_encoding/utf_8_spec
scored 0/28 under MRI 4.0.5 too, so those 28 were harness noise counted as VM
failure. #625 is a dependency bump; the VM did not change, but thirteen
language spec files became parseable for the first time and brought 333 already-
passing examples into view. Both are real gains in what the measurement can
see, not in what the VM can do.

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.

1 participant