[exKAZUu]

Why

Comparison chains expose their operators but leave their operands unfielded. Tooling must infer the operand list from child positions. This addresses the source-order operands request in tree-sitter/tree-sitter-python#329; a chain can contain more than two operands, so binary left/right fields are insufficient.

Requirements

• required: Improve our forked tree-sitter repositories, ignoring backward compatibility; review existing and upstream issues, PRs and commits and create a dedicated nonduplicate PR for each eligible item.
• required: Run review-booster → complete-pr → release using subagents without exhausting memory, limiting Cargo to one job.
• required: Address tree-sitter/tree-sitter-python#329 by exposing the operands of arbitrary-length comparison chains as fields, alongside the existing operators field; binary left/right fields do not describe a chain.
• required: Preserve accepted syntax, existing operator fields, source ranges, highlighting and incremental parsing. Compatibility is unnecessary; tree structures may change freely.
• chosen: Keep the pinned generator/runtime ABI for this field-only change, because no new runtime support is needed.
• chosen: Add a repeated operands field to the first comparison operand and every subsequent operand. Its plural name matches the existing operators field and preserves the source-order relationship without introducing wrapper nodes or changing precedence.
• chosen: Validate actual public field traversal and standard field queries on a mixed comparison chain, then append another comparison through a real incremental edit and compare its fields/ranges with a fresh parse. The regression fails against published 4.0.0 with an unknown operands field; existing parser acceptance tests cannot catch a field-only metadata regression.
• chosen: Keep a standalone artifact freshness guard using the existing generationInputMtime helper and the same four compiled source inputs as the performance suite. With only parser.h newer than Wasm, the original three-file guard passes the public regression, while the complete input check rejects it; deleting the guard would leave focused standalone runs exposed to stale artifacts. Reusing the canonical generation-input inventory avoids a second example/corpus/config list.
• chosen: Set CARGO_BUILD_JOBS=1 and RAYON_NUM_THREADS=1 and cap ad hoc benchmarks at 1GiB RSS or smaller inputs to keep concurrent reviewers within host memory.

Customer Summary

Every comparison operand is available through the repeated operands field and standard field queries. The existing operators field remains available in matching source order.

Technical Summary

grammar.js labels the first operand and each repeated subsequent operand with the same field. It adds no wrapper nodes and changes no precedence or token alternatives. Generated parser and schema metadata carry the field to native and Wasm consumers.

Testing

Canonical generation, all 207 native and Wasm corpus cases, eight focused tests in six files, and bun run verify pass. The public API regression checks field traversal, standard queries, exact source ranges and a real incremental edit; published 4.0.0 exposes no operand fields and rejects the query with Bad field name 'operands'. A 369-source comparison covers 370 comparison nodes and 1,769 operands, mixed operators and 32/128/512-operand chains; every existing node, range and field is unchanged. The standalone freshness guard shares the existing generation-input inventory and includes the parser header: a manually newer header is rejected, restoring its timestamp makes the public regression pass, and verification passes again. Four bounded manual cases also verify nested comparisons, Unicode/multiline ranges and field-cursor traversal; replacing/deleting an internal operator and undoing both edits match fresh parsing. Full examples/fuzz/browser coverage runs in PR CI.

Notes

Seven existing code-gauge errors remain outside the change: GrammarTests.testFuncdef in both Python2 example variants (159 NCSS), the same function in both Python3 variants (187 NCSS), the Python3.8 example file (1,200 NCSS) and its test_funcdef (232 NCSS), and the external scanner dispatch (complexity 175/202 NCSS). Refactoring imported grammar fixtures or the unrelated scanner would expand this field change. Forty-six existing warnings remain. The intentional LF/CRLF example duplicates would be suitable for a code-gauge exclusion; no configuration exclusion is added.