A type argument list is split on commas without tracking nesting, so an adaptor cannot be chained

Chaining two generic structs fails in codegen:

import core::iter;

fn main() -> i32 {
  let evens = filter(range(0i64, 10i64), | x : i64 | x % 2i64 == 0i64);
  let mut scaled = map(evens, | x : i64 | x + 100i64);
  for v in scaled {
    print(v);
  }
  return 0;
}

struct without a body only allowed in a recursive struct
Codegen Error: failed to parse lowered MLIR type `!llvm.struct<"Filter<Range">`

The name arrives already cut at the comma. Map<Filter<Range, i64>, i64, i64> has a type argument that itself carries a comma, and the argument list is taken apart with a plain split(','), so Filter<Range and i64> become two arguments.

The sites that do this:

• src/syntax/expr.rs:1042, :1144, :1250 -- each splits a ty_args_str on commas
• src/codegen/lower/stmt.rs:520 -- same shape

A depth-aware split, counting < and > and only breaking at depth 0, is what these want. One helper used at each site should do it.

Single-level adaptors are unaffected and work today: map, filter, take and skip over a Range each run correctly, as does a for loop over any of them. It is only a nested one that breaks, which is exactly the chaining an iterator library exists for.

Filed while writing core::iter, which ships with single-level adaptors only because of this.

Start at the comma-splitting sites in src/syntax/expr.rs:1042, :1144, :1250 and src/codegen/lower/stmt.rs:520, then trace how ty_args_str is parsed. The shared helper should split only at nesting depth zero. Done means the shown nested map/filter example compiles and runs, while the listed single-level adaptors remain working.