fix(hir): keep observable user code out of a folded builder (#10357)

changelog.d/10355-builder-fold-gap.md

@@ -0,0 +1,37 @@
+Fixed a 75× property-store cliff on `const o = {}; const X = 1; o.a = X;`
+(#10353). The straight-line builder fold (#6812) rewrites `const o = {}`
+plus its following `o.k = v` assignments into the object literal they spell
+out, which is what gives the object a closed anon shape, a shape-stamped
+allocation and direct stores. It only matched when the assignments followed
+the binding *immediately*, so a single ordinary declaration in between — the
+usual way initialisation code names its constants — dropped the whole
+sequence back onto the dynamic `js_put_value_set` path, where every store
+re-interns and re-coerces the key and transitions the object's shape. The
+same program with the value passed as a parameter, or with the constants
+written inline, was 75× faster, which is what made the cliff look like a
+property of the stored *value*.
+
+`fold_builder_sequences` now skips up to 64 statements between an **empty**
+`{}` binding and its first assignment, sinking the allocation below them. A
+statement is skippable only when moving the allocation past it is
+unobservable, which is the pair of conditions the value side already carries
+(`gap_stmt_is_hoistable`): it must not name the binding, and it must not be
+able to execute user code — a call can reach a hoisted
+`function peek() { return o; }` that names the binding without the statement
+naming it, which would turn a successful read into a TDZ `ReferenceError`.
+Destructuring patterns (getter-bearing property reads) and populated
+literals are excluded; sinking `const o = { a: y }` below `const y = 1`
+would hide a TDZ throw. Skipped statements keep their relative order and
+still run before every folded value.
+
+Measured with `perf stat -e instructions:u` on x86_64, 2400 iterations
+building a six-property object with `--no-auto-optimize`: 108,447,339 →
+1,399,772 instructions (77×), matching the same program with the constants
+written inline (1,401,872) or the value passed as a parameter (1,411,774).
+Nothing that folded before folds differently — the gap is an additional
+match, and a statement that fails the test leaves the original dynamic
+writes exactly as they were: `benchmarks/object-write-6812` and the
+`bench_*` corpus move by at most 0.006%, and a 12k-line file whose gaps
+never reach an assignment (maximum pre-scan work, zero folds) costs 0.019%
+more to compile. A file where the fold now applies compiles 51% cheaper,
+because 1,200 dynamic store sites become 200 stamped allocations.

changelog.d/10361-builder-fold-toprimitive.md

@@ -0,0 +1,44 @@
+Fixed the builder fold (#6812) turning a successful read into a TDZ
+`ReferenceError` when a folded value runs an implicit conversion (#10357).
+Folding `const o = {}; o.a = v;` into `const o = { a: v }` evaluates `v` before
+`o` is initialized, which is unobservable only if `v` runs no user code that
+can read `o`. `value_is_fold_safe` claimed exactly that, yet admitted every
+converting operator: `"" + w`, `-w`, `w < 1`, `w == 1` and `` `${w}` `` all call
+`w`'s `valueOf`/`toString`/`Symbol.toPrimitive`. With
+`w = { valueOf() { return o; } }` node builds `{ a: "[object Object]" }` and
+perry threw.
+
+Every such conversion could have been dropped from the predicate, but that
+would have stopped the fold's own motivating example (`o.b = r + i`) from
+folding. Instead the fold now asks whether anything *can* read the binding
+early. A binding is only readable by code that names it, so user code reached
+through a conversion must be a function-like nested in the builder's scope
+that mentions the name. `FoldScope` scans each function body (or the module)
+for such observers, and keeps that scan precise because every false positive
+costs a fold:
+
+- a function-like created after a `let`/`const` builder cannot run before it
+  (the binding is fresh per loop pass and execution within a pass only moves
+  forward); a hoisted function declaration always counts, and so does any
+  observer of a `var`, whose binding every loop pass shares;
+- a nested function-like that re-binds the name as a parameter or top-level
+  body declaration is not an observer (body declarations do not shadow
+  parameter defaults);
+- `eval` (Perry compiles a literal `eval("o")` into a closure that reads
+  `o`), `with`, an exported name and a module-level `var` make a builder
+  observable outright.
+
+The same hazard hides in a bare identifier read: a name that resolves to no
+binding reads the global object, and `Object.defineProperty(globalThis, "g",
+{ get() { return o; } })` makes that read user code. `o.a = g` threw exactly
+like the conversion. An unobservable builder folds exactly as before. On an
+observable builder, a conversion needs operands that are primitive by
+construction, and a read needs a proven declarative binding. `Visible`
+proves that from a chain built only of declarations that cover the whole
+region: a statement list's own declarations, parameters and
+function-scoped `var`s, loop heads, catch parameters, and module imports and
+declarations. A sibling block's declaration, an ambient `declare` (see
+#10363), or any `with` in the module does not count. #10355's gap statements
+share the same answers. The scan covers the enclosing function rather than
+the folded statement list, because a `var` is function-scoped and a `let` in
+one `case` is visible to every other case of its `switch`.