Indexing gap: C# `{{{` fails to parse

[moshekar]

Indexing gap: C# {{{ (escaped brace + interpolation hole containing a string literal) fails to parse

Summary

In C#, an interpolated string that contains an escaped literal brace immediately
followed by an interpolation hole, where that hole contains a string literal, is
reported under parse_partial. Both ingredients are required — remove either and the
file parses cleanly.

This is the {{{ sequence: {{ is the escape for a literal {, and the third {
opens the hole. It is idiomatic whenever a string needs to render a brace-wrapped list,
e.g. $"{{{string.Join(", ", items)}}}" producing {a, b}.

I hit this on a private C# codebase (~163k lines, .NET 10). Six of the eight flagged
ranges there were this one construct, and five of those six were the same kind of
member — a property that renders a value list into braces. A minimal 9-variant repro is
attached.

Environment

Version	codebase-memory-mcp 0.10.8
OS	Windows 11 Pro 26200 (amd64)
Install	install.ps1 --skip-config, binary under %LOCALAPPDATA%\Programs
Index modes	Reproduced under both fast and full

Minimal reproduction

Smallest failing case — one line, no expression-bodied member, no comma:

public sealed class H
{
    public string Get()
    {
        var s = $@"HKLM\Some\Key\{{{string.Concat("x")}}}";
        return s;
    }
}

Reported as parse_partial, error_ranges: 8-8.

The same line with the escaped braces removed parses cleanly:

public string Source =>
    $@"HKLM\Some\Key\{string.Join(", ", Items)}";

Variant matrix

Nine single-class files, one construct each, indexed as one project. {{{ = escaped
brace followed by an interpolation hole; "nested string" = a string literal appearing
inside that hole.

File	Construct	{{{	Nested string	Result
A_SingleLine.cs	expression-bodied property, one line	yes	yes	parsed
B_Continuation.cs	same string, on a continuation line	yes	yes	parse_partial 10-10
C_ContinuationPlain.cs	continuation line, plain string	no	no	parsed
D_SingleLineNoNest.cs	one line, hole holds an indexer expression	yes	no	parsed
E_Concatenated.cs	multi-line + concatenation	yes	yes	parse_partial 11-11
F_NoComma.cs	continuation line, no comma in nested string	yes	yes	parse_partial 8-8
G_NoBraces.cs	continuation line, nested string with comma	no	yes	parsed
H_StatementSingleLine.cs	local variable, one line	yes	yes	parse_partial 8-8
I_StatementContinuation.cs	same, split across two lines	yes	yes	parse_partial 10-10

What the matrix establishes

• {{{ is necessary. G has a nested string literal and a comma inside the hole
  but no escaped brace, and parses.
• A string literal inside the hole is necessary. D has {{{ but the hole holds
  Value[^4..], and parses.
• A comma inside the nested string is not required. F uses
  string.Concat("x") and still fails.
• Line position is not the trigger. H fails on a single line; A parses on a
  single line.
• Not mode-dependent. Same five failures under fast and full.

What it does not establish

A and H carry both necessary ingredients, yet only H is flagged. I could not
isolate why. I would not read that as "A parses correctly" — parse_partial is
described as best-effort detection, so A may be mis-parsed without being detected.
Reporting it as an open question rather than fitting a rule to the pass/fail column.

Why it matters in practice

The construct is not exotic. Anywhere a string renders a brace-delimited list, {{{
is how it is written. In the codebase where I hit this, the affected members were the
ones declaring each check's data source — so graph queries about exactly those members
were silently incomplete, with no error beyond the coverage flag.

The flag itself worked well: it named the files and the line ranges, which is what made
this reducible at all.

Other flagged constructs in the same codebase, not reduced here

Observed under parse_partial in the same run. I have not minimised these and the code
is not shareable, so they may or may not be the same root cause — listing them only as
possible signal:

• A verbatim (@"...") regex literal containing quantifier braces — [0-9a-fA-F]{8},
  \{?, \}? — flagged on the declaration line.
• A positional record with generic and nullable parameter types, flagged across a
  ~200-line range, the largest single gap in the run.
• A PowerShell format-operator string, (" {0,-22} {1}" -f $_.Name, $_.Count), in a
  .ps1 file. Different grammar, so presumably unrelated, but also brace-in-string.

Attached

The 9-file repro project. All content is synthetic — no real paths, identifiers or data.

cbm-parse-repro.zip

[DeusData]

Thank you for the unusually strong variant matrix and for separating what it proves from the remaining unexplained pass case. The paired controls make this actionable without requiring access to the private repository, and the coverage flag gives us exact affected ranges.

I have routed this as a high-priority C# parsing bug and removed the Windows-only classification because the grammar path itself is cross-platform. We need more time to review whether the defect belongs to the vendored grammar, preprocessing, or parse-partial classification before proposing a fix. Thank you for keeping the additional unreduced constructs clearly out of the primary claim.