runtime: "" + err / "" + arr yield "undefined" in release builds — the + ToPrimitive path lacks ArrayHeader/ErrorHeader guards (bit-casts them as ObjectHeader)

[proggeramlug]

Summary

"" + err and "" + arr evaluate to the string "undefined" in release builds. The ToPrimitive-for-+ path bit-casts a non-ObjectHeader receiver and reads its valueOf/toString out of garbage field slots.

Repro (release build)

const err = new Error("boom");
console.log("" + err);        // node: "Error: boom"   perry: "undefined"

const arr = [1, 2, 3];
console.log("" + arr);        // node: "1,2,3"         perry: "undefined"

// contrast — these are all correct:
console.log(String(err), `${err}`, String(arr), `${arr}`);

test-files/test_gap_string_coercion_tostring.ts already covers the array case (array: undefined vs node's array: 1,2,3) and is triaged in known_failures.json; this issue is the root cause.

Why

to_primitive_default_for_add (crates/perry-runtime/src/value/dynamic_arith.rs) special-cases the heap types whose header is NOT an ObjectHeader before falling through to ordinary_to_primitive_number_for_add, which does ptr as *mut ObjectHeader and reads field slots off it. There are guards for Proxy, Buffer, TypedArray, closures, Date and URL — but not for ArrayHeader or ErrorHeader, so those two fall into the bit-cast and the garbage valueOf/toString read yields undefined.

The read is UB, which is why it is optimization-sensitive: a perry-dev (opt-level=1) runtime happens to produce the right answer, while --release prints undefined. Anything that only ever tests with a dev-profile runtime will not see it.

RegExpHeader had exactly this bug and is fixed in #6370's PR by adding the missing guard next to the Date one:

if crate::regex::is_regex_pointer(ptr as *const u8) {
    // OrdinaryToPrimitive(re, "default") = valueOf, then toString
    if let Some(primitive) = exotic_own_value_of_primitive(ptr, ExoticKind::RegExp, value) {
        return primitive;
    }
    let s = crate::value::js_jsvalue_to_string(value);
    return crate::value::js_nanbox_string(s as i64);
}

Array and Error want the same treatment (Array.prototype.join(",") / the name: message form both already exist inside js_jsvalue_to_string), plus an own-valueOf first step for the "default" hint. Left out of the #6370 PR to keep that diff scoped to the own-toString override bug.

[proggeramlug]

Cannot reproduce on a correctly-built release toolchain — please re-verify before anyone acts on this

I tried to confirm this and could not, on two release builds:

build	"" + fn	"" + [1,2,3]	"" + new Error("boom")	"" + /c/gi
--release @ be5ed2bfc	function f(…)	1,2,3	Error: boom	/c/gi
--release @ 988c2d86f (current main)	function f(…)	1,2,3	Error: boom	/c/gi
node 26	same	same	same	same

All byte-identical to node. I also tried the shapes that defeat static typing — regex via a local, via a property (holder.re), via a call's return value — and after flipping the expando latch (re.toString = … on a different regex first, then coercing a plain one). All correct.

Both builds used the correct recipe, which matters here:

cargo build --release -p perry -p perry-runtime-static -p perry-stdlib-static
PERRY_RUNTIME_DIR=<target>/release <perry> repro.ts -o out && ./out

Why I suspect a build artifact rather than a code bug

perry-runtime/perry-stdlib are crate-type = ["rlib"] — building those does not emit libperry_{runtime,stdlib}.a; the archives come from the -static wrapper crates (CLAUDE.md, #5422). A build that misses them links a stale archive, and the symptom is exactly this: plausible-looking "undefined" where a header was read from the wrong layout.

I hit this myself earlier today — I reported a "" + fn → "undefined" regression against a worktree whose archives a parallel session was concurrently rebuilding, and it evaporated on a clean toolchain. The report that led here also notes its baseline gap run hit a disk-full (ENOSPC) mid-flight, which corrupted one arm.

Ask

Before this is worked: please post the exact repro (full .ts) and the exact build commands, and confirm ls -la <target>/release/libperry_runtime.a shows an mtime after the last source edit. If it still reproduces on a from-scratch release build, I'm wrong and this is real — but right now the evidence says the + path is fine.

Note this does not affect #6370 / #6383, which fixes a different, independently-reproduced bug: String(re) and `${re}` ignore an own toString override. I verified that one directly. The + guard added alongside it is harmless either way, but the claim that + is broken for Array/Error should not be treated as established.

[proggeramlug]

Re-verified on the current branch with a freshly built release toolchain, including the required static wrapper crates:

cargo build --release -p perry -p perry-runtime-static -p perry-stdlib-static
PERRY_RUNTIME_DIR=target/release target/release/perry compile --no-cache repro.ts -o out

The compiler also rebuilt its profile-correct panic=abort runtime/stdlib archives before linking, so this did not reuse a stale archive. A byte-for-byte diff against Node passed for all of these shapes:

• "" + new Error("boom") → Error: boom
• "" + [1, 2, 3] → 1,2,3
• "" + /c/gi → /c/gi
• "" + f → the function source
• the same four values read through object properties
• the same four values returned through an any pass-through function

The broader tests/test_c262_array_addition_parity.sh fixture also passed with the release binary. This confirms the follow-up diagnosis: the reported undefined output came from stale/incomplete native archives rather than the current + coercion path. Closing as not reproducible; the temporary repro was removed.