Haskell: an escaped char literal followed by a primed name swallows the next definition (vendored tree-sitter-haskell)

Version

codebase-memory-mcp 0.11.0 (also 0.9.0)

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

When a top-level Haskell definition contains an escaped character literal ('\n') and the next definition's name has a prime (g'), the first definition's node extends over the second, and the second gets no node.

On pandoc (1539a541f, src/Text/Pandoc/Readers/Markdown.hs), spnl (line 159) ends with notFollowedBy (char '\n') and is followed by spnl'. The graph has spnl spanning lines 159-244. The 9 top-level functions in between have no node: spnl', indentSpaces, nonindentSpaces, skipNonindentSpaces, litChar, litBetween, litCharNoSpace, litBetweenNoSpace, inBalancedBrackets. All 11 CALLS edges out of spnl come from their bodies (lines 168-244), none from spnl's own.

Expected: one Function node per definition.

Reproduction

repro/M.hs:

module M where

f = '\n'

g' = 2

h = 3

codebase-memory-mcp cli index_repository --repo-path repro --name repro
codebase-memory-mcp cli query_graph --project repro --query "MATCH (n) WHERE n.label = 'Function' RETURN n.name, n.start_line, n.end_line ORDER BY n.start_line"

Actual: f 3-5, h 7-7. g' has no node, and f ends on g''s line. Expected: f 3-3, g' 5-5, h 7-7.

The parse tree is already wrong before extraction. With upstream's own release (tree-sitter-haskell 0.23.1 from PyPI, tree-sitter 0.25.2), without codebase-memory-mcp:

import tree_sitter as ts, tree_sitter_haskell as tsh
p = ts.Parser(ts.Language(tsh.language()))
t = p.parse(b"module M where\n\nf = '\\n'\n\ng' = 2\n\nh = 3\n")
print(t.root_node.has_error)  # True; the bind for f ends on line 5

On the grammar alone, '\t' and '\'' do the same; 'x', "\n", or another definition between f and g' do not.

THIRD_PARTY_NOTICES.md lists the vendored grammar at 7fa19f195803. Upstream's last release is v0.23.1 (2024-11-10), so a local scanner patch, as in #1232, may be the practical route.

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.