[tannevaled]

wave 32 (lang): singleton classes of nil/true/false, post parameters, !~/!/!=, and a refinement that reaches its own blocks

Four measured defects, each reproduced against MRI 4.0.5 through the same shim before it was touched, and each cited to the MRI source it was read from.

Totals, rbgo before → after, against MRI 4.0.5 run through the same shim:

tree	before	after	Δ	MRI ceiling
language/	2314	2332	+18	2627
core/	19908	19926	+18	—
both	22222	22258	+36	—

No file regressed in either tree, and core/'s 14 load failures are the same 14 (all pre-existing parse errors or signal/exit specs). FLOOR is untouched, as asked; it sits at 22205 and the measured total is 53 above it.

1. Singleton classes of nil / true / false, and a metaclass chain that reaches Class

MRI read: class.c v3_4_0 — special_singleton_class_of (:2199), singleton_class_of (:2224-2260), rb_singleton_class (:2299), make_metaclass (:766-792).

singleton_class_of has two arms for immediates. The first raises "can't define singleton" for T_FIXNUM, T_BIGNUM, T_FLOAT, T_SYMBOL. The second, just below, answers special_singleton_class_of for T_FALSE / T_TRUE / T_NIL: those three have no room for a per-object singleton, so Ruby hands back their class. rbgo drew no line and raised for all seven.

Every door now opens the same class — #singleton_class, class << nil, #define_singleton_method, #extend, #instance_eval — so a method defined "on" nil is an ordinary instance method of NilClass, as in MRI.

Separately, make_metaclass ends the metaclass chain at Class: RCLASS_SET_SUPER(metaclass, super ? ENSURE_EIGENCLASS(super) : rb_cClass). BasicObject is the only class with no superclass, so one missing link left every singleton class of a class cut off from Class — not in #ancestors, no #method_defined?, no #respond_to?.

file	before	after	MRI
language/singleton_class_spec.rb	35	47	53
language/metaclass_spec.rb	18	21	24
core/kernel/singleton_class_spec.rb	4	7	10
core/module/ancestors_spec.rb	6	8	9
core/{nil,true,false}/singleton_method_spec.rb	0 each	1 each	1 each
core/basicobject/basicobject_spec.rb	6	7	13
language/variables_spec.rb	113	114	118

TestSingletonClassErrors pinned class << nil as a TypeError — it pinned the divergence. It was updated to the MRI-verified raising set (Fixnum, Symbol, Float, Bignum, all four now covered).

2. Method#arity / #parameters see post parameters, and Proc#arity sees them after a splat

MRI read: rb_iseq_min_max_arity (proc.c v3_4_0:1073-1080), rb_iseq_parameters (iseq.c v3_4_0:3578-3660), setup_parameters_complex / args_setup_post_parameters (vm_args.c v3_4_0:595, 878-892).

param.post_num is independent of has_rest: def m(a, *r, c) has post_num 1 and so does def m(a=1, b). rbgo had each half wrong in a different place, in opposite directions — which is why #650, which fixed Proc#arity for the no-splat shape, could not have found either:

• the method half knew only the after-splat post run: def m(a=1, b) answered arity -1 for MRI's -2, and [[:opt, :a], [:opt, :b]] for MRI's [[:opt, :a], [:req, :b]];
• the proc half read is.PostCount directly, which is 0 whenever there is a splat: proc { |a, *b, c| }.arity answered -2 for MRI's -3.

Both now read iseqPostCount, which already reported both shapes. Verified byte-for-byte against MRI across the whole matrix (def, define_method, lambda, non-lambda proc, Method#to_proc, UnboundMethod, splat and no-splat, keywords, block).

This cost a defect on the way in, and TestPostParamsBindFromTheTail is the control that caught it: making iseqRequiredPositional lead+post left exec's minReq := iseqRequiredPositional(iseq) + iseq.PostCount counting the post run twice, which rejected m(9) for def m(a=1, b). Reflective counts are worth nothing unless the binder agrees with them, so the control calls the methods.

core/method/arity_spec.rb and core/proc/arity_spec.rb stop on a shared-example the shim does not implement — under MRI too — so this one is behavioural and reflective rather than something the ratchet can show.

3. #663 — !~, ! and != are dispatched, not synthesised

MRI read: object.c v3_4_0 rb_obj_not (:264), rb_obj_not_equal (:280), rb_obj_not_match (:1678) and the three rb_define_method calls (:4265, :4266, :4427); compile.c v3_4_0's specialisation table (:4260-4297); vm_insnhelper.c v3_4_0 vm_opt_not (:7019) and vm_opt_neq (:6665).

None of the three is a compiler-synthesised negation in MRI. ! and != get specialisations (opt_not, opt_neq) that compute in place only while the receiver's method is still the built-in cfunc and otherwise fall back to the send. !~ gets no specialisation at all.

The issue asked whether one cause had produced three defects. Measured, it had produced three — each with a different shape, so fixing only the one the issue named would have left two:

• !~ compiled to !(a =~ b): a user-defined #!~ was dead code, and so was Kernel#!~ itself. This is what inverted 11 assertions in the conformance shim.
• unary ! was inlined unconditionally: a redefined #! never ran anywhere.
• != dispatched, but only for a method on the class chain below BasicObject — a singleton def o.!= and a module-supplied one (o.extend M) were both invisible. Half right is the hardest kind to notice.

One resolver answers all three now (overriddenNegation, the equivalent of vm_method_cfunc_is). Kernel#!~ goes in the prelude, in Ruby, because the body is Ruby — so a redefined #=~, or a mock expecting one, is what runs, and #respond_to?, #method, #send and Kernel.instance_method(:!~) all answer as MRI's do.

internal/aot/codegen.go and level2.go had to move with the interpreter or a lowered body would answer differently for the same source; their two pinned expectations were updated. The frozen prelude was regenerated and is not byte-identical — it carries the new <module:Kernel> / !~ ISeqs, which is the check that the emitter saw the addition.

Cost, measured serially, three runs each, on a loop that does nothing but negate 10M times: 1.11s → 1.20s user, ≈ +8% of a synthetic worst case.

file	before	after	MRI
core/kernel/not_match_spec.rb	2 (+1 error)	3	3
core/exception/full_message_spec.rb	4	8	20
language/match_spec.rb	1	2	7
language/defined_spec.rb	255	256	257

4. A refinement activated in a block body now reaches the blocks written in it

MRI read: rb_vm_cref_replace_with_duplicated_cref (vm.c v3_4_0:1931) → vm_cref_replace_with_duplicated_cref (vm_insnhelper.c v3_4_0:912), from mod_using (eval.c:1547) and top_using (eval.c:1890); vm_cref_push and pushed_by_eval; rb_yield_refine_block.

using replaces the calling frame's cref with a duplicate carrying the refinements, so every block created after it captures the replacement and MRI walks the whole chain. rbgo already performed that replacement on the frame's cref entry — which is why 1.foo written directly in a Module.new { using R; … } body worked. Everything written inside it did not: the block-literal path read the lexCref local, settled before using ran. A refinement activated in such a body reached no nested block at all — not Module.new {}, not Class.new {}, not #class_eval, not #instance_eval/#instance_exec, not even [0].each { }.

rbgo keeps one *RClass per frame, so MRI's chain is approximated by its two ends — the frame's definee (MRI's pushed link: the refinement inside a refine block, the eval target inside a class_eval) and its cref (the textual one it was pushed onto), innermost first — plus Proc.refDefinee, which carries the second end onto a block so a lambda written in a method of the class still has a link back.

Consulting only the cref cost 3 examples in refine_spec (a refine block's sibling refinements hang off the pushed link); consulting only the definee was the original defect. TestCrefChainKeepsItsOtherEnd is the control for the other thing a cref is for: a constant inside a class_eval block still resolves textually, because MRI skips a pushed_by_eval cref when resolving one.

file	before	after	MRI
core/module/using_spec.rb	14	17	20
core/module/refine_spec.rb	29	30	38

What was left, and why

• language/method_spec.rb stayed at 55 of 62. Reproducing it first overturned the premise: 9 of its 16 non-passes are errors MRI has too (a shared-example the shim does not implement). Of the 7 real ones, 5 are the :strict_unused_block warning category and 2 are keyword/positional Hash separation. Neither is the arity defect, and the warning category lives in files another agent owns this wave.
• Six examples in language/singleton_class_spec.rb all need builtins.go: #is_a? resolves through classOf rather than the singleton class; Class#new / #allocate do not refuse a singleton class (and #new panics on one, recovered as an ArgumentError — worth its own issue); and a frozen object's singleton class is not frozen.
• Object.new.method(:!~).parameters answers [[:req, :other]] where MRI answers [[:req]]: MRI's is a cfunc with no parameter name and a Ruby definition must spell one. Nothing in language/ or core/ reads it.
• A module's metaclass superclass is still nil where MRI says Module (Module.new.singleton_class.superclass). The class root is fixed once at boot; the module case needs cModule where RClass.metaClass cannot reach it. No example in either tree asks.
• def nil.foo does not parse — the parser refuses nil as a def receiver. That is the external parser package, not this repo.
• core/module/using_spec.rb's remaining 3: one instance_eval shape needing a fourth chain link, and two over-activation examples that were already failing.
• Most of refine_spec's gap is indirect dispatch (#send, #respond_to?, #method, Symbol#to_proc, #binding honouring refinements), which lives in refinement.go.
• A pre-existing flake, not touched: TestWave28KernelSleepScheduler pins sleep(o) to "0" for a 0.001s sleep, while the neighbouring TestWave28SleepReturnsWholeSeconds documents that a sub-second sleep "can only answer 0 or 1". It failed once here and passed 5× on a rerun and 5× on unmodified main.

Files outside the wave's exclusive set

Two, both minimal and neither on the do-not-touch list: internal/vm/arith.go (one function body — hasCustomNeq lives there) and internal/vm/prelude.rb (one method appended). Fixing != and giving !~ a real method could not be done from the exclusive set alone, and leaving either half would have left the other lying.

🤖 Generated with Claude Code