A throw from the iterator step must not close the iterator

[lahma]

§7.4.9 IteratorStepValue sets the iterator record's [[Done]] on any abrupt completion produced by the step itself — next() throwing, next() answering a non-object, or the done/value reads throwing — and §7.4.11 IteratorClose is then never reached, because callers propagate those with ?. Only the consumer's own abrupt completion (a mapper, an adder, CreateDataPropertyOrThrow) closes the iterator.

Jint wrapped step, value-read and processing in a single try at four sites, so all three step failures closed. AddEntriesFromIterable was the one site that already got it right — which is exactly why the Map/WeakMap rows of staging/sm/Map/constructor-iterator-close.js passed while the Set/WeakSet rows failed. A second defect at the same sites: the "skip close" flag was never re-armed per iteration, so a next() that threw on the second step closed on the strength of the first step's success.

Separately, for-of closed the iterator on normal exhaustion. §14.7.5.7 step 7.d is If done is true, return NormalCompletion(V) — no IteratorClose. for-await-of had the identical defect, since step 8.e is written once for both iterator kinds.

Measured before/after, true = return() was called (expected: false,false,false,true,false,false):

                    next  done  value  consumer  2nd-next  exhausted
Array.from   before  true  true   true     true      true      false
new Map      before false false  false     true      true      false
new Set      before  true  true   true     true      true      false
for-of       before false false  false     true      true      TRUE
             after  false false  false     true     false      false   (all rows)

The fix

IteratorInstance gains [[Done]], plus TryIteratorStepValue (one try that classifies every way a step can fail) and CloseIfNotDone (the spec's If iteratorRecord.[[Done]] is false, … IteratorClose). All five sites now step through the former and close through the latter, so the per-iteration re-arm bug cannot recur — there is no per-iteration flag left to forget; skipClose is deleted, not generalised. A pooled instance resets [[Done]] on reuse.

for-of deliberately does not route through TryIteratorStepValue: that would put a try/catch region around the hottest step in the interpreter. It gets close = false at loop top instead, which also fixes its own second-step bug.

Performance

for-of pays one extra store of a bool local per iteration; IteratorInstance grows one bool field, once per loop entry. The five protocol sites get faster — they now call TryStepValue rather than TryIteratorStep + Get("value"), so Array.from(array), [...array], new Set(array) and new Map(entries) skip a per-element IteratorResult allocation and property read when the source is a value-kind array iterator. The added try costs nothing when nothing throws, and all five sites already sat inside one.

Tests

Jint.Tests/Runtime/IteratorCloseTests.cs — 9 tests, 7 failing against unfixed code, covering the six cases above across Array.from, new Map/Set/WeakMap/WeakSet and for-of. No existing test depended on the old for-of behaviour; the four candidates all use non-terminating iterators and exit abruptly.

test262: 102,332 passed, 0 failed (+6 over baseline; three files × two modes).

Note this reaches array spread, function-parameter array patterns and groupBy, which share IteratorProtocol.Execute — each spec-correct in the same direction.

Frees Array/from-iterator-close.js, Map/constructor-iterator-close.js, statements/for-of-iterator-close.js.

Refs #3021.