VB6 .frm/.cls misclassified as FORM/Apex; .bas/.ctl unmapped; no Visual Basic language

[matigumma]

Summary

Visual Basic 6 source files are indexed with the wrong tree-sitter grammar (or not at
all), because their extensions collide with two other supported languages and there is no
Visual Basic language in the table:

Ext	Current mapping (src/discover/language.c)	Correct
.frm	CBM_LANG_FORM (line 104) — the FORM symbolic-manipulation language (vermaseren/form)	Visual Basic
.cls	CBM_LANG_APEX (line 333) — Salesforce Apex	Visual Basic
.bas, .ctl, .vbs	(absent from EXT_TABLE)	Visual Basic

There is no CBM_LANG_* for Visual Basic / Basic among the 449 extension entries.

Impact

On a real VB6 codebase (~800 .frm/.cls files), indexing produced zero function nodes
for every .frm file and parsed .cls with the Apex grammar. Forms — which hold most of a
VB6 app's logic — are effectively invisible to search_graph / query_graph /
get_code_snippet. Example: a 9,960-line form with 100 procedures yielded 0 Function nodes
(only a handful of stray identifiers mislabeled as Variable).

This is an extension collision, not merely a missing language: .frm is shared with FORM
and .cls with Apex, so both currently win over (nonexistent) VB6 handling.

Repro

1. Index any VB6 project containing .frm/.cls files (e.g. forms with Private Sub … End Sub).
2. query_graph("MATCH (n:Function) WHERE n.file_path CONTAINS '.frm' RETURN count(n)") → 0.

Signatures (for disambiguation)

VB6 files are reliably distinguishable by their first line (Windows-1252 encoded, CRLF):

• VB6 form .frm: VERSION 5.00 followed by Begin VB.Form …
• VB6 class .cls: VERSION 1.0 CLASS
• FORM .frm: Symbol x;, #procedure … (no VERSION/Begin VB.)
• Apex .cls: public class …, @isTest (brace-based)

Proposed fix

(a) Short term — content disambiguation. The codebase already has the exact pattern:
cbm_disambiguate_m() (language.c:996) resolves .m between Objective-C/Magma/MATLAB by
content. Add cbm_disambiguate_frm() / cbm_disambiguate_cls() that detect the VB6 signatures
above and route them away from FORM/Apex. This alone stops the misparsing.

(b) Full support — add a Visual Basic language. Wiring (per scripts/new-languages.json):
add CBM_LANG_VBASIC to internal/cbm/cbm.h; an entry in new-languages.json pointing at a
tree-sitter VB grammar with extensions: [".frm", ".cls", ".bas", ".ctl"]; vbasic_func_types
(e.g. sub_statement, function_statement, property_*) etc. in internal/cbm/lang_specs.c;
a grammar_vbasic.c shim; tests.

Caveat for whoever picks this up: a VB6 .frm is mostly a Begin VB.Form … End GUI layout
block; the actual code starts well below it. A generic VB/VBScript grammar may need either a
VB6-aware grammar or a preprocessing step that locates the code section. This is the main
technical risk and worth scoping before committing to a grammar.

(Happy to contribute the disambiguator and/or help wire the language if there's interest.)

[DeusData]

Thanks for the concrete VB6 analysis. The extension collision point is valid: .frm and .cls need content disambiguation before we can claim reliable VB6 coverage. I’m tracking this under parsing/language coverage. Short-term disambiguation looks like the right first PR; fuller VB6/VBScript extraction can follow once the grammar/preprocessing choice is settled.

[Tokarzewski]

Following up on the short-term/long-term split proposed above — I have both parts working against a real VB6 codebase (~800k lines, 557 .cls, 126 .frm/.ctl, 80 .bas) and would like to land them in that order.

1. Short-term disambiguation — PR opened

#2074 implements the content disambiguation suggested here. It extends the existing .cls disambiguator (ObjectScript UDL vs Apex, from #467) with the VB6 header check and adds cbm_disambiguate_frm() for FORM vs VB6 forms. Because there is no Visual Basic language yet, a VB6 file is reported as unsupported (CBM_LANG_COUNT, i.e. not indexed) rather than fed to the Apex/FORM grammar. Markers used: VERSION 1.0 CLASS, VERSION x.yy on line 1, Begin VB., Attribute VB_Name. ObjectScript/Apex/FORM routing is unchanged and covered by tests.

2. Full support — proposal for your review before I open the PR

Grammar: harumiWeb/tree-sitter-vba @ 63b2f8d0d65c (v0.13.0, MIT, ABI 15, no external scanner). It parses the .frm/.cls export headers natively (VERSION, Begin … End, BeginProperty … EndProperty, GUID blocks, Attribute lines), which removes the preprocessing risk flagged in the issue — the designer block simply becomes frm_begin_block nodes and the code below parses normally. It also covers the VB6-specific statements (Declare, Implements, Event/RaiseEvent, WithEvents, Property Get/Let/Set).

Alternatives I rejected: arrmee-wt/tree-sitter-vba (GPL-3.0 — blocked by scripts/license-policy.json), joannefan/tree-sitter-vb6 (no licence file, no generated parser, README lists .frm metadata as poorly parsed), CodeAnt-AI/tree-sitter-vb-dotnet (VB.NET, different language — relevant to #1073, not here).

Caveat to decide on: upstream gitignores src/parser.c, so the vendored parser has to be generated from the pinned grammar.js with tree-sitter-cli 0.26.9 --abi 15 (the project's own pnpm generate command). It is 46 MB (case-insensitive keywords are expanded per keyword; lean's parser is 102 MB, so within precedent), and byte-identity with an upstream artefact cannot be claimed — I'd document the regeneration command in MANIFEST.md.

Extraction design (all generic paths, small language-specific hooks):

• Sub/Function/Property Get|Let|Set/Declare/Event → callables (name field); Type … End Type → Class with typed Fields; Enum → Enum with members; module-level Dim/Const → Variable; Implements → import; call_statement/call_expression/RaiseEvent → CALLS.
• .bas/.ctl/.dsr/.pag map directly; .cls/.frm are routed to VB6 by the same sniffing as in PR A (replacing its CBM_LANG_COUNT with the new language).
• Question for you: a .cls/.frm/.ctl file is one class, but the grammar has no class node. I synthesise a Class named from Attribute VB_Name, emit the file's procedures as Methods (DEFINES_METHOD), and seed the call-scope walker with the same QN so calls source to the Methods. On the test codebase that yields 680 classes / 15k methods / 45k CALLS edges with none sourced from Module nodes. If you'd rather keep the first PR to plain Functions, I can hold that part back as a follow-up.

Known grammar gaps (files still index; only those lines lack nodes): calls with a leading omitted argument (.Add , x), Print #f, …, graphics Line (x,y)-(x2,y2), _-continued comments, and .frm header Object = "{GUID}…" lines — 46 of 763 VB6 files had at least one such line.

Scope not covered: .vbs (VBScript has no header markers and a different runtime model), .vbp/.vbg project files, VB.NET.

The language-count contract (#1859) surfaces would be bumped in the same PR. Happy to split into two PRs (grammar + wiring; class-module synthesis) if that's easier to review. Does the grammar choice and the class-synthesis approach look acceptable?

[Tokarzewski]

Part two is up, split so the two decisions from my previous comment can be taken independently:

• feat(lang): add Visual Basic 6 / VBA grammar (harumiWeb/tree-sitter-vba) #2086 — feat(lang): the Visual Basic 6 / VBA grammar (harumiWeb/tree-sitter-vba @ 63b2f8d0d65c, MIT, ABI 15) and all wiring, including the language-count surfaces and MANIFEST provenance. The fix(discover): keep VB6 .frm/.cls files out of the FORM and Apex grammars #2074 sniffers now route VB6 .frm/.cls to the new language instead of "unsupported", so the "vanish silently" note on fix(discover): keep VB6 .frm/.cls files out of the FORM and Apex grammars #2074 largely dissolves. The one thing that needs your call is the provenance caveat: upstream ships no parser.c, so it is generated from the pinned grammar.js with the project's own tree-sitter-cli 0.26.9 --abi 15 command, documented in MANIFEST.md.
• feat(extract): VB6 class modules as Class + Methods (stacked on grammar PR) #2087 — feat(extract), draft, stacked on the first: class modules (.cls/.frm/.ctl) as a synthesised Class with Methods and correct call attribution. Kept separate so it can be reviewed, folded in, or declined without affecting the grammar. Its description lists the four design points (Property Get/Let/Set collapsing to one Method node, Declare/Event in a .cls as Methods, module-level Dim staying Variables, squash vs. two commits).

Both are green locally on today's main (737 and 628 tests respectively; Windows toolchain without sanitisers, so CI is authoritative). Not covered by either: .vbs, .vbp/.vbg, VB.NET (#1073).