fix(abc/csharp): comparison-operator overloads other than `<` / `>` still score a condition

[dekobon]

Summary

#1297 fixed
public static bool operator <(V a, V b) scoring an ABC condition, and its
method was an enumeration of "the set of productions that can emit a bare <
or >". C# can overload six comparison operators, and the other four are
spelled with different tokens — GTEQ, LTEQ, EQEQ, BANGEQ — which
reach a separate, ungated arm of csharp_count_token_condition. They still
score a spurious condition each.

Found while measuring #1383,
whose fix gated GTEQ / LTEQ against a RelationalPattern parent but
deliberately did not widen into this.

Measured

At HEAD of fix/batch-2026-09-10 (after #1383):

class V {
    public static bool operator <(V a, V b) { return true; }
    public static bool operator >(V a, V b) { return true; }
    public static bool operator <=(V a, V b) { return true; }
    public static bool operator >=(V a, V b) { return true; }
    public static bool operator ==(V a, V b) { return true; }
    public static bool operator !=(V a, V b) { return true; }
}

declaration	abc.conditions	cyclomatic()	should be
operator <	0	1	0 ✓
operator >	0	1	0 ✓
operator <=	1	1	0 ✗
operator >=	1	1	0 ✗
operator ==	1	1	0 ✗
operator !=	1	1	0 ✗

bca dump confirms the shape — the token is a direct child of
operator_declaration, with no binary_expression anywhere:

{operator_declaration:256} : public static bool operator >=(V a, V b) { … }
  ├─ {operator:61} : operator
  ├─ {>=:82} : >=

Where

csharp_count_token_condition, src/metrics/abc/csharp.rs. After #1383 the
arms read:

EQEQ | BANGEQ | Else | Case | Try | Catch => { stats.conditions += 1.; }
GTEQ | LTEQ if !ancestors.parent_has_kind(node, RelationalPattern as u16) => { … }
GT | LT if <parent is BinaryExpression | BinaryExpression2> => { … }

Only the third has an allowlist, and only the third is #1297-clean. The
declaration's operator token is the operator being defined, not applied,
exactly as #1297 argued for < / >.

Suggested fix

Give GTEQ / LTEQ / EQEQ / BANGEQ the same BinaryExpression | BinaryExpression2 allowlist polarity GT / LT already has, which
subsumes #1383's RelationalPattern denial and fails closed on a grammar
bump (.claude/rules/grammar-dispatch.md §1). Enumerate the productions
that can emit each of the four tokens at the pinned =0.23.5 first — at
minimum binary_expression, relational_pattern (the first two only) and
operator_declaration — and confirm nothing else legitimately needs to
count.

This changes a published metric, so it wants the same corpus pass #1383 got.
Note the DeepSpeech corpus is useless for it: it contains no comparison
operator overloads either.

Sibling sweep

#1297's C# row was the only one whose construct is spelled with more than
one token family, but check whether Java's #1274 allowlist has the same gap
before closing — operator overloading does not exist in Java, but Groovy's
compareTo / equals spellings and Kotlin's operator fun compareTo should
be measured.

---

Resolution

Status: Fixed (pending merge)
Commit: f04a007 on branch fix/batch-2026-09-13
Root cause: the six comparison tokens were split across two arms of
csharp_count_token_condition with different gate polarity; the ungated and
denylisted arms let operator_declaration through for <= >= == !=.
All six now share one binary_expression parent allowlist.

[dekobon]

Fix Summary

Root cause: csharp_count_token_condition split the six comparison
tokens across two arms with different polarity. GT / LT carried a
binary_expression parent allowlist (#1297, #1383); GTEQ / LTEQ carried
only a RelationalPattern denial, and EQEQ / BANGEQ were completely
ungated. operator_declaration passed both of the latter, so four of the six
overload spellings scored a spurious condition each.

Changes:

• src/metrics/abc/csharp.rs: all six tokens merged onto one arm gated on a
  BinaryExpression | BinaryExpression2 parent. This subsumes fix(abc/csharp): relational pattern operator double-counts against its arm #1383's
  relational_pattern denial and fails closed on a grammar bump (§1).
  Else | Case | Try | Catch split out of the old shared arm to stay ungated.
  Both FIXME(#1420) blocks removed.
• src/metrics/abc.rs: new
  csharp_comparison_operator_overloads_are_not_conditions (one member per
  token, plus an applying-form control) and
  csharp_preproc_equality_counts_through_the_binary_expression_alias.
  csharp_relational_pattern_does_not_double_count_its_arm's state table
  updated — two of its four rows described a half-fix the merged arm makes
  unreachable.
• big-code-analysis-book/src/metrics.md: the < / > row now records that
  the exclusion covers all six spellings.

Languages affected: C# only.

Tests: each token gets its own member, so a partial fix names the
spelling it missed — the file total reads 4 before and 0 after, so any
two-of-four fix halves it and still looks like movement. Method n is the
§11 control (the same four tokens applied), which stops the gate being
satisfied by refusing to count them at all. Verified by revert.

Two corrections to the previous comments, both measured

BinaryExpression2. The old comment said it was listed defensively and
unreachable because C#'s preprocessor admits no bare < / >. True of
< / >, irrelevant to == / !=, which the preprocessor does admit.
The real reason it is not load-bearing: #if A == B parses as
BinaryExpression (369), so the preprocessor spelling counts through the
first entry. Now pinned in both directions, since the new gate is the only
thing keeping #if equality a condition.

Case comes from two productions, not one. switch_section and
goto_statement, so goto case 2; scores a condition without being an arm.
Left counting deliberately (C# cyclomatic counts the same token, so gating it
here alone would break §8 parity) and filed separately.

Sibling sweep

Java has no operator overloading. Groovy and Kotlin were checked; neither
spells an overload with a bare comparison token the way C# does.

Snapshots: none move — neither C# corpus declares a comparison-operator
overload.

Gate: BCA_GATE: pass (gate=pre-commit).

Commit: f04a007 on branch fix/batch-2026-09-13.