Native complexity rules misclassify switch/case for c/cpp/kotlin/scala (and drop the switch container entirely for swift); comment-line undercounting for c/cpp/kotlin/swift/scala

[carlos-alm]

Summary

While porting the native LangRules/HalsteadRules for c/cpp/kotlin/swift/scala/bash to the TS/WASM side (#1923), several latent correctness issues were found in the existing native rules (crates/codegraph-core/src/ast_analysis/complexity.rs). All are pre-existing — unrelated to the TS-side port — and were mirrored verbatim into the new TS rules for exact engine parity, since fixing rule semantics is a separate, larger workstream from fixing rule presence (which is #1923's scope). Filing here so they don't get silently perpetuated.

Finding 1: case-node shadowing in C_RULES, CPP_RULES, KOTLIN_RULES, SCALA_RULES

In walk(), node classification order is: logical-op check → optional-chain check → is_branch(kind) (returns unconditionally on match) → pattern-C-else check → is_case(kind). So any node type listed in both branch_nodes and case_nodes is always handled as a generic branch — the case_nodes arm for that type is dead code.

Four of the five affected languages put the actual per-case node type in branch_nodes alongside (or instead of) the switch container:

• C_RULES / CPP_RULES: branch_nodes includes "case_statement" (also listed in case_nodes); the switch container "switch_statement" is not in branch_nodes at all (only in switch_like_nodes, which is only consulted from inside the branch handler).
• KOTLIN_RULES: branch_nodes includes both the container "when_expression" and the case "when_entry" (also in case_nodes).
• SCALA_RULES: branch_nodes includes both the container "match_expression" and the case "case_clause" (also in case_nodes).

Every unaffected switch-having language in the same file (JS/TS, Java, C#, PHP, Ruby, Bash) puts only the container in branch_nodes + switch_like_nodes (contributing nesting once, cyclomatic 0) and puts the case node in case_nodes only (flat cyclomatic += 1, no per-case cognitive/nesting weight). For C/C++/Kotlin/Scala, each case arm instead gets the full "regular branch" treatment (cognitive += 1 + nesting_level, cyclomatic += 1), which very likely inflates cognitive-complexity scores for every switch/when/match statement in these four languages relative to the metric's intended semantics (and relative to every other supported language).

Finding 2: SWIFT_RULES drops the switch container from complexity entirely

SWIFT_RULES.branch_nodes and .nesting_nodes never include "switch_statement" — only the per-case "switch_entry" appears (in both branch_nodes and case_nodes, hitting the same shadowing bug as Finding 1). Net effect: a Swift switch statement contributes zero nesting for its cases and each case arm is scored as an unnested "regular branch" rather than as a switch case.

Finding 3: comment_prefixes() omits */*/ continuation-line prefixes for c/cpp/kotlin/swift/scala

"javascript" | "typescript" | "tsx" | "go" | "rust" | "java" | "csharp" => {
    &["//", "/*", "*", "*/"]
}
...
"c" | "cpp" => &["//", "/*"],
"kotlin" => &["//", "/*"],
"swift" => &["//", "/*"],
"scala" => &["//", "/*"],

All of these are C-family/JVM languages with the same /** ... */ block-comment style as JS/Java/C#, but only get the 2-entry ["//", "/*"] list instead of the 4-entry list that also matches bare * continuation lines and closing */ lines. For a function with a multi-line Javadoc-style comment, only the first line (/**) is counted as a comment line for these 5 languages — undercounting commentLines and skewing the Maintainability Index input.

Scope note

Not fixed as part of #1923, which is scoped to adding missing complexity/Halstead configs for languages that have none — not auditing the correctness of configs that already exist and are already used in production by the native engine today (real native users are seeing these numbers right now; changing the methodology needs its own careful before/after validation). Both TS-side mirrors intentionally match current native behavior byte-for-byte in #1923's PR to keep native/WASM parity. Fixing the underlying branch_nodes/case_nodes/switch_like_nodes design for c/cpp/kotlin/swift/scala correctly — likely moving the container into branch_nodes+switch_like_nodes+nesting_nodes and dropping the per-case node from branch_nodes on both engines, matching the pattern already used by JS/Java/C#/PHP/Ruby/Bash — is tracked here as follow-up work.

[carlos-alm]

Update: two additional findings, plus two fixes landed directly in #1923's PR

While empirically verifying every tier-1 language's if/else handling against real tree-sitter output (not just reading the Rust source), found two more issues and fixed two of the total findings directly since they were simple, well-understood, isolated data corrections (same risk profile as a typo fix, unlike the switch/case findings above which need methodology judgment calls):

Fixed directly (in #1923's PR, both engines)

• C_RULES/CPP_RULES: else_via_alternative was set backwards. Verified via direct parse that tree-sitter-c/cpp's if_statement wraps its else-branch in a real else_clause node (if_statement → ... → else_clause(else [if_statement | <substatement>])) — this is Pattern A (JS/C#/Rust style), not Pattern C (Go/Java, alternative field holds the substatement directly, no wrapper). The rules had else_node_type: None, else_via_alternative: true, which doesn't match either the Pattern-C field lookup (no reachable "alternative" field the way the check needs) or account for the wrapper node at all. Net effect verified empirically: a canonical if {} else if {} else {} in C computed cognitive: 5, maxNesting: 2 instead of the correct cognitive: 3, maxNesting: 1 (the same value every other imperative language in this file produces for the same shape). Fixed to else_node_type: Some("else_clause"), else_via_alternative: false, plus added "else_clause" to branch_nodes (required for the Pattern-A branch to ever be reached) — verified this now produces the correct {cognitive: 3, cyclomatic: 3, maxNesting: 1}.
• BASH_RULES: else_clause was missing from branch_nodes. else_node_type/elif_node_type were already correctly configured (flat-sibling Pattern B, same shape as Python/Ruby/PHP/Lua), but branch_nodes only listed "elif_clause", not "else_clause" — so is_branch() never even reached the else-handling code for a plain trailing else, giving it zero cognitive credit. Verified empirically: if/elif/else computed cognitive: 2 instead of 3. Fixed by adding "else_clause" to branch_nodes; verified now correct.

New finding: KOTLIN_RULES/SWIFT_RULES — else_via_alternative: true doesn't match either grammar's actual shape (needs a new engine primitive, not a data fix)

Verified via direct parse + field probing that neither tree-sitter-kotlin's if_expression nor tree-sitter-swift's if_statement exposes an alternative field at all (confirmed with childForFieldName) — nor do they wrap the else branch in a dedicated else_clause node like C/C++. Instead, both wrap every if-body (consequence and alternative) in the same generic single-purpose node (Kotlin: control_structure_body; Swift: no wrapper node at all around the alternative, but the same ambiguity exists for both since "the nested if_statement's .parent() is the same node type as any other alternative-slot content, and looks identical to a nested if used elsewhere"). Because of this, detect_else_if's Pattern-C check (parent.kind() == if_node_type && parent.child_by_field_name("alternative").id == node.id) can never fire for either language — every else if in a chain gets treated as a brand-new nested branch instead of a flat chain link.

Verified empirically: if {} else if {} else {} in both Kotlin and Swift computes {cognitive: 3, cyclomatic: 3, maxNesting: 2} — cyclomatic happens to come out right, but maxNesting is inflated (should be 1), and for longer chains or chains with genuinely nested content inside a branch, cognitive would very likely diverge too since the "each else-if goes one level deeper" behavior compounds.

Unlike the C/C++/Bash fixes above, this can't be resolved with a config change — it needs a real detection mechanism (e.g., "is this node's parent a generic body-wrapper, AND is that specific wrapper instance immediately preceded by an else token among its own parent's children" — a sibling-position check the current LangRules/classify_branch/detect_else_if shared algorithm doesn't support at all today, since it currently only reasons about a node's own children (Pattern A) or named fields (Pattern C)). That's genuine algorithm design work on the shared walker used by both engines, with its own edge cases to validate (e.g. distinguishing a nested if that's part of the primary consequence's first statement from one that's the else branch, when both are wrapped in the identical node type) — appropriately out of scope for #1923's port. Kotlin/Swift's TS-side rules in #1923 intentionally mirror this known-imperfect native behavior for engine parity.