mspec shim: should.equal? asserts nothing — 765 uses across 328 corpus files #655

The vendored shim defines ShouldProxy#equal but not #equal?. So x.should.equal?(y) does not reach the matcher at all: it dispatches Object#equal? on the proxy object, which answers false and is discarded. The example then passes whatever the values are.

Proof, with MRI as the judge

describe "should.equal?" do
  it "should FAIL: 1.should.equal?(2)" do
    1.should.equal?(2)
  end
  it "should FAIL: 1.should.equal(2)" do
    1.should.equal(2)
  end
end

Run under ruby 4.0.5 through the shim:

RBGO_RESULT pass=1 fail=1 error=0 skip=0
RBGO_DETAIL fail SpecFail ... should FAIL: 1.should.equal(2)  expected 1 to equal 2

The equal form fails correctly. The equal? form passes while comparing 1 to 2.

Size

765 uses of `should.equal?`  across  328 files  of language/ + core/

Every one of them currently asserts nothing. Found while implementing TracePoint (#654), where 20 such sites across 7 of the 19 core/tracepoint spec files meant the specs could not be trusted as the measure — that agent wrote 24 differential probes against MRI instead, and reported that exactly one of its passing examples is vacuous and which one.

What fixing it will do, and why that is the point

Some of the 765 will start failing. That is the correct outcome, not a regression: those examples were never passing on their merits, and the conformance total is overstated by however many of them rbgo does not actually satisfy. Others will start passing genuinely.

So the floor will move in an unpredictable direction and must be re-measured rather than assumed, and a FLOOR bump that follows should say plainly that the number changed because the measurement got stricter — the same care #624 took when a shim fix raised the total.

Related: #621 (the shim's instance_eval rebinding — 41 files, 120 examples), #630 (SPEC_TMP_BASE symlink). Three defects in our own harness found in three weeks; each was counted as VM behaviour until someone ran MRI through the same shim.