fix(getter/bash): translated_string double-counts its string in Halstead N2

[dekobon]

Summary

BashCode::get_op_type (src/getter/bash.rs) classifies both
Bash::TranslatedString and Bash::String as HalsteadType::Operand.
At the pinned tree-sitter-bash 0.25.1, translated_string (238) has
exactly one required child — a string (237) — so a $"…" literal is
counted twice: once as the wrapper, once as the string it wraps.

This is the same wrapper/leaf shape as #1351 (command_name), found while
fixing it, in the same match.

Reproduction

$ printf 'a=$"x"\n' > a.sh
$ bca dump --no-config -p a.sh
╰─ {variable_assignment:209} : a=$"x"
   ├─ {variable_name:160} : a
   ├─ {=:9} : =
   ╰─ {translated_string:238} : $"x"
      ├─ {$:101} : $
      ╰─ {string:237} : "x"

$ bca ops --no-config -p a.sh
operands: $"x", "x", a      # honest: $"x", a

It also defeats the #180 interpolation guard

bash_string_has_expansion inspects the node's own children. A
translated_string has only $ and string as children, so it never sees
the expansion nested one level down and is classified as an operand
unconditionally — while the inner string is correctly skipped:

$ printf 'b=$"$y"\n' > b.sh
$ bca ops --no-config -p b.sh
operands: $"$y", $y, b      # honest: $y, b

So the wrapper reintroduces exactly the double count #180 removed, for the
$"…" spelling only.

Where it is reachable

translated_string surfaces on an assignment RHS, as a case subject, and
in command-name position:

a=$"x"            # variable_assignment  → translated_string → string
case $"y" in *) ;; esac
$"ls" arg         # command_name         → translated_string → string

It is not emitted in ordinary argument position — echo $"hello" parses
as a bare $ anonymous token followed by a string, with no
translated_string node at all. That asymmetry is why the bug is easy to
miss: the common spelling is already correct.

Fix

Per .claude/rules/grammar-dispatch.md §5/§6 the keeper is the node that
exists for every spelling of the construct. Here the string is present
in all three positions and the translated_string only in some, so the
wrapper is the arm to drop — but check first whether dropping it loses the
$ prefix from the recorded operand text in a way that matters for bca ops, and re-derive against case/assignment/command-name positions rather
than assuming.

Whichever direction is chosen, the $"$y" interpolating form must end up
counting $y once and nothing else, matching what #180 already guarantees
for a plain "$y".

Tests

src/metrics/halstead.rs already pins the current (wrong) value: the
translated_string row of bash_command_name_wrapper_no_double_count
records $"ls" arg as [0, 0, 3, 3] and carries a FIXME pointing here.
That row is the one to flip, plus a new case for a=$"x" and one for
b=$"$y".

Resolution

Status: Fixed (pending merge) — branch fix/issue-1358, commits
69a7f787 (fix + tests) and 6853f8cc (test-doc accuracy).

BashCode::get_op_type classified the translated_string wrapper and
the single required string child the grammar gives it, so every $"…"
was counted twice in Halstead N2 — and, because
bash_string_has_expansion inspects only a node's own children, the
wrapper also hid a nested simple_expansion and reintroduced the double
count #180 removed. The wrapper arm is gone; the string carries the
count, which is what argument position already did.

Two corrections to this issue, both measured:

• The translated_string row's _before pair becomes (3, 3), not the
  (3, 4) written above — two stacked wrappers make it a counterfactual
  against today's tree rather than a historical measurement.
• translated_string is emitted in at least eight positions, not the
  three listed; and $"${#}" now scores zero, matching what a plain
  "${#}" already scored.

See the resolution comment for the sibling sweep: the same wrapper/leaf
shape exists in Perl, Elixir, PHP, Java and the JS family, and wants
separate issues.

[dekobon]

Fixed on fix/issue-1358 (commits 69a7f787 + 6853f8cc). Not yet merged.

Every premise verified, one correction

Confirmed against the pinned tree-sitter-bash =0.25.1, not the issue transcript:

• translated_string: $ => seq('$', $.string) (grammar.js:848); node-types.json gives "multiple": false, "required": true, "types": ["string"]. The wrapper is never childless, so grammar-dispatch §6's gate-don't-delete rule genuinely does not apply.
• src/languages/language_bash.rs carries exactly one TranslatedString = 238 and one String = 237 — no numeric-suffix aliases of either, nor of RawString / AnsiCString.
• Both reproductions replayed exactly as filed, and the argument-position asymmetry holds: cmd $"hi" and echo $"hi" emit a bare $ token plus a string, with no wrapper at all.

Correction to the issue's Tests section. It says the translated_string row records [0, 0, 3, 3] and (3, 4). The [0,0,3,3] is right; the _before pair is not what the row becomes. With command_name restored against the post-#1358 tree the row measures (3, 3), and that is what it now carries — the two stacked wrappers make the pre-#1351 column a counterfactual rather than a historical measurement, which the test doc now says outright.

Also broader than filed. The issue names three wrapper-bearing positions; bca dump finds at least five more (for x in $"a", arr=($"c" d), cmd > $"f", [[ $"g" == h ]], local q=$"w"). Nothing branches on position, so the fix covers them all, but the in-code rationale no longer reads as a closed list.

One residue the issue did not anticipate. $"${#}" now scores zero, because its inner string wraps an operandless brace expansion. That is #1351's residue one level down, not a new gap — a plain a="${#}" already scored [1, 1, 1, 1] — and both positions agree on it. Two table rows and a parity row pin it.

Fix

src/getter/bash.rs — drop Bash::TranslatedString from the string arm, as #1351 did for command_name in the same match. The string is the keeper under grammar-dispatch §6 because it is present for every spelling, so the change makes wrapper-bearing positions agree with argument position rather than newly disagree.

This also repairs the #180 guard for free: with the wrapper unclassified, only the inner string is inspected, and it does see its simple_expansion child.

source	before	after
a=$"x"	"x", $"x", a	"x", a
b=$"$y"	$"$y", $y, b	$y, b
case $"y" in *) ;; esac	"y", $"y"	"y"
$"ls" arg	"ls", $"ls", arg	"ls", arg

Checker::is_string still matches the wrapper. That is not drift: bca find string reports nodes, and an interpolating "$y" is likewise a string the operand walk skips. The divergence is already pinned by bash_is_string_matches_translated_string and the assert_variants_is_string! table.

Tests

src/metrics/halstead.rs:

• bash_translated_string_wrapper_no_double_count — 7 rows (assignment RHS, empty $"", case subject, command-name position, interpolating $"$y", and the two operandless ${#} / ${!} forms), asserting N2 because n2 alone cannot see this: the wrapper and its child spell different text, so the bug split one operand into two vocabulary entries rather than repeating one.
• bash_translated_string_scores_alike_in_both_positions — the §6 keeper argument, which nothing else asserted.
• The $"ls" arg row of bash_command_name_wrapper_no_double_count flipped to [0, 0, 2, 2], (3, 3).
• ~40 duplicated lines across the two wrapper tables extracted into assert_bash_wrapper_sheds_one_operand.

Verified by perturbation, not by passing. Restoring | Bash::TranslatedString fails exactly three tests out of 4,522 in the lib suite — these three — so they are the only coverage of this bug anywhere. All 7 rows move ([1,1,2,2]→[1,1,3,3] etc.), including the two operandless ones, so none passes because zero equals zero. Each assertion in the new helper was individually neutralised and shown to fire.

An independent audit did find that the two _before-column identities cannot catch a production regression — they hold whatever get_op_type answers, and only assert_halstead_counts fails when the arm returns. 6853f8cc corrects the docstring rather than overstating the coverage.

Validation

• make pre-commit: BCA_GATE: pass (gate=pre-commit).
• src/getter/bash.rs coverage: 33 regions, 1 missed (96.97%) — unchanged by this fix; the one uncovered region is the pre-existing _ => SpaceKind::Unknown in get_space_kind. Every changed region is covered.
• No snapshot or submodule churn: the integration corpora contain no Bash sources.

Sibling sweep

All 25 modules under src/getter/ were swept for this wrapper/leaf shape (grammar node-types.json cross-referenced, then each candidate confirmed or rejected with bca ops). Clean: c, cpp, mozcpp, objc, csharp, go, groovy, kotlin, lua, python, rust, irules, tcl, and the getter-less ccomment / preproc.

The same defect was found in six other languages. Each needs its own §6 keeper analysis, tests, and metric-drift note — and the JS-family ones would churn the integration corpora — so they are not bundled here and want their own issues:

• Perl bareword_import (src/getter/perl.rs:178) — the wrapper spans the whole statement; POSIX->import(qw(floor)); scores n2 3 for two operands.
• Elixir sigil over sigil_name / sigil_modifiers — inert ~r/abc/i counts 3 operands for one literal.
• PHP dynamic_variable_name over a string child (src/getter/php.rs:174) — the fix(getter/php): every $variable counts twice in Halstead operands #1259 guard is one kind short; ${'x'} counts twice.
• Java Throws and Throws2 (src/getter/java.rs:88) — the clause node and the keyword token it contains, both operators.
• JS family (javascript, mozjs, typescript, tsx) FunctionExpression + Function, and Import + Import2 (src/getter.rs:201-202) — a function expression bills two operators where a declaration bills one.
• Ruby complex / rational — already filed as fix(getter/ruby): complex and rational literals double-count their inner numeral #1359.

Note the commit hashes may be rewritten when the branch is re-signed at merge.