fix(extraction): name a function bound through a curried wrapper (#1747)

[maxmilian]

Fixes #1747.

reactHookBoundName already names an anonymous function after the variable_declarator that binds it. As @Dshuishui points out, the mechanism reads as a general one — it is bounded to three React hooks only by the callee test. This adds the same shape with a different bound, on both the TypeScript and the Rust kernel paths.

The bound

Not "any callee". Widening that far would give const total = useMemo(() => 1 + 1, []) a function node, and __tests__/react-hook-handlers.test.ts already asserts expect(names).not.toContain('total') — correctly, since a memo callback is a computation rather than a body worth a node.

The three shapes in the report have something narrower in common: the callee is itself a call, i.e. a factory that returns the wrapper.

shape	callee	admitted
Effect.fn("Session.run")(function* () {…})	Effect.fn("Session.run") — a call	✅
connect(mapState)(function () {…})	connect(mapState) — a call	✅
wrap("name")(() => {…})	wrap("name") — a call	✅
useMemo(() => 1 + 1, [])	useMemo — an identifier	❌
[1,2].map(() => …)	[1,2].map — a member expression	❌

So the new path is curriedWrapperBoundName / curried_wrapper_bound_name, kept beside the React one rather than replacing it: the hook allowlist keeps its own meaning and its own tests, and this reads as one additional, independently bounded rule.

Generators are the second half of the fix

This is worth calling out because it is not visible in the issue's diagnosis. generator_function is in functionTypes (languages/typescript.ts:42, javascript.ts:6, mod.rs:85), but the guards in reactHookBoundName, react_hook_bound_name and declaratorBoundFunction all accept only arrow_function | function_expression.

The report's first repro is Effect.fn("Session.run")(function* () {…}), and function* is the common form in that ecosystem — broadening the callee test alone would not have fixed it. Generators are admitted in the new method and deliberately not added to reactHookBoundName: a React handler is never a generator, so nothing is gained there and the existing bound stays exactly as it was.

Tests

__tests__/curried-wrapper-handlers.test.ts, three of them:

1. the fix — all four callee shapes (Effect.fn with a generator and with an arrow, connect, wrap) produce a function node named by the declarator.
2. the guard that makes the bound meaningful — useMemo and arr.map still produce none. If these ever start producing function nodes, the callee test has been widened past what this change claims.
3. the other half of the report — the half a node count alone does not cover: refsFrom(viaEffectGen) contains helper, and refsFrom(file) does not. That is the "a file appeared to call what the function called" symptom.

Red control — reverting only src/extraction/tree-sitter.ts to main and re-running:

× names the wrapped function after its declarator, for every callee shape
    AssertionError: expected [ 'helper' ] to include 'viaEffectGen'
× attributes the body calls to the function, not to the file
    AssertionError: no function node for viaEffectGen: expected undefined to be defined
  Tests  2 failed | 1 passed

Test 2 passes in both directions, which is what a vacuity guard should do.

Verification

• npx tsc --noEmit: clean.
• cargo build --release for the kernel: clean; npm run build:kernel stages the binding.
• __tests__/curried-wrapper-handlers.test.ts + __tests__/react-hook-handlers.test.ts: 8 passed — the React path is unchanged.
• __tests__/kernel-tsjs-parity.test.ts: 21 passed.
• node scripts/kernel-parity.mjs on a file holding all six shapes above: 1/1 files byte-parity, 0 diffs, 0 deferred-to-wasm. Since the TypeScript side is known to produce the four function nodes, byte-parity is what establishes the Rust side does too.
• Full suite after npm run build:ui: 4570 passed, 18 failed, 11 skipped.

On those 18 — I checked rather than assuming they were pre-existing. I ran the same nine files on a clean upstream/main worktree: 14 of the 18 fail there identically. The remaining 4 are all kernel-dart-parity (torture.dart / TortureCtors.dart, parity and CRLF), which that baseline run skipped because the kernel was not built in it. Building the kernel there and re-running gives the same 4 failures on unmodified main. So: 18 = 14 + 4, all pre-existing, none of them TypeScript/JavaScript extraction, and this change introduces no regression.

Notes

• CHANGELOG entry added under ## [Unreleased] → ### Fixes → #### Symbols, tests and the viewer, in user-facing language, with the re-index note.
• No version bump, no tag, no publish.
• I have not indexed sst/opencode to confirm the 1,008-function figure from the report; the mechanism is verified here, that scale claim is @Dshuishui's measurement rather than mine.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WgtWMywGTyu6twnk1Bu9nP