Skip to content

fix: operator-method call names (regression from Round 4) - #7

Merged
tannevaled merged 1 commit into
mainfrom
fix-operator-method-name
Jun 26, 2026
Merged

fix: operator-method call names (regression from Round 4)#7
tannevaled merged 1 commit into
mainfrom
fix-operator-method-name

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

Round 4 regressed methodName: it returned "`" (backtick) for every explicit operator-method call (1.+(2), a.<=>(b)…), so they'd dispatch to the wrong method. Fix: use t.Type.String() for operator tokens, reserving the backtick name for the empty-XSTRING case. Adds a name-asserting test; 100% coverage.

🤖 Generated with Claude Code

methodName lumped every operator token together with the backtick XSTRING
case and unconditionally returned "`", so `1.+(2)`, `a.<=>(b)`, `obj.&(x)`
and every other explicit operator-method call parsed with method name "`"
instead of the operator. The existing tests only asserted these *parse*,
not their resulting name, so the regression went unnoticed.

Split the XSTRING (backtick-method) case out and return the operator
token's own spelling (t.Type.String()) for the operator cases. Add
TestOperatorMethodName asserting the parsed Call.Name for each operator,
plus the empty-backtick method, keeping methodName at 100% coverage.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@tannevaled
tannevaled merged commit 68a81d2 into main Jun 26, 2026
9 checks passed
@tannevaled
tannevaled deleted the fix-operator-method-name branch June 26, 2026 18:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant