chore(csharp): reconcile is_call with abc.branches, and primary-constructor space attribution

[dekobon]

Summary

Two small divergences noticed while fixing
#1406, neither
introduced by it, both worth a decision rather than being left implicit.

1. Checker::is_call disagrees with abc.branches

C#'s Checker::is_call matches only the invocation aliases. abc.branches
counts those plus ObjectCreationExpression, ConstructorInitializer, and
since #1406 the primary-constructor base call
(PrimaryConstructorBaseType / a base_list-gated ArgumentList).

So bca find --filter call and abc.branches now disagree by one more
construct than they used to. .claude/rules/grammar-dispatch.md §7 asks for
exactly this cross-walk: two predicates classifying the same nodes through
parallel matches!() drift silently, and each reads as internally
consistent from its own side.

Decide which is intended — is_call is arguably answering a narrower
question ("is this a call site a reader navigates to") than ABC's
Fitzpatrick branch rule ("function invocation or object construction"). If
the divergence is deliberate, say so in a comment at both sites; if not,
widen is_call.

2. A primary constructor opens no FuncSpace

class Sub(int x) : Base(x) has no constructor body, so no function space
is opened and the base call lands on the class space. The classic
: base(x) spelling lands on a function space.

File-level sums agree, so nothing is wrong at the aggregate. But
per-function branches_max / branches_average, and a per-function
bca check --threshold abc=N, see the two spellings differently — the
primary-constructor form contributes to the class row and never to any
function row.

That may well be correct (there is no function there to attribute it to),
but it means a codebase that migrates to primary constructors will see its
per-function ABC distribution shift without any behaviour change. Worth
recording the decision either way.

Related

• fix(abc/csharp): primary-constructor base call is not a branch #1406 — where both were noticed.
• fix(abc): constructor delegation calls score zero branches in Java and C# #1279, fix(abc/kotlin): primary-constructor superclass call is not a branch #1384 — the sibling delegation fixes.

---

Resolution

Status: Fixed (pending merge)
Commit: 2463287c on branch fix/issue-1456
Root cause: Neither divergence is a defect. Both are deliberate and
both were undocumented. (1) is_call answers "where is this called" and
ABC's branches applies Fitzpatrick's wider "function invocation or
object creation" rule; the split is the workspace convention across 13
languages, stated only in a Groovy test since #430. (2) A primary
constructor's superclass call sits in the class header — a sibling of
its parameter list, not a child — so no function space encloses it and
the branch is the class's. Fixed as documentation (trait doc, both C#
sites, the Kotlin sibling, two book sections) plus
csharp_is_call_excludes_constructors and per-space assertions on the
Kotlin primary-constructor test. No metric or predicate behaviour
changed.

[dekobon]

Fix Summary

Both divergences are real and both were verified before deciding. Neither
is a bug, and neither metric nor predicate changed: this lands the two
decisions as documentation, cross-references at both sites, and tests
that pin them.

1. is_call narrower than abc.branches — deliberate, and not C#-specific

This is the workspace convention, not a C# quirk. Surveying every
Checker::is_call against its language's ABC branch arms:

Relation	Languages
branches ⊃ is_call (construction / delegation / ?)	C#, Java, Groovy, Kotlin, C++, Mozcpp, JavaScript, MozJS, TypeScript, TSX, PHP, Ruby (super / yield), Rust (?)
the two coincide	C, Objective-C, Go, Python, Lua, Bash, Perl
neither — they diverge both ways	Tcl, iRules (a mutator command is an ABC assignment), Elixir (definition/directive Calls excluded, |> added)

So the issue's framing is right but the fix is narrower than "decide
for C#": the rule already existed, stated only in
groovy_is_call_excludes_constructors (#430), and was neither on the
trait nor visible from either C# site.

Verified at the CLI (--no-config) on

class Sub(int x) : Base(x) {
    public Sub(int a, int b) : this(a) { }
    void M() { var f = new Foo(); Helper(f); }
}

bca count -t call reports 1; abc.branches reports 4.

One premise correction. The issue and the survey both assume C#'s
three invocation_expression aliases are all live. They are not: at the
tree-sitter-c-sharp =0.23.5 pin only InvocationExpression3 (id 395)
is ever emitted. Probed with bca dump across plain, this.- and
base.-qualified calls, query clauses, lambda bodies, attribute
arguments, interpolations, when guards and constant patterns — 347 and
348 never appear. The other two arms are defensive, and the new test
carries !ast_has_kind_id drift markers saying so (grammar-dispatch §2)
rather than asserting three positives that cannot be produced.

2. Primary-constructor attribution — deliberate, now stated

Confirmed at the CLI. For

class Sub(int x) : Base(x) { }
class Classic : Base { public Classic(int x) : base(x) { } }

Sub's branch is the class space's; Classic's is its
constructor's function space. File branches_sum is 2 either way.
Kotlin is identical (class Sub(x: Int) : Base(x) vs
constructor(x: Int) : super(x)).

The mechanism is sharper than "a primary constructor opens no
FuncSpace": the superclass call sits in the class header — C#'s
base_list, Kotlin's delegation_specifiers — which is a sibling
of the primary constructor's parameter list, not a child of it.
Verified by perturbation: labelling Kotlin's PrimaryConstructor a
SpaceKind::Function moves nothing at all, precisely because the
delegation specifier is not inside it. So the attribution would survive
any future decision to open a space for the primary constructor itself,
and the comments say that rather than the weaker claim.

Changes

File	Change
big-code-analysis-ast/src/checker.rs	is_call trait doc expanded from one line into the contract + the per-language survey above; new test csharp_is_call_excludes_constructors; feature = "csharp" added to find_first_kind's gate
big-code-analysis-ast/src/checker/csharp.rs	// cross-reference at is_call naming the ABC arm and the contract
src/metrics/abc/csharp.rs	// cross-reference at csharp_count_token_branch; attribution statement on the primary-constructor arm
src/metrics/abc/kotlin.rs	same attribution statement on the ConstructorInvocation arm
src/metrics/abc.rs	kotlin_primary_constructor_superclass_call_is_a_branch now asserts per-space attribution via check_func_space / child_space, and its fixture gains the secondary-constructor contrast
big-code-analysis-book/src/commands/nodes.md	new Semantic filters section {#semantic-filters} defining all / function / call / comment / string / error
big-code-analysis-book/src/python/traversal.md	forward link retargeted from #counting-nodes (which never defined them) to #semantic-filters
big-code-analysis-book/src/metrics.md	new Where a constructor call lands {#abc-constructor-attribution} under ABC

Languages affected: none behaviourally. Documentation and tests touch
C# and Kotlin; the trait doc covers all 23.

Tests

• csharp_is_call_excludes_constructors — count -t call == 1 against a
  fixture holding all four constructions plus one real call, direct
  !is_call assertions on object_creation_expression,
  constructor_initializer, primary_constructor_base_type and the
  base_list-gated argument_list, and §2 drift markers on the two
  unemitted invocation aliases.
• kotlin_primary_constructor_superclass_call_is_a_branch — per-space
  branches() on Sub (class, 1), Plain (0), make (0) and its
  object-expression space (1), Classic (class, 0) and its constructor
  space (1), plus the unchanged branches_sum.

Verified by perturbation (inverse edits from an in-memory backup, no
file-level git checkout):

Perturbation	Result
is_call widened with ObjectCreationExpression	FAIL (count 2 ≠ 1)
widened with ConstructorInitializer	FAIL
widened with PrimaryConstructorBaseType	FAIL
widened with the base_list-gated ArgumentList	FAIL
Kotlin ConstructorInvocation arm neutralised	FAIL
Kotlin DelegationSpecifier made a function space	FAIL (attribution moves)
Kotlin PrimaryConstructor made a function space	PASS — a finding, not a gap: the delegation specifier is its sibling. Recorded in the comment.

Follow-ups

• The CLI's -t/--type help still reads "Node-type name to match" and
  does not mention the six semantic filters. Widening it means a
  cargo xtask man-page regeneration in the same commit, which is out of
  scope here; the book now carries the definition.

Commit: 2463287c on fix/issue-1456