Context
Discovered while implementing the fix for #1920 (dynamic import() destructure extraction missing rest/default-value bindings).
Description
extractDestructuredBindings in src/extractors/javascript.ts (WASM/TS engine) and its mirror extract_destructured_bindings in crates/codegraph-core/src/extractors/javascript.rs (native engine) create constant-kind Definition nodes for each bound name in a plain object-destructuring declaration (e.g. const { a, b } = someValue;). Both only recognize shorthand_property_identifier_pattern and pair_pattern children — neither handles:
- Rest elements:
const { a, ...rest } = someValue; — rest never gets a Definition, so rest() (if later called) can never resolve to this binding.
- Default values:
const { a = 1 } = someValue; — a never gets a Definition at all.
This is the same class of bug just fixed in #1920 for extractDynamicImportNames/extract_dynamic_import_names (which populates Import.names for dynamic import() destructures), but affects a different pair of functions that populate the generic definitions array for any object-destructuring declaration, not just dynamic imports. Verified present in both engines — this is a genuine parity-preserving gap (both wrong the same way), not just a WASM-only gap.
Repro
```js
const symbols = extractSymbols(parseTree, 'test.js');
// input: const { a, ...rest } = someValue;
// symbols.definitions contains a but not rest
// input: const { a = 1 } = someValue;
// symbols.definitions does not contain a at all
```
Suggested fix
Mirror the rest_pattern/rest_element and object_assignment_pattern handling added to extractDynamicImportNames/extract_dynamic_import_names in #1920: add matching branches to extractDestructuredBindings (TS) and extract_destructured_bindings (Rust) so a rest binding gets its own constant Definition and a shorthand default's left-hand identifier is recorded.
Source
Context
Discovered while implementing the fix for #1920 (dynamic
import()destructure extraction missing rest/default-value bindings).Description
extractDestructuredBindingsinsrc/extractors/javascript.ts(WASM/TS engine) and its mirrorextract_destructured_bindingsincrates/codegraph-core/src/extractors/javascript.rs(native engine) createconstant-kindDefinitionnodes for each bound name in a plain object-destructuring declaration (e.g.const { a, b } = someValue;). Both only recognizeshorthand_property_identifier_patternandpair_patternchildren — neither handles:const { a, ...rest } = someValue;—restnever gets aDefinition, sorest()(if later called) can never resolve to this binding.const { a = 1 } = someValue;—anever gets aDefinitionat all.This is the same class of bug just fixed in #1920 for
extractDynamicImportNames/extract_dynamic_import_names(which populatesImport.namesfor dynamicimport()destructures), but affects a different pair of functions that populate the genericdefinitionsarray for any object-destructuring declaration, not just dynamic imports. Verified present in both engines — this is a genuine parity-preserving gap (both wrong the same way), not just a WASM-only gap.Repro
```js
const symbols = extractSymbols(parseTree, 'test.js');
// input: const { a, ...rest } = someValue;
// symbols.definitions contains
abut notrest// input: const { a = 1 } = someValue;
// symbols.definitions does not contain
aat all```
Suggested fix
Mirror the
rest_pattern/rest_elementandobject_assignment_patternhandling added toextractDynamicImportNames/extract_dynamic_import_namesin #1920: add matching branches toextractDestructuredBindings(TS) andextract_destructured_bindings(Rust) so a rest binding gets its ownconstantDefinition and a shorthand default's left-hand identifier is recorded.Source