refactor: `parse_table_index_spec_for_multi` duplicates `parse_table_index_spec` byte for byte

[shunichironomura]

Warning

This content was written by an AI agent and must be verified by a human developer. After human verification, this alert may be removed.

Summary

parse_table_index_spec and parse_table_index_spec_for_multi have byte-identical bodies, and the doc comment explaining why they are separate describes a difference that no longer exists in the code.

Sites

• crates/graphcal-compiler/src/syntax/parser/table.rs:104-143
• crates/graphcal-compiler/src/syntax/parser/decl/multi.rs:580-618

diff of the two bodies (excluding the signature line) is empty.

The stale rationale

multi.rs:574-579:

Same shape as the single-decl parse_table_index_spec, but split out so the multi-decl parser can stop at the opening paren of the slot tuple without also advancing past a comma. Named axes retain their full path.

No such difference exists any more — presumably a real divergence was refactored away and the comment plus the duplicate survived.

Impact

Two copies of the Fin(N) cardinality parse (including the error text "table Fin cardinality must be a non-negative integer literal" and the ExpectedIndexFoundNat suggestion path) can now drift apart silently. A fix or a new diagnostic applied to one axis-spec parser will not reach the other.

Suggested fix

Delete parse_table_index_spec_for_multi, call parse_table_index_spec from the multi-decl path, and remove the stale comment. If a divergence is reintroduced later, encode it as an explicit parameter rather than a copied function.

Provenance

Found during a full-workspace code review at 6e462341a (v0.0.1-alpha.27). Baseline at that commit: cargo clippy --workspace --all-targets clean, cargo test --workspace 2926 passed / 0 failed, cargo deny check advisories ok.