fix(perl-lsp): guard pathologically nested Perl before tree-sitter parse

A deeply nested Perl call chain f(f(f(...))) overflowed the stack while
parsing on small-stack platforms: tree-sitter's GLR parser recurses once
per nesting level in stack_node_add_link (vendored ts_runtime/src/stack.c)
merging the ambiguous parse-stack heads that Perl's f(...) grammar produces.
The overflow happens during ts_parser_parse, before any LSP walk runs, so
the CBM_LSP_PERL_MAX_WALK_DEPTH guards can never fire. This crashed
test-windows (CLANG64) with an AddressSanitizer stack-overflow and hung
test-unix (ubuntu-24.04-arm) to a 4h timeout on lsp_perl_deep_expression_no_crash.

Add cbm_source_nesting_exceeds(): an O(n) early-exit bracket-depth scan, and
skip extraction (clean has_error, zero edges) for Perl input whose nesting
exceeds CBM_PERL_MAX_PARSE_NESTING (128) before it reaches tree-sitter.
Scoped to Perl because only its ambiguous call grammar drives the GLR
recursion to the nesting depth; C/Java/Python parse the same shape with a
single stack head. 128 is ~10x above any real Perl nesting and well below
the depth where the parser overflows a 1MB stack.

Correct the lsp_perl_deep_expression_no_crash comment to describe the actual
mechanism (parser recursion, not the LSP walk).

Signed-off-by: Shane McCarron <shane.mccarron@corvexconnect.com>

Author: shanemccarron-maker

internal/cbm/cbm.c

@@ -684,6 +684,43 @@ static void cbm_test_fault_inject(const char *rel_path) {
     }
 }
 
+/* Pre-parse nesting guard for pathologically nested input. tree-sitter's GLR
+ * parser recurses once per nesting level inside stack_node_add_link
+ * (vendored ts_runtime/src/stack.c) while merging ambiguous parse-stack heads.
+ * The Perl grammar is genuinely ambiguous for `f(...)` (function call vs.
+ * bareword), so a deeply nested call chain `f(f(f(...)))` drives that recursion
+ * as deep as the nesting and overflows a small (1 MB Windows) stack *during the
+ * parse* — before any of the LSP walk-depth guards can fire. Unambiguous
+ * grammars (C/Java/Python) keep a single stack head and don't hit this, which is
+ * why only Perl crashed on the Windows/ARM CI runners.
+ *
+ * This is a workaround: the proper fix is bounding the GLR stack-merge recursion
+ * inside the vendored tree-sitter runtime, tracked upstream as #913. Remove this
+ * guard once that lands.
+ *
+ * cbm_source_nesting_exceeds scans the raw bytes for the maximum bracket-nesting
+ * depth and returns true as soon as it passes the cap (early-exit, O(n)). Real
+ * source never nests brackets this deep, so a file that does is skipped as a
+ * parse error (zero edges — graceful degradation, never a crash). Brackets in
+ * strings/comments are counted too: the only consequence of a false positive is
+ * skipping one absurd file, so string-awareness is not worth the cost. */
+#define CBM_PERL_MAX_PARSE_NESTING 128
+
+static bool cbm_source_nesting_exceeds(const char *source, int source_len, int cap) {
+    int depth = 0;
+    for (int i = 0; i < source_len; i++) {
+        char c = source[i];
+        if (c == '(' || c == '[' || c == '{') {
+            if (++depth > cap) {
+                return true;
+            }
+        } else if ((c == ')' || c == ']' || c == '}') && depth > 0) {
+            depth--;
+        }
+    }
+    return false;
+}
+
 static CBMFileResult *cbm_extract_file_impl(const char *source, int source_len,
                                             CBMLanguage language, const char *project,
                                             const char *rel_path, int64_t timeout_micros,
@@ -747,6 +784,17 @@ static CBMFileResult *cbm_extract_file_impl(const char *source, int source_len,
         return result;
     }
 
+    // Skip pathologically nested Perl before tree-sitter's recursive GLR stack
+    // merge overflows a small stack during the parse (see
+    // cbm_source_nesting_exceeds). Scoped to Perl: its ambiguous call grammar is
+    // the only one that drives that recursion to the nesting depth.
+    if (language == CBM_LANG_PERL &&
+        cbm_source_nesting_exceeds(source, source_len, CBM_PERL_MAX_PARSE_NESTING)) {
+        result->has_error = true;
+        result->error_msg = cbm_arena_strdup(a, "perl source nesting too deep; skipped");
+        return result;
+    }
+
     // Get thread-local parser (reused across files on same thread)
     TSParser *parser = get_thread_parser(ts_lang, language);
     if (!parser) {

tests/test_stack_overflow.c

@@ -513,11 +513,14 @@ TEST(lsp_python_deep_expression_no_crash) {
 }
 
 TEST(lsp_perl_deep_expression_no_crash) {
-    /* Deeply nested Perl call expressions f(f(f(...f(1)...))). The Perl AST
-     * walkers (perl_resolve_calls_in_node / perl_pass1_scan) recurse per child
-     * with no depth bound before QA round 1 — the same SIGSEGV-prone shape as
-     * the Java/C++ walkers. The CBM_LSP_PERL_MAX_WALK_DEPTH guard must cap the
-     * recursion so this does not overflow the stack. See
+    /* Deeply nested Perl call expressions f(f(f(...f(1)...))). Unlike the
+     * Java/C++ cases, the overflow here is NOT in the LSP walk — it is in
+     * tree-sitter's own GLR parser: stack_node_add_link (vendored
+     * ts_runtime/src/stack.c) recurses once per nesting level while merging the
+     * ambiguous parse-stack heads that Perl's `f(...)` grammar produces, blowing
+     * a small (1 MB Windows) stack during the parse, before any LSP walk runs.
+     * The CBM_PERL_MAX_PARSE_NESTING pre-parse guard in cbm_extract_file skips
+     * such input so it never reaches tree-sitter. See
      * lsp_java_deep_nesting_no_crash on the depth choice. */
     const int DEPTH = 30000;
     size_t sz = (size_t)DEPTH * 3 + 256;