Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

LanguageExtractor.extractVariables is declared and documented but never called

Aperta
  • Qualcosa non va?
#2,465 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
devtools

Direzione di ricerca

Start in src/extraction/tree-sitter-types.ts: the extractVariables hook is declared near line 308, and VariableInfo and its doc comment sit near lines 30-32. Then find the private extractVariable method in the core extractor and see where its per-language branches and variableTypes array dispatch. Done means either the hook is called before those branches with a test covering it, or the declaration and doc comment are removed. The issue leaves that choice to the maintainers, so confirm it before editing.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

src/extraction/tree-sitter-types.ts declares a language hook that nothing calls:

// :308, as of b635dd46
extractVariables?: (node: SyntaxNode, source: string) => VariableInfo[];

VariableInfo is exported at :32, and the interface documentation at :30 refers to it — "Returned by a language's extractVariables hook" — so it reads as a supported extension point. A repo-wide search finds zero call sites in src/. Variables are actually dispatched through the private extractVariable (singular), which reads per-language } else if (this.language === …) branches plus the declarative variableTypes array.

$ grep -rn "extractVariables" src/ | grep -v tree-sitter-types | wc -l
0

Why it matters

A language author writing a new extractor finds the hook, implements it, and gets nothing back: no error, no warning, no node. That is precisely the failure mode this codebase otherwise avoids — silent misses are preferred over wrong edges, but a documented API that silently does nothing is neither.

I hit it adding Nim support. Nim's declared names live in variable_declaration > symbol_declaration_list > symbol_declaration > name, never as a direct child of the declaration, so extractVariables was the obvious hook to write. It did nothing. The working answer was a new } else if (this.language === 'nim') branch in the core's extractVariable — a core edit that a language's own file should not require just to declare variables.

Suggested fix

Either wire it up — call it from extractVariable when present, ahead of the per-language branches, since the shape it already declares is the right one — or delete the declaration and its doc comment so the next person does not follow it. If it is being kept as future work, a one-line "declared, not yet called" note at the declaration would be enough to stop the trap.

Found while adding Nim support (#2463).

Lingua principale
C
Stelle
73.2k
Fork
4.7k
Merge medio
4h 46m
PR unite (30g)
478

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di colbymchenry/codegraph

Tutte le issue di colbymchenry/codegraph

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.