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.