Reject the legacy recursive if c order in for loops (0175)

[rmorozov]

Requested by Ruslan · project thread

Before: {% for x in l recursive if c %} (the old Jinja2C++ order) parsed next to Jinja2's {% for x in l if c recursive %}, so statements.loop_recursive_after_filter_reject_order sat in the statements allow-list.

After: recursive is accepted only after the filter, as in Jinja2; the legacy order is a parse error ("expected end of statement, got 'if'").

2.0 breaking change (default decision, Ruslan can override): templates using recursive if c must move to if c recursive. test/arena_switch_test.cpp was the one in-repo user and now uses the new order.

How: ParseFor no longer eats recursive before the filter; the filter's dynamic-region look-ahead (EndsWithRecursive) is unchanged. The divergence line is deleted; the corpus case already exists.

Task 0175: the other line (loop_recursive_filter_sees_outer_loop) was already gone after 0165. The include-in-loop loop item is now pinned as statements.loop_not_visible_in_include (new corpus case, allow-listed) and filed as task 0209. 0175 is marked done.

Roles: none (main session only), no verifier round (small parser change; sanitizer jobs run in CI). One push went red locally before CI: my first version also added a trailing-token check after a filter, which changed the error text for if true else hello; fixed in the second commit.

---

Generated by Claude Code