[tannevaled]

vm: (1..).to_set never came back — refuse an endless range

$ timeout 6 rbgo -e '(1..).to_set'; echo $?
124

On main today. Enumerable#to_set enumerated the endless range forever,
allocating as it went. One expression, from any untrusted Ruby an embedding
host evaluates — and unlike the repr recursion fixed in #852 there is nothing to
recover from, because nothing faults: no stack overflows, no panic is raised,
the process simply never returns.

How it hid: every other member of the family was already guarded

	on main
(1..).to_a	RangeError: cannot convert endless range to an array
(1..).last	RangeError: cannot get the last element of endless range
(1..).max	RangeError: cannot get the maximum of endless range
(1..).size	Infinity
(1..).to_set	hangs

Range#to_set is new in Ruby 4.0, so there was no 3.4-era guard to copy —
and its spec sits behind ruby_version_is "4.0", which the gate cannot reach
while the shim resolves at 3.4.1 (#799). The version sweep recorded
core/range/to_set_spec.rb as "failed to load"; it had not failed to load,
the per-file TIMEOUT had killed it. I only found that out by running the file
by hand and watching it not finish.

MRI's own, and the message is asserted character for character

range.c at tag v4.0.9:

static VALUE
range_to_set(int argc, VALUE *argv, VALUE range)
{
    if (NIL_P(RANGE_END(range))) {
        rb_raise(rb_eRangeError, "cannot convert endless range to a set");
    }
    return rb_call_super(argc, argv);
}

core/range/to_set_spec.rb:22 asserts that wording exactly. The check is on
end, not on either endpoint, so a beginless range still fails from the
iteration as before (TypeError: can't iterate from NilClass) — that is a test.

Unconditional, not version-gated. No spec asserts the old behaviour —
nothing can assert a hang — so the only thing a version gate would preserve is
the way to wedge the interpreter.

Measured, with the control

core/range/to_set_spec.rb on the pinned corpus:

shim CUR_VERSION	binary	result
3.4.1	this branch	pass=3 fail=1 — BASELINE records 3, unchanged
4.0.9	this branch	pass=4 fail=1, exit 0
4.0.9	main	exit 124 — hung, no RBGO_RESULT at all

The third row is the control, and it is what makes the second mean something.

The fail=1 in both of my rows is pre-existing and unrelated: it is
Range#to_set given positional arguments | instantiates an object of provided as the first argument set class — rbgo returns a plain Set where the spec wants
the given subclass. It is why BASELINE says 3 for a file with 4 active
examples at 3.4.1, and this change neither fixes nor touches it.

Also found, and deliberately NOT changed here

min/max with a custom comparison block diverge from MRI by one word:

rbgo  : cannot get the minimum of unbounded range with custom comparison method
MRI   : cannot get the minimum of endless  range with custom comparison method   (range.c:1649)
MRI   : cannot get the maximum of beginless range with custom comparison method  (range.c:1762)

rbgo uses one format string with a %s for min/max (builtins.go:11903) and
the word unbounded for both, where MRI uses opposite words — endless for
min, beginless for max. So it is not a one-word fix but an asymmetry that is
easy to invert, and no spec asserts either message, so nothing would catch
getting it backwards. Filed rather than folded into a crash fix.

Tests in crash_hardening_test.go, beside the recursion guards, since a hang
belongs to the same class. gofmt clean, frozen prelude regenerated
(prelude_frozen_test.go is what would catch forgetting that).

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

🤖 Generated with Claude Code

[tannevaled]

Green and ready — held back on purpose, not stalled

25 of 25 checks green, CLEAN, bound to 9deb20fe (the head of this
branch). Nothing here needs re-running.

It is not merged because go-embedded-ruby/ruby is leased by another session
working the plan9 port (#855), and that session keeps renewing: I watched the
lease move 05:27 → 06:10 → 06:47 while a gated agentsync claim -wait sat on
it. agentsync claim … && ghmerge … refused and the merge did not run, which is
the protocol doing its job.

⛔ I did not get that right the first time tonight. On #851 I wrote
claim ; ghmerge instead of claim && ghmerge, the claim printed REFUSED with
the holder's name, and the merge ran anyway — into a repository someone else
held. I told the holder immediately with the list of commits so they could
rebase rather than discover it. The semicolon is the whole of that mistake, and
it is why this one is waiting.

So: whoever picks this up, it merges as-is once the lease frees. The measurement
in the description stands —

shim CUR_VERSION	binary	result
3.4.1	this branch	pass=3 fail=1, BASELINE records 3
4.0.9	this branch	pass=4 fail=1, exit 0
4.0.9	main	exit 124 — hung

— and the fail=1 in both of my rows is the pre-existing
to_set(SetSubclass) divergence, unrelated and already counted in the baseline.

🤖 Generated with Claude Code