Slot fast path for compound assignment to non-number bindings

[lahma]

Stacked on #2565 (the first two commits; review the last commit only).

Compound assignment to a slot-stored non-number binding (the s += "x" loop shape) fell off the fast path on both execution lanes: the discard lane's TryCompoundUnboxed bailed for any non-number left value, and completion-value positions (eval/script bodies, where expression statements must produce values) always took the materialized lane — an uncached environment-chain walk plus a Reference rent/return per iteration.

What this does

• TryCompoundUnboxed keeps its numeric lane byte-for-byte and, when the resolved slot holds an initialized mutable reference value, completes through a shared TryCompoundSlotValue: slot read → right-hand side exactly once → ComputeCompound → write-back via SetMutableBinding unless the rope concat mutated the value in place (the materialized lane's exact skip).
• EvaluateInternal gets the value-producing twin behind the same gates (no suspendable frame, no operator overloading, logical/nullish forms excluded) — this is what reaches eval bodies, whose completion-value semantics keep their statements off the discard lane entirely.
• Const and TDZ bindings bail before any evaluation, so the slow path preserves exact error ordering (RHS-then-TypeError for const, ReferenceError for TDZ).
• SlotLocationCache.ResolveAndPopulate now probes only declarative environments (their sealed HasBinding is pure) and disables without touching anything else once a non-declarative environment is reached. Test262's set-mutable-binding-idref-compound-assign-with-proxy-env.js caught the new value lane firing an extra has/Symbol.unscopables proxy trap while probing a with environment; the same latent hazard existed in the pre-existing discard lanes (i++/n += 1 inside with) and is fixed for all users of the cache.

Measurements (same-window stash A/B against the slot-backed-eval baseline, BenchmarkDotNet default job)

Benchmark	before	after	Δ
EvalHotReusedEngine	1,086.1 µs	945.4 µs	−12.9%
EvalFreshEngine	1,053.2 µs	947.9 µs	−10.0%
NewFunctionHotReusedEngine	1,166.7 µs	947.3 µs	−18.8%
PlainFunctionLoopReference	1,168.6 µs	968.4 µs	−17.1%
NewFunctionFreshEngine	1,141.6 µs	1,001.5 µs	−12.3%
ParseOnlyTmp	39.4 µs	38.9 µs	noise

Numeric guards (FunctionLocalNumberLoopBenchmark, PlainNumericAssignBenchmark): the numeric lane is unchanged; flagged rows varied ±4–5% with different rows flagging in different runs, including untouched plain-assignment code, and a same-binary triple run spans the same range (e.g. AccumulatorWithCallArg 31.5–34.0 ms on one binary) — run-to-run variance, not a code effect. The stopwatch driver, the stable canary, reads ±0.8% across all shapes.

Shape note: an earlier iteration marked the shared helper [MethodImpl(NoInlining)] to protect the numeric lane's code size; that taxed the per-iteration discard call +3..7% on the string loops and was dropped after measurement.

Combined effect with the slot-backed-eval PR this stacks on — EngineComparison rows (same-runtime worktree A/B against the common base):

Row	base	both PRs	Δ
Jint / dromaeo-core-eval	2.507 ms	1.941 ms	−22.6%
Jint_ParsedScript / dromaeo-core-eval	2.480 ms	1.909 ms	−23.0%
Jint / dromaeo-core-eval-modern	2.439 ms	1.949 ms	−20.1%
Jint_ParsedScript / dromaeo-core-eval-modern	2.427 ms	1.995 ms	−17.8%

Allocation unchanged on all rows.

Gates

• Pinning tests (CompoundAssignmentTests, 10 cases) verified to pass identically on the code before and after this change via stash cycles — including s += (s = 'z', 'a') (in-place rope append skips the write-back, so the interleaved write wins) in both discard and completion-value positions.
• Jint.Tests 3169/3107 (net10/net472), PublicInterface 79/79, CommonScripts 28/28, Test262 99,260 passed / 0 failed, all-TFM build.

🤖 Generated with Claude Code

[lahma]

Adversarial multi-agent review of the stack surfaced issues; fixed in 1722d13 (branch rebased on the updated #2565):

• Shadow-aware slot-cache hit walk (the critical one, reproduced with A/B runs): SlotLocationCache.TryResolve validated a cached hit by reference-walking to the cached environment without checking whether an intermediate environment shadows the name. The new write lanes turned a pre-existing stale-read hazard into silently writing the wrong variable (and could swallow the TypeError for a shadowing const) — reachable via cached-eval bodies under shadowing blocks, nested self-eval, and sloppy direct eval injecting a var into an enclosing function environment. The hit walk now probes each hopped declarative environment with HasBinding, mirroring the read-walk fix in Slot-backed strict-eval environments with per-source pooling #2565.
• Bounds guard in TryCompoundSlotValue (stale/torn-cache discipline, matching TryGetNumberSlot).
• Lane dedup: the discard-lane fallback goes straight to the extracted EvaluateMaterialized instead of re-running the fast-lane gates and slot resolution; each gate list now exists in exactly one place.

Perf note, measured with interleaved A/B/A/B driver runs: the shadow probe costs ~2% on the stopwatch script (closure-captured variables resolve at hop 1, paying one pure HasBinding per access); hop-0 hits — the eval/function loop rows this stack targets — are unaffected (all deltas re-verified within noise). That 2% is the price of validating against confirmed silent corruption; a cheaper validation scheme (e.g. binding-shape versioning) could be follow-up work.

Full suites + Test262 99,260/0 re-verified on the fixed stack.

🤖 Generated with Claude Code