fix(checker/php): is_string matches the `string` type keyword

[dekobon]

Summary

Checker::is_string for PHP lists String2 (id 25), which is the string
type keyword, not a string literal. So bca find string reports a hit on
every PHP file carrying a string type annotation.

Evidence

The same distinction is already drawn correctly one predicate over:
php_bool_terminal_kinds! (big-code-analysis-ast/src/macros/kind_sets.rs)
deliberately excludes Float2 (id 52) with a comment saying it is the
float type keyword rather than a literal. String2 is the same shape and
is included in is_string.

Why it is its own issue

This is Checker::is_string, not a metric terminal set — a different
predicate with different consumers (bca find, bca count). Nothing in the
ABC/Halstead path is affected, which is why the 2026-09-14 batch left it
alone rather than widening a metric fix into a classifier change.

It is nonetheless the .claude/rules/grammar-dispatch.md §7 case: sibling
predicates classifying the same node differently drift silently, and each
reads as internally consistent from its own side.

Before fixing

• Confirm with bca dump which id a string type annotation versus a string
  literal actually carries at the pinned grammar, and enumerate every
  numeric-suffix alias of both (§1).
• Cross-walk the §7 pairs named in the rule: is_string ↔ get_op_type
  string classification, and check whether Halstead currently agrees or
  disagrees with is_string here.
• Check the sibling languages in the same group — Java, C#, Kotlin and Groovy
  all have type keywords that could be spelled as a literal-looking kind.

Related

• fix(abc): non-numeric truthy literals score no condition #1462 — where the Float2 exclusion rationale is recorded.

---

Resolution

Status: Fixed (pending merge)
Commit: c755fafa on branch fix/issue-1474
Root cause: PhpCode::is_string listed Php::String2 (kind_id 25),
the string type keyword — a node the grammar emits only as the sole
child of a primitive_type wrapper. bca find -t string / bca count string reach that predicate through is_string_with_code, so every PHP
type annotation was reported as a string literal. #288's two
justifications for the arm had both been retired already: #1293 moved
String2 into get_op_type's primitive_type-suppression arm, and
#1261 removed the identical keyword aliases from TypeScript and TSX.

PHP was the only language affected — Java, C#, Kotlin and Groovy spell
their string types as type_identifier / predefined_type and list
none of them, and the JS-family String2 aliases are literals. Measured
corpus impact: php/strings.php 24 → 12 hits, php/classes.php
27 → 8 (earlier triage in this thread estimated 24 → 8, which was
wrong).

[dekobon]

Fix Summary

Root cause. PhpCode::is_string listed Php::String2 (kind_id 25),
which bca dump shows appearing only as the sole child of a
primitive_type:261 wrapper — it is the string type keyword, never
a literal. bca find -t string / bca count string route the literal
filter word string through Parser::filters
(big-code-analysis-ast/src/parser.rs:171) to is_string_with_code,
which PHP does not override, so every type annotation was reported as a
string.

Both justifications recorded when 8725e636 (#288) added the arm have
since been retired:

• fix(getter/php): type and qualified-name wrappers double-count their leaves in Halstead N2 #1293 moved String2 into get_op_type's primitive_type-suppression
  arm (getter/php.rs), so the claimed Halstead parity now argues the
  other way.
• fix(getter/typescript): the string type keyword counts as operator and operand #1261 removed the identical keyword aliases from TypeScript
  (String2) and TSX (String3) for exactly this reason.

Correction to the issue's framing. The issue asks whether Halstead
currently agrees or disagrees with is_string here. It already agreed
with the fix, not with the bug — #1293 landed that side first, and this
change is the classifier catching up.

Changes

File	Change
big-code-analysis-ast/src/checker/php.rs	Drop String2 from impl_simple_is_string!; rewrite the rationale in the shape checker/typescript.rs uses. String3 (hidden _string supertype) stays as the defensive arm.
big-code-analysis-ast/src/checker.rs	Replace php_is_string_matches_string_alias_kinds (which asserted the bug) with php_is_string_excludes_type_keyword_alias_1474; drop String2 from the assert_variants_is_string! block and rewrite its header.
big-code-analysis-ast/src/getter/php.rs	§7 cross-walk comment claimed is_string lists String2 — rewritten.
big-code-analysis-ast/src/alterator.rs	Arm keeps Php::String2; comments no longer claim is_string parity. Flattening a childless keyword is a no-op versus get_default, and deleting it would be grammar-dispatch §6's narrow-by-deletion.
big-code-analysis-ast/src/macros/kind_sets.rs	php_bool_terminal_kinds!'s note that is_string "does list String2" inverted into a supporting precedent (net-zero lines — the file is at its loc.sloc baseline).
.claude/rules/macro-comments.md	Worked example used the real PHP arm; updated so it still matches it.
docs/development/lessons_learned.md	Lesson 35's TypeScript paragraph is present-tense and has been false since #1261; appended one sentence recording that both TS and PHP resolved the disagreement by withdrawing the keyword.

Languages affected

PHP only. Swept all 29 is_string invocations under
big-code-analysis-ast/src/checker/ and read every variant list. The
sibling group the issue names is clean: Java, C#, Kotlin and Groovy spell
their string types as type_identifier / predefined_type, and none of
those kinds is listed. Javascript::String2, Mozjs::String2 and
Tsx::String2 render "string" but are literal aliases (JS has no type
annotations; TSX's keyword is String3, excluded since #1261). PHP was
the only language whose is_string named a type keyword.

Measured impact — the numbers in the issue thread were wrong

Earlier triage estimated strings.php dropping 24 → 8 with 16 keyword
hits. The real split, measured with bca find --no-config -t string
before and after:

fixture	before	keyword hits	after
tests/repositories/big-code-analysis-output/php/strings.php	24	12	12
tests/repositories/big-code-analysis-output/php/classes.php	27	19	8

After the fix only {string:368}, {encapsed_string:367},
{heredoc:371} and {nowdoc:373} appear — no {string:25}.

Tests

php_is_string_excludes_type_keyword_alias_1474 uses a fixture carrying
all five keyword positions (property type, plain parameter, ?string, a
string|int union, return type), all four literal kinds, and a
(string) cast as a negative control. It asserts ast_has_kind_id for
String2 first so the zero below cannot hold vacuously, then zero
is_string matches for that kind, a non-zero count for Php::String
(the over-narrowing guard), and an exact end-to-end
count_php_strings == 4 through the real find/count filter chain.

Verified by revert per .claude/rules/testing.md: re-adding String2 as
an exact inverse one-line edit fails the new test with left: 5, right: 0 — the five keyword positions — and restoring it passes.

No snapshots moved: is_string feeds no metric, the single non-doc call
site is parser.rs:171, and cargo test --workspace --all-features
leaves no .snap.new under
tests/repositories/big-code-analysis-output/.

Validation

cargo fmt --check, cargo clippy --workspace --all-targets -D warnings, cargo test --workspace --all-features, and make pre-commit
(BCA_GATE: pass) all clean. No baseline refresh needed — the
kind_sets.rs edit is net-zero on loc.sloc and the rest are comment
changes that do not move loc.ploc.

Follow-ups

None. Php::String3 remains a deliberate defensive arm, still pinned
unreachable by php_hidden_string_supertype_is_unreachable.

Commit: c755fafa on branch fix/issue-1474.