Regression (5959b64→2d1204e4): ERB/mustache interpolation blanks String values — locals-hash string values lost in template render

[OriPekelman]

Found re-testing tep's re-pin at master 2d1204e4. New value-correctness regression — interpolated String values come out blank in rendered templates:

test_simple_interpolation: expected /hello, world!/
                           got      "<h1>hello, !</h1>\n\n<p>Thanks .</p>\n"
test_loop_block:           expected /<li>item 0</
                           got      "<ul>\n\n</ul>\n"   # loop emits nothing

The values vanish; the surrounding literal HTML survives. Same shape in test_mustache (2 fail). This is the "Bug B" String-value-blanking class.

Construct

ERB rendered with a locals hash of Strings:

get '/hello/:who' do
  erb :hello, locals: { name: params[:who], mood: "happy" }
end
# view: <h1>hello, <%= name %>!</h1>  <p>Thanks <%= mood %>.</p>

Both name (a params[:who] String) and mood (a "happy" literal) blank. The translator lowers erb ... locals: {...} to a generated render method that pulls each local out of the hash and concatenates into the output String — so this is the locals-hash → String-value → concat path losing the values.

Regression window + suspects

• f6d5eef (tep's pin): PASS (19 assertions, 0 fail) · 5959b64: PASS · 2d1204e: 3 fail
• Window 5959b64..2d1204e4. Suspects in that range:
  • 59236598 (String-receiver each/unresolved → typed nil/0 stub — tep serve (full program) @a266211: String#split result typed String -> unsupported each (next blocker after #1420/#1422; whole-program, #1367 class) #1434's fix): if a legitimate String op in the render path is now mis-classified as unresolved and gated to a nil/"" stub, that would blank exactly these values. Worth checking the gate doesn't over-trigger.
  • the emit_*_call dispatch extractions (emit_hash_call / emit_scalar_call / emit_value_recv_call …) — locals is a Hash, the values are Strings.

Happy to bisect this commit-by-commit (I have builds across the range) and/or hand over the translated .tep.rb of the generated ERB render method. Flagging because it's a value-correctness regression (silent wrong output, not a compile error) and it blocks tep's re-pin alongside #1477 (proxy override dispatch).

[matz]

Confirmed the culprit: 59236598 (Extend the NoMethodError gate to String receivers), and there's a precise self-diagnostic for it.

That commit makes an unresolved call on a String receiver lower to a silent nil/"" stub instead of erroring. For the #1434 case that's correct (a statically-dead else x.each branch that never runs). But if a live String operation in the render path is unresolved by codegen, it now silently blanks instead of either working or erroring — exactly your "values vanish, literal HTML survives" symptom. Demonstration at 2d1204e4:

def f(s); out = ""; s.each { |x| out = out + x }; out; end
p f("abc")
# spinel: "" (silent)   ·   CRuby: NoMethodError

The same commit added the audit env that pinpoints this without a bisect:

SPINEL_WARN_UNRESOLVED=1 bin/spinel <tep render>.rb -c -o /dev/null

emits one line per gated site, e.g.

warning: unresolved call 'each' on string receiver -> nil (CRuby would raise NoMethodError)

Please run your tep build with SPINEL_WARN_UNRESOLVED=1 — it will name the exact call(s) being blanked in the ERB/mustache render method (the <%= name %> concat and the test_loop_block loop). That tells us which of two root causes it is:

1. a value/collection mis-inferred as String, so a legitimate op (each, or a concat) resolves to the String table, misses, and gets gated — an inference bug; or
2. a genuinely-unsupported String method in the render lowering that should be implemented rather than silenced.

Either way the fix is to resolve that specific op (or tighten the gate so a live String op isn't silently dropped); I just need the gated-call name. The .tep.rb of the render method would also do it.

Ruling out the other suspect: the emit_*_call dispatch extractions (emit_hash_call/emit_scalar_call/emit_value_recv_call, etc.) are pure code moves — emitted C is byte-for-byte identical across optcarrot and all 1007 bench/test inputs, and the gate that produces the nil/"" stub lives in the non-extracted part of emit_call. The blanking is the gate's behaviour, not the refactor. So the window narrows squarely to 59236598.

[OriPekelman]

Bisected — prime suspect is the string-heap GC trigger (#1450), not the String-receiver gate

Narrowed the window and ruled out 59236598 (your earlier suspect for the sibling issue): test_erb already fails 3/3 (the blanking) at its parent 65ffff9c. So it's earlier.

Window: 5959b64 (PASS) → 65ffff9c (FAIL, 3 blanking). The standout commit in that range is:

7cc10f21 — string-heap GC trigger + delete read-first (#1450)

String values blanking while the surrounding literal HTML survives is the textbook premature-string-heap-GC / rooting-gap symptom — and it's the same family as tep#213's "Bug B" key-blanking. Two more things point at it:

• 65ffff9c is literally Merge … fix-string-heap-gc-trigger — it fixed the build of that cluster but the blanking persists at 65ffff9c, i.e. a residual string-rooting gap in the trigger, not a build issue.
• The minimal mk_hash; l["name"]="world"; render(l) shape round-trips fine at both pins — it only blanks under the full program's string-heap pressure, exactly what a GC-trigger rooting gap needs to fire.

Couldn't isolate 7cc10f21 by building it directly — that commit and its neighbours (78979069…7cc10f21, the Ractor-milestone cluster) don't build a tep app: the generated C references sp_ractor_obj_nivars_hook / _getivar_hook / _alloc_hook, undeclared until 65ffff9c resolves them. So the GC trigger lands inside an unbuildable window from tep's side; you'll have a working build of it internally.

Repro site

ERB <%= locals["name"] %> with a String-valued locals hash:

# call site (generated):
__l = str_hash; __l["name"] = (req.params["who"]).to_s; tep_view_hello(__l, req.ivars)
# render (generated):
def tep_view_hello(locals, ivars); out=""; out += (locals["name"]).to_s; ...; end
#   -> out = "hello, !" at 2d1204e4   (locals["name"] blanks)

tep-side angle: none clean (unlike #1477)

This is a runtime string-heap rooting gap, not a code-structure issue — there's no tep-side restructure analogous to the #1477 proxy-class consolidation. It's purely upstream-gated. It's the last blocker for tep's re-pin (opts.each / broadcast / --rbs fixed upstream; proxy fixed tep-side in OriPekelman/tep#228). Happy to test a candidate fix the moment one's up.

[matz]

Strong bisect — and it lines up with the commit's own note. 7cc10f21's message explicitly flags that turning the string-heap trigger on "activates latent unrooted-string-temp gaps (#1057/#1068/#1445 class) that GC_STRESS surfaces." So a string value blanking under full-program string-heap pressure while literal HTML survives is exactly the predicted class. Your bisect away from 59236598 is convincing.

I tried to reproduce the render shape four ways and can't get it to blank locally, which tells us where the gap isn't:

• out += (locals["name"]).to_s concat render, and the interpolation form "...#{locals["name"]}...";
• the value sourced from an object-ivar hash (l["name"] = (req.params["who"]).to_s), matching your call site;
• all under SPINEL_GC_STRESS=1 (string threshold dropped to 2KB, so the trigger fires aggressively).

All stay correct. The generated render is properly rooted: the sp_StrStrHash param gets SP_GC_ROOT(lv_locals), the accumulator gets SP_GC_ROOT(lv_out), and sp_StrStrHash_scan marks both keys and values — so a value reached through the rooted hash survives a collection inside sp_str_concat's sp_str_alloc. That means the blanking temp in tep's render is reached by some path that doesn't keep it live through the rooted hash (a detached temp, a copy, or a value that's been moved out of the hash before the allocating op).

The fastest way to land this: the .tep.rb of the render method (your offer) — the exact generated lowering. With it, SPINEL_GC_STRESS=1 ./that.rb should reproduce here, and the gated/unrooted op will be obvious in the C. If it's easier, the generated C of tep_view_hello (or whatever the render fn is named) would do it too — I mainly need the precise op sequence around the blanked locals["name"]. Happy to turn a fix around quickly once I can see it fire.

[OriPekelman]

More localization at ce6995c8 (GC fix not in yet — still blanks):

It blanks deterministically, not just under SPINEL_GC_STRESS=1. Both plain and SPINEL_GC_STRESS=1 ./erbapp give <h1>hello, !</h1> — so in the full tep program there's enough string-heap pressure to fire the trigger during render/populate without forcing it. That's why your reduced shapes stay correct: they don't accumulate enough to fire the trigger at the vulnerable point.

The render fn is correctly rooted (matches what you found):

static const char * sp_tep_view_hello(sp_StrStrHash * lv_locals, sp_StrStrHash * lv_ivars) {
    SP_GC_ROOT(lv_locals); SP_GC_ROOT(lv_out);
    lv_out = sp_str_concat(lv_out, (sp_StrStrHash_get(lv_locals, "name")));   // value via rooted hash

The call site (the .to_s is elided, string→string):

sp_StrStrHash_set(lv___l, "name", sp_StrStrHash_get((lv_req)->iv_params, "who"));  // value arg = bare unrooted get

That bare get-as-set-value-arg looked like the culprit — but rooting it in a local first (_v0 = req.params["who"].to_s; __l["name"] = _v0) does NOT fix it. So the unrooted temp is deeper than the call site.

Small isolations stay correct — /echo/:who → req.params["who"], and /lit/:who → h["name"]=req.params["who"]; h["name"] both return world. Only the full erb program blanks. So it's genuinely whole-program-pressure-dependent, and I can't reduce it further from this side.

Reproduce it deterministically (tep is public, so the .tep.rb is regenerable):

git clone https://github.com/OriPekelman/tep && cd tep
SPINEL=<your spinel ≥ce6995c8> rv ... ruby -Itest test/test_erb.rb   # 3 fail = the blanking
# or to get the .tep.rb: TEP_KEEP_TMP=1 bin/tep build <erb app> -> keeps .<name>.tep.rb

test/views/hello.erb + a get '/hello/:who' { erb :hello, locals: { name: params[:who], mood: "happy" } } is the whole thing. Happy to paste the full generated .tep.rb here if you'd rather not regenerate — just say.

No tep-side angle (unlike #1477): render + call-site are both structurally fine; it's a runtime rooting gap. Last re-pin blocker.

[matz]

Yes — please paste the full generated .tep.rb for the render path. What I need is the exact op sequence around the blanked value, so specifically:

• sp_tep_view_hello (the render method), and
• the request-handler / populate method that builds the locals hash — the one with __l["name"] = req.params["who"] (the sp_StrStrHash_set(lv___l, "name", sp_StrStrHash_get(...->iv_params, "who")) site) — including everything that runs between that store and the render call.

The deterministic-without-SPINEL_GC_STRESS detail is the key clue: it means the string-heap trigger fires at a specific allocating op while the blanked value is momentarily unreachable from any root. Since rooting the call-site value didn't help, the gap is a temp deeper in that handler→render window — most likely a value that's read out of the rooted locals hash into a bare C temp and then held across an allocating op (a sp_str_concat / sp_sprintf / another ..._set) before use. The full .tep.rb (or even just those two methods plus the handler body verbatim) lets me regenerate the C here and watch it fire under SPINEL_GC_STRESS=1.

(Confirmed #1434 is a different mechanism and is already fixed/closed; this is purely the runtime rooting gap.)

[OriPekelman]

It's not GC — it's argument-temp hoisting, and it minimizes to 10 lines. I read the generated C of the handler and the value is never reaching the render:

static const char * sp_TepRoute_0_handle(...) {
    sp_StrStrHash * lv___l = NULL; SP_GC_ROOT(lv___l);
    sp_StrStrHash * _t3381 = lv___l;        // <-- arg0 temp captured HERE: lv___l is still NULL
    SP_GC_ROOT(_t3381);
    ...
    const char *_t3378 = (({ lv___l = sp_Tep_s_str_hash();          // __l assigned AFTER _t3381 captured
        sp_StrStrHash_set(lv___l, "name", sp_StrStrHash_get(...,"who"));
        sp_StrStrHash_set(lv___l, "mood", "happy");
        sp_tep_view_hello(_t3381, _t3382); }));                     // render gets stale _t3381 (==NULL)

tep_view_hello receives _t3381, copied from lv___l before the in-sequence lv___l = str_hash() runs. So it renders the empty hash → every locals[...] blanks. Rooting didn't help because nothing's collected — the populated hash is simply never passed. Deterministic, GC_STRESS-independent: all consistent.

Minimal repro ([] at ce6995c8, [world] correct)

def render(h)
  h["name"]
end
def handle
  # call's arg `a` is assigned inside the SAME sequence expr the call belongs to,
  # and the whole sequence is an operand (of `"" + ...`)
  "" + ((a = {"z" => "z"}; a.delete("z"); a["name"] = "world"; render(a)))
end
puts "[" + handle + "]"

Same logic as statements (a = ...; "" + render(a)) prints [world]. The trigger is the call-arg temp being hoisted above an assignment to that same variable earlier in the sequence-expression it's part of. Regression window unchanged (5959b64→…); my earlier string-heap-GC suspicion was a red herring (the bisect window was right, the mechanism wasn't).

tep side

Fixed it in the translator by building the hash inside the first argument (render((a = ...; setters; a), ivars)) so the assignment is part of arg evaluation — verified erb+mustache green at ce6995c8 AND no regression at the pin. But the codegen bug is general (any sequence-expr-valued call whose arg is assigned in the sequence), so worth fixing upstream. Happy to confirm a fix.