[tannevaled]

$ rbgo -e 'def d; FOO = 1; end'   # on main
$                                 # nothing

MRI refuses that at parse time with dynamic constant assignment, and has for
many versions. rbgo refused no form of it.

It has its own spec, in a file nobody had connected to this

language/constants_spec.rb fails on Assignment dynamic assignment | raises SyntaxError — measured pass=88 fail=8 → pass=89 fail=7 with this
change, a gain this branch was not aiming at.

I reached the defect sideways, from #799's fifth item, which I had written down
as "a non-ASCII upcased character must be rejected as a constant identifier".
That title points at the lexer. The spec behind it is

-> { eval("def test\n  ἍBB = 1\nend") }.should.raise(SyntaxError, /dynamic constant assignment/)

so what it needs is this check, plus a lexer that classifies ἍBB as a
constant at all (go-ruby-parser#57 — rbgo's defined?(ἍDD) is nil where MRI
says "constant"). Running the simplest version of the example —
def t; FOO_X = 1; end, three words shorter — is what showed the real defect
was ASCII-wide and in the compiler. Corrected on #799.

The boundary is syntactic, and two measured rows prove it

	MRI	rbgo before
def d; Class.new { FOO = 1 }; end	refused	—
class C; define_method(:m) { FOO = 1 }; end	allowed	—

Both blocks end up running as a method body, so reasoning from "will this run
as a method?" gets both backwards. The rule is about an enclosing def
keyword, reached through any number of blocks and stopped by a class or
module body — which is exactly what inDefBody walks.

The other row I expected to go the other way: a scoped assignment,
C::FOO = 1, is refused inside a def too. Naming the namespace explicitly
settles where the constant would go, and upstream refuses it anyway.

Measured: eighteen shapes, eighteen agreeing

Against /usr/bin/ruby. The rule predates that interpreter by many versions, so
unlike the numbered-parameter check in #861 this oracle is a valid one here.

Refused by both, after the change — plain, through one/two/three blocks, a
lambda, Class.new, instance_eval, scoped, ::FOO, ||=, +=, masgn in
either position, nested masgn, def self.m, class << self + def, def o.m,
a nested def, a rescue clause, an ensure clause, and a default argument.

Allowed by both — the top level, a class body, a module body, a nested class
body, a block at the top level, a block in a class body, a class << self
body, define_method, module_eval, and, inside a def, a local, an ivar, a
class variable, a global, and READING a constant.

One row deliberately still diverges: def d; class I; end; end is
class definition in method body upstream and still compiles here. Different
message, different construct, different check — filed as #860, and the
inDefBody predicate this adds is what it will use.

Blast radius

No valid Ruby does this, so our own Ruby should be clean — and it is: the
prelude, stdlib and gem tests pass, which includes regenerating the frozen
prelude. language/def_spec.rb is unchanged at pass=63 fail=8 error=1.

⛔ The full internal/vm suite was NOT run to completion for this branch. The
machine is at load 37–76 on 16 cores (around forty peer sessions are building
across this fleet), and the run on the previous branch hit
panic: test timed out after 10m0s at 604s where the same suite took 297s
earlier this morning. Above roughly 8 this machine stops measuring, so I am
claiming nothing from it either way; the test lanes and the ruby/spec ratchet
here are the verdict.

Tests: internal/compiler/dynamic_constant_assignment_test.go — the refusals,
the fifteen controls, a planted positive (every control row passes with the
check deleted), a same-name/two-scopes pair proving the predicate reads the
SCOPE rather than the name, and inDefBody pinned directly through sources
whose outcome depends only on the walk.

Refs #799

🤖 Generated with Claude Code

[tannevaled]

The three arch lanes were right: a test fixture here was invalid Ruby

--- FAIL: TestCompileSupported/setconst
    codegen_test.go:84: compile "def m\n  X = 1\n  X\nend\nm":
        compile error: dynamic constant assignment

internal/aot exercised the OpSetConst codegen arm with a constant assigned
inside a def — which MRI refuses too, so the arm was being described by a
source no Ruby program can contain.

What the fixture was hiding

A method's ISeq can never legally hold OpSetConst: upstream forbids the
assignment in every form inside a def, the scoped C::X = 1 included.
Where the opcode does reach a child ISeq is a block whose lexical chain does not
cross a def, or a class/module body. methodISeq takes Children[0] whatever
kind it is, so a top-level block serves directly:

{"setconst", "[1].each { X = 1 }\nX", "block in <main>", "vm.consts["},

So this is not a workaround for the new refusal — the question of which ISeq
kinds legally carry that opcode was invisible while the old fixture stood.

⛔ Why CI found it and I did not

I ran ./internal/compiler/ and ./internal/vm/ for this branch, plus the
prelude/stdlib/gem tests, and never ./internal/aot/. A compiler change reaches
every package that compiles Ruby; the suite to run was ./....

go test ./... -count=1 now passes here — exit 0, no FAIL lines, full
internal/vm included. That also closes the one measurement I could not complete
when this PR was opened: the machine was at load 37–76 on 16 cores and the suite
had died at panic: test timed out after 10m0s, so I said then that I was
claiming nothing from it either way. It passes.

main is merged in as well (#856 has landed); the merge conflicted on this very
case list, where #856 had changed the neighbouring getgvar row to
vm.gvarGet( — both kept.

🤖 Generated with Claude Code

[tannevaled]

compiler: inDefBody's trailing return was unreachable

The macOS lane failed, and not on a percentage:

-- NEWLY BELOW 100% (1) --
   internal/compiler/compiler.go inDefBody  83.3% (was fully covered)
##[error]1 function(s) dropped below 100% -- named above

Five statements of six. The missing one was the return false after the
loop, and it is not missing a test — it cannot have one. Every builder chain is
rooted at <main>, <class:…>, <module:…>, <singleton class> or
<binding>, and none of those is a block, so the walk always leaves through the
!b.isBlock arm and never by exhausting b != nil.

So the arm returns through a break and the function ends with the single
reachable return false. inDefBody and refuseDynamicConstAssign both
measure 100.0% under go tool cover -func, the same instrument the lane uses.

⛔ Worth noting about this gate, because my own notes had it wrong: the
percentage is reported and not gated any more — coverage: 99.9% (reported, NOT gated -- see below) — and scripts/coverage/cmd/covratchet gates
per-function against scripts/coverage/BELOW100.<lane> instead. So a POSIX lane
failing here is no longer the rounding knife-edge it used to be; it names a
function, and the two "further below than recorded" rows it also printed
(bootstrap 99.6% and registerNetHTTP 92.3%) are pre-existing and ungated.
That is a strictly better gate than the one that had to be argued with.

The comment now says why the return cannot be covered, which is cheaper than
the next person rediscovering it.

Refs #799

Co-authored-by: Claude Opus 5 noreply@anthropic.com