fix(codegen): two silent miscompiles on poly receivers

[OriPekelman]

Two codegen fixes for polymorphic receivers

Both bugs surfaced while building tep, a
spinel-AOT'd Sinatra clone. Each is a silent miscompile — code runs,
no error, wrong behaviour — and each has a tiny, deterministic repro.

Repros:

• repro_01_poly_ivar_write.rb — see issue #N1
• repro_02_empty_base_method.rb — see issue #N2

Bug 1 — obj.x = v no-ops when obj's static type is a class union

The dispatch loop in compile_call_expr's if (recv.tag == SP_TAG_OBJ)
block emits arms only for explicit user methods and attr_readers.
Setter calls (mname == "x=") on a attr_writer-registered ivar fall
through with no arm, so the surrounding if (.tag == SP_TAG_OBJ) {}
block is empty. The store never executes.

Fix: add a third arm to the loop that recognises the
attr_writer shape and emits a direct ((sp_C*)recv.v.p)->iv_x = v
inside the matching cls_id branch. Also extends
poly_dispatch_return_type to recognise setters so the result temp's
C type matches the ivar slot type (Ruby returns the rhs from x=,
not an int default).

Bug 2 — subclass override silently dropped when its return type is nil

box_value_to_poly for at == "nil" previously returned the bare
literal "sp_box_nil()", discarding the val argument. The
dispatch loop calls this with val = "sp_<Subclass>_method(...)" —
the actual method call is dropped, the cls_id arm just produces
sp_box_nil(), and the body of the override never runs.

This bites any base-class method with an empty body (or any subclass
override whose final expression is puts ... / Hash[]= / similar
nil-returning side effect).

Fix: emit the val for its side effect, then yield nil:

return "((void)(" + val + "), sp_box_nil())"

The (void) cast suppresses the otherwise-benign "expression result
unused" warning under -Wall configurations.

Verification

• Both repros now print the expected output.
• make test passes (425/425).
• The downstream tep project's full Sinatra-compat test suite still
  passes (57/57), and several workarounds in tep can now be removed
  (renaming Request#body → Request#raw_body to avoid the
  poly-write bug; placeholder 0 returns in filter base methods to
  dodge the nil-return drop).

What this doesn't cover

• The String#index returns -1 instead of nil divergence (filed
  as a separate issue, no PR — the choice between matching CRuby
  semantics vs. documenting the divergence is a maintainer call).
• Other patterns where method-parameter types fall back to int in
  the absence of a concrete call site (deferred until I have a
  cleaner repro).

[gemini-code-assist]

Code Review

This pull request introduces regression tests for polymorphic dispatch, specifically addressing issues where setter calls on class unions were ignored and subclass overrides returning nil were skipped. The tests verify that instance variable assignments occur and that method bodies are executed. The review feedback suggests strengthening these tests by explicitly verifying the return values of the setter expressions and dispatched calls, and by adding test cases for shared instance variables with differing types to ensure proper polymorphic boxing.

[gemini-code-assist]

The PR description mentions that poly_dispatch_return_type was extended to ensure the return value of the setter matches the assigned value's type. However, the current test only verifies the side effect (the write to the ivar) and not the return value of the assignment expression itself. It would be more robust to verify that set_x and set_body return the expected value (e.g., by wrapping the calls in puts).

[gemini-code-assist]

The current test for shared ivar names uses String for both Req#body and Res#body. To fully exercise the fix in poly_dispatch_return_type (which handles matching the C type to the ivar slot), it would be beneficial to add a case where the shared ivar has different types in different classes (e.g., String in one and Integer in another). This would verify that the polymorphic return value is correctly boxed when the types in the class union diverge.

[gemini-code-assist]

While the test correctly verifies that the subclass override is executed via its side effect (puts), it doesn't verify that the return value of the dispatched call is correctly handled as nil. Since the fix specifically addresses nil return values in polymorphic dispatch by ensuring they are properly boxed as sp_box_nil(), adding an assertion for the return value (e.g., puts h.call_hook("ok").nil?) would provide better coverage.

[OriPekelman]

Addressed all three of @gemini-code-assist's points:

1. Return-value coverage: every setter call in test/poly_attr_writer.rb now also captures the return and prints it (ret_foo, ret_req, ret_res, ri, rs). Confirms obj.x = v evaluates to v, not just that the store happens.

2. Differing slot types: added a third subcase (IBox#slot:int, SBox#slot:String) to exercise the path where poly_dispatch_return_type widens to poly because the two arms disagree on slot type. Required a small follow-up in the new arm itself: when slot is concrete and the rhs is poly (because the function param widened from divergent call sites), the rhs gets unboxed via unbox_poly_to(slot_t, ...) before the store. Without this, the C compiler errors with "assigning to mrb_int from incompatible type sp_RbVal" — the IBox and SBox arms need different concrete unboxes.

3. Nil return assertion: test/poly_nil_return_dispatch.rb now captures the result of h.call_hook("ok") and prints result == nil (true). Confirms the boxing path didn't just preserve the side effect but also yielded a properly nil-tagged value to the caller.

Re: Windows CI — file_class_methods_int_recv was already failing on master before this PR landed (see run 25562363479 on master, same failure). Pass count on Windows went from 334 to 336 with my two new tests, so the new tests pass; the pre-existing failure is unrelated.