C# files with CRLF line endings + XML doc comments (///) silently parse to zero Method/Class nodes (v0.9.0, Windows)

[FIBlood]

Bug: C# files with CRLF line endings + XML doc comments (///) silently parse to zero Method/Class nodes (v0.9.0)

Summary

On v0.9.0 (Windows amd64), a C# file with CRLF line endings that contains XML documentation comments (///) silently fails to extract any structural nodes (Method/Class/Field) — the file degrades to producing only a single Module node with 0 Method, 0 Class, 0 CALLS. The indexer reports skipped_count: 0 and status: indexed (no error, no warning), so the failure is completely silent.

Converting the exact same file to LF line endings makes extraction work perfectly (full Method/Class/CALLS graph). Chinese/non-ASCII content is not the cause — it works fine under LF.

Environment

• Version: codebase-memory-mcp 0.9.0 (also reproduced on 0.8.1)
• Platform: Windows 10 x64 (10.0.18363)
• Binary variant: codebase-memory-mcp-ui-windows-amd64.zip
• Language: C# (tree-sitter-c-sharp)

Reproduction

The file

A real C# file from a .NET project (UTF-8 with BOM, CRLF line endings, Chinese XML doc comments). Call it LearnTypeModel.cs:

using System.Collections.Generic;
using CommunityToolkit.Mvvm.ComponentModel;

namespace FX_TestModule.Models
{
    /// <summary>
    /// 学习类型数据模型（金板建模勾选状态）。
    /// <para>
    /// 所有学习开关（器件类型开关 + 条件选项，如 ModelR/ModelRCover/ModelCCT…）统一存在
    /// <see cref="LearnSwitches"/> 字典里，key=开关名（由仪器 DLL 自报），value=勾选状态。
    /// </para>
    /// <para>
    /// 仪器 DLL 端用 GetTestParamsValue&lt;Dictionary&lt;string,bool&gt;&gt;("LearnSwitches") 读取。
    /// </para>
    /// </summary>
    public partial class LearnTypeModel : ObservableObject
    {
        public Dictionary<string, bool> LearnSwitches { get; } = new();

        public bool GetSwitch(string key, bool defaultValue = false)
            => LearnSwitches.TryGetValue(key, out var v) ? v : defaultValue;

        public void SetSwitch(string key, bool value) => LearnSwitches[key] = value;
    }
}

Important: the file must be saved with CRLF (\r\n) line endings — this is the VS / Windows default. UTF-8 BOM presence is irrelevant (tested both).

Steps

# 1. Index as-is (CRLF) — BUG: only file-tree nodes
codebase-memory-mcp cli index_repository --repo-path ./proj --mode full --name bug_crlf
codebase-memory-mcp cli get_architecture --project bug_crlf
# node_labels: File, Module, Project, Branch  (NO Method, NO Class)

# 2. Convert to LF, re-index — WORKS
sed -i 's/\r$//' proj/LearnTypeModel.cs   # CRLF -> LF
codebase-memory-mcp cli index_repository --repo-path ./proj --mode full --name ok_lf
codebase-memory-mcp cli get_architecture --project ok_lf
# node_labels: Method, Class, Field, ... ✅

Controlled experiment (single-file, isolated variables)

Same file, only one variable changed at a time:

Line endings	/// doc comments	Non-ASCII content	Result
CRLF	yes	yes (Chinese)	❌ 0 Method, 0 Class (file tree only)
LF	yes	yes (Chinese)	✅ Method=2, Class=1
CRLF	removed	yes (Chinese)	✅ Method=2, Class=1
LF	no	yes (Chinese)	✅ Method=2, Class=1

Conclusion: the bug is triggered by the CRLF + /// doc comment combination. Non-ASCII (Chinese) is not a factor — it parses fine under LF.

Whole-project impact

Indexing the full fx_testmodule project (28 .cs files, all CRLF with /// comments):

Version	nodes	edges	Method	Class
CRLF (original)	73	72	0 ❌	0
LF (converted, comments kept)	748	1540	243 ✅	48

Expected behavior

CRLF is the line-ending default for Visual Studio / Windows .NET projects. The C# parser should handle CRLF + XML doc comments identically to LF. At minimum, a parse failure should surface in skipped[] or a warning rather than silently producing a degenerate file-tree-only graph.

Workaround

Convert .cs files to LF before indexing (in a mirror copy, not the source repo). This preserves all comments and non-ASCII content while restoring full extraction.

Additional notes

• The failure is silent (skipped_count: 0, status: indexed) — hardest part of diagnosing was realizing extraction had failed at all.
• Not related to the CJK repo_path issue (Windows: tree-sitter definitions pass fails on ALL files when repo_path contains non-ASCII (CJK / Cyrillic / Arabic / accented Latin / etc.) characters #636/[Bug] v0.9.0 regression: CJK repo_path still crashes despite #636 fix #973) — repo paths here are pure ASCII; the content is what triggers it.
• A previously-suspected "non-ASCII is the root cause" conclusion (from v0.8.1 era) turned out to be a confounded experiment: the "de-Chinese'd" sample also had CRLF→LF applied, so the real variable (line endings) was masked.