Two ES5 correctness bugs: Object(null)→{} and function-declaration reassignment

[proggeramlug]

Summary

Two small, independent ES5/core-semantics correctness bugs found during the Test262/parity dive. Both are self-contained; an agent can fix both in one PR (clearly separate root causes/files).

Bug 1 — Object(null) / Object() / Object(undefined) returns undefined instead of a fresh {}

typeof Object(null)       // Perry "undefined"   Node "object"
typeof Object()           // Perry "undefined"   Node "object"
typeof Object(undefined)  // Perry "undefined"   Node "object"
// (new Object(null) also affected)

Per spec, the Object coercion function called with null/undefined/no args returns a new ordinary object. Perry returns undefined.

Where: the Object(...) call path (not new). The new path in crates/perry-runtime/src/object/class_registry.rs::js_new_function_construct already has an "Object" => js_object_alloc(0,0) arm under identify_global_builtin_constructor; the plain-call path (codegen call dispatch for the Object global / global_this.rs Object thunk) needs the same nullish→{} handling. Verify both Object(null) and new Object(null).

Bug 2 — reassigning a function-declaration binding is ignored

function G(m){ this.v = "OLD"; }
G = function(m){ this.v = "NEW"; };
new G(1).v;   // Perry "OLD"   Node "NEW"
// also: var f = G; G = otherFn; f and G should reflect the reassignment per binding semantics

A top-level function declaration's binding is treated as an immutable FuncRef at use sites, so a later G = ... reassignment doesn't take effect — new G() / G() still calls the original. Function-declaration bindings are mutable var-like bindings in JS.

Where: HIR lowering resolves an identifier that names a function to Expr::FuncRef(func_id) (see crates/perry-hir/src/lower/ — lookup_func resolution in lower_expr.rs / call + new lowering). When the name has been reassigned, the binding must read the current value (a mutable slot), not the static FuncRef. Likely needs the function name to also have a mutable local/global slot that assignment writes and reads go through once reassigned.

Acceptance criteria

• typeof Object(null) === "object", Object()/Object(undefined) return {}, new Object(null) too.
• After G = fn2, both new G() and G() invoke fn2; unre-assigned function declarations keep working (no perf/behavior regression for the common case).
• Add gap tests; differential vs node --experimental-strip-types.

Refs: Test262 radar #799, Node+TS roadmap #793.

[proggeramlug]

Working on this — both ES5 bugs (Object(null)→{} call path + function-declaration reassignment binding).

[proggeramlug]

Releasing this — Bug 1 (Object(null) call path) is clean, but Bug 2 (function-declaration reassignment) requires routing FuncRef reads + new G()/G() call/new lowering through a mutable binding slot, which touches several lowering sites and needs human review before landing on protected main. Leaving for someone who can pair the two safely.

[proggeramlug]

Bug 1 (Object(null)/Object()/Object(undefined) plain-call coercion → fresh {}) is fixed in #3530 (byte-identical gap test vs Node, incl. new Object(null) + object/array identity pass-through).

Bug 2 (function-declaration reassignment) is split out to #3531 — it needs mutable-binding-slot routing across the FuncRef read / G() call / new G() lowering sites and warrants human review before landing on protected main.

[proggeramlug]

Both ES5 bugs are fixed on current main, verified against node --experimental-strip-types:

• Object(null) → {} (typeof object, 0 own keys) — was PR fix(es5): Object(value) plain-call coercion returns a fresh object (#3149) #3530.
• function-declaration reassignment (function g(){} ; g = ...) → reassigned value is called — was PR fix(hir): honor reassigned function declarations #3344.
  Closing as resolved.