[ASDAlexander77]

Part of #442: the first of its two bugs. With --no-default-lib, a.map(f).map(g) failed to compile under every memory model.

Cause

Without the default library, an array's map, filter, forEach, every and some are MLIRGen builtins. map and filter build a generator and return it, and a generator had none of these methods. With the default library the same code works: its namespace __Iterator gives every iterator these methods as extension functions.

Change

• Any iterator gets the builtins. An iterator here is any object whose next() returns {value, done}: the result of map or filter, or a generator of your own.
  • The new fallback is in mlirGenPropertyAccessExpressionBaseLogic, and applies only under enableBuiltins && noDefaultLib.
  • It reuses the array builtins unchanged: each one is already a for...of over its receiver.
  • It runs after extension functions, so a user's own map still wins, as it does with the default library.
• reduce stays array-only. Its builtin is a generic function that takes T[].
• Refactors:
  • The builtin's symbol construction is moved out of MLIRPropertyAccessCodeLogic::Array into CustomMethod(elementType), so arrays and iterators share it.
  • hasIterator now wraps a new getIteratorValueType, which returns next()'s value type.
• A second bug the fix exposed: in one expression, a.map(f).map(g) then failed with "redefinition of symbol ... .next".
  • The generator was named after where its call starts, and both calls start at the same place.
  • LocationHelper::getSpan has no real span end to tell them apart.
  • The generator is now also named after its callback's location. A location gives the same name in MLIRGen's dummy and real runs, which a counter might not.

Not in this PR

• The second half of Built-in .map/.filter return a generator (no default lib): a.map(f).map(g) fails with a misleading "the condition has no value" #442: in a condition, "Can't resolve property" is replaced by "the condition has no value". The success() it comes from (the dummyRun/allowPartialResolve return in mlirGenPropertyAccessExpressionBaseLogic) is deliberate, for sibling-method discovery, so changing it is a separate change with its own risk.
• .length, [i] and reduce on a map result: they still fail. The result is a generator, not an array.
• -mm=own: every chain is rejected with "'this value' borrows a field and cannot be stored, returned or captured", the 5b capture error, because the outer map's closure box captures a generator. Phase 7b (-mm=own phase 7b: a generator over a parameter's block borrows it; .map and .filter #441) changes how generators borrow, so I'll recheck after it merges. Accepting a chain would mean a box inheriting its contents' bound, which would be new inference work.

Verification

• Release suite: 3389 of 3390 pass. The one failure, test-compile-gc-defaultlib-collector, is the stale installed default library, as on -mm=own phase 5a: a closure that does not escape borrows what it captures #436--mm=own phase 7b: a generator over a parameter's block borrows it; .map and .filter #441.

• WSL/GCC: builds; the 392 tests run there (the new ones, own, and the map/filter/every/some tests) all pass.

• Memory: a loop of chains (map.filter.map, map.forEach, map.some), AOT, measure.ps1, in MB:

  iterations	gc	rc	none
  20000	5.7	4.2	21.8
  200000	5.7	4.2	179.2

  rc stays flat, so the chained generators leak nothing.

• Own corpus: 359 compile, the same files as on main.

Tests

tests/00iterator_methods.ts covers:

• a two-call and a three-call chain in one expression;
• forEach through a variable;
• every and some, both true and false;
• the methods on a generator of your own;
• next() on a map result;
• strings.

It is registered for AOT and JIT, and in TSLANG_CORPUS, so it also runs under rc and none.

🤖 Generated with Claude Code

[ASDAlexander77]

Rechecked -mm=own with #441 merged. This branch merges into main cleanly; I built the merge locally and ran each case with --no-default-lib --di.

• Compiles and runs correctly: a single builtin on a generator, e.g. const m = a.map(f); m.forEach(print) (prints 2 4 6), g().map(f), a.map(f).every(p).
• Rejected, as it should be: reassigning the source while the generator is in use, e.g. const m = a.map(f); a = [7, 8, 9]; m.forEach(print). The error is "'m' borrows 'the generator's source' but is used here after 'the generator's source' is released or overwritten", for both map and filter.
• Still rejected, by -mm=own phase 7b: a generator over a parameter's block borrows it; .map and .filter #441's documented limits (spec §19.5):
  • Chains, e.g. a.map(f).map(g) or m.map(g): "'m' borrows its generator's arguments and cannot be stored, returned or captured". The outer map's closure box captures the inner generator. Accepting this would need a box to inherit its contents' bound, which is new inference work.
  • A capturing callback on a generator, e.g. m.forEach(x => { s += x; }): "takes a second reference".

So 00iterator_methods.ts stays in the gc/rc/none tiers only, and needs no change for own.