Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

LanguageExtractor.extractVariables is declared and documented but never called

オープン
  • 何か問題がありますか？
#2,465 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
半日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
devtools

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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).

主要言語
C
スター
73.2k
フォーク
4.7k
平均マージ
2時間 16分
マージ済み PR（30日）
423

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

colbymchenry/codegraph のほかの issue

colbymchenry/codegraph の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。