Repository navigation
Indexing gap: 1C.pas using Cyrillic identifiers #2211
Description
Version
codebase-memory-mcp 0.10.8
Platform
Windows (x64)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
ui
What happened, and what did you expect?
index_status reports 1C.pas as parse_partial. The file is indexed, but tree-sitter flags many lines that are valid Delphi 7 Object Pascal: late-bound Variant COM/OLE calls into 1C using Cyrillic identifiers (Документы, Пустая, ПолучитьОбъект, Записать, …).
Expected: Cyrillic letters are legal in Delphi identifiers. These dotted property/method chains should parse, and the unit should not be marked parse_partial for this pattern.
The same gap appears in other 1C-export units in the same project (Export1C.pas, V8.pas).
Related but not the same: #636 (Cyrillic in the repo path), #1401 (non-ASCII search queries). This is source-level Pascal identifier parsing.
Reproduction
Reproduction
Minimal shareable snippet (ASCII unit name; Cyrillic identifiers only):
unit Demo;
interface
procedure Demo1C;
implementation
procedure Demo1C;
var
v8_Base, v8_dst, NM: Variant;
begin
v8_dst := v8_Base.Документы.СчетНаОплатуПоставщика.НайтиПоНомеру('1', Now);
if v8_dst.Пустая() then Exit;
NM := v8_Base.Справочники.Номенклатура.НайтиПоКоду('123', 0);
if not NM.Пустая() then
NM.ПолучитьОбъект().Записать();
end;
end.
Index the file, then call index_status on the project.
Actual: those lines appear under parse_partial (error_ranges). Call-graph extraction for that procedure may be incomplete.
Expected: no parse error; Cyrillic identifiers treated as normal identifier nodes.
Confirmations: searched existing issues; this is not a duplicate. Reproduction uses a dummy snippet, not proprietary code.
Logs
codebase-memory-mcp could not fully index `1C.pas` (project `T-W-Dropbox-V-MEBEL-vit-PR2`) — best-effort coverage signal. Please: 1) call the index_status MCP tool and note this file's flagged line ranges under parse_partial; 2) read those ranges in the file and summarize which construct fails to parse; 3) file a GitHub issue at https://github.com/DeusData/codebase-memory-mcp/issues/new, titled "Indexing gap: 1C.pas", with the summary — include a minimal reproducible snippet ONLY if the code is shareable.
Diagnostics trajectory (memory / performance / leak issues)
Project scale (if relevant)
7047 nodes / 15083 edges
Confirmations
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Activity
DeusData commentedon Sep 25, 2026
Hi @a7in, thank you for this excellent report! The minimal snippet with ASCII-only unit names made it straightforward to reproduce, and ruling out #636/#1401 up front saved us real time.
You were right: Delphi accepts non-ASCII letters in identifiers, and the late-bound 1C OLE calls (
v8_Base.Документы...НайтиПоНомеру(...),NM.Пустая()) are perfectly valid code. The gap was in the tree-sitter Pascal grammar we vendor: its identifier token only accepts ASCII letters, so every Cyrillic name became a parse error. That flagged the unit as parse_partial, and a procedure whose own name is Cyrillic was dropped from the graph entirely.The fix (#2356) makes us maintain a small fork of that grammar with a one-line change: identifiers may start with any Unicode letter and continue with letters, combining marks, digits or
_. Keywords such asbegin/end/procedureare recognized exactly as before, and on ASCII code the new parser produces trees identical to the old one. On your snippet the file is no longer flagged, and Cyrillic-named procedures now show up as Function nodes.One expectation to set: calls to 1C's OLE members (
НайтиПоНомеру,Записать, …) go into an external COM object, so they won't become CALLS edges to anything in your repo; they'll be parsed correctly and won't hide the surrounding code anymore. If some units are saved as Windows-1251 rather than UTF-8, re-saving them as UTF-8 avoids flags on those bytes. After upgrading, please re-index 1C.pas, Export1C.pas and V8.pas from scratch and let us know if anything is still flagged. Thanks again!fix(grammar): accept non-ASCII letters in Pascal identifiers (#2211)
fix(grammar): accept non-ASCII letters in Pascal identifiers (#2211)
fix(grammar): accept non-ASCII letters in Pascal identifiers (#2211)
fix(grammar): accept non-ASCII letters in Pascal identifiers (#2211)