Greptile Summary

The PR adds Lua Definition extraction and complexity scoping for anonymous function-expression assignments in both native and WASM engines.

• Recognizes identifier and dotted assignment targets as functions or methods.
• Adds function_definition to Lua complexity function-node rules.
• Adds parser and dual-engine integration coverage for the new behavior.

Confidence Score: 4/5

The PR is not yet safe to merge because same-line anonymous-function assignments can still persist another function's complexity, Halstead, and CFG metrics.

The new WASM Definitions use the RHS start line, while analysis results are grouped by that line and unnamed same-line function expressions fall back to the first candidate, so the previously reported incorrect metric attribution remains reachable.

Files Needing Attention: src/extractors/lua.ts and src/ast-analysis/apply-results.ts

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Lua["Lua assignment"] --> Parse["Parse function_definition"]
  Parse --> Extract["Create named Definition from LHS"]
  Parse --> Analyze["Analyze RHS complexity and CFG"]
  Extract --> Merge["Merge analysis onto Definition"]
  Analyze --> Merge
  Merge --> Persist["Persist graph metrics"]

Reviews (2): Last reviewed commit: "fix(lua): track complexity for anonymous..." | Re-trigger Greptile

Confirmed and investigated — this is a real gap, but it's pre-existing shared infrastructure, not something this PR introduces. matchResultToDef in src/ast-analysis/apply-results.ts disambiguates same-line candidates via funcNode.childForFieldName('name'), which is always null for any anonymous function node (JS arrow/function expressions included), falling back to candidates[0].

I reproduced the identical failure mode with plain JS, no Lua involved:

const a = (x) => {
  if (x) { return 1; }
  return 0;
}, b = (x) => {
  return 2;
};

b's Definition gets a's complexity (cyclomatic 2/cognitive 1 instead of the correct 1/0) today, on main, unrelated to this PR — handleVarFnAssignment sets Definition.line from the enclosing statement, not each arrow function's own line, so b's line (1) collides with a's real result.

Filed #2265 with the repro and a suggested column-aware fix, scoped as its own PR since it touches the shared matching path used by every language (not just Lua) and deserves focused review rather than scope-creeping this fix. This PR's own scope — the issue's exact repro (M.foo and f on separate lines) — is unaffected and verified with identical dual-engine numbers.

Codegraph Impact Analysis

2 functions changed → 5 callers affected across 3 files

• handleLuaAssignmentStatement in src/extractors/lua.ts:228 (4 transitive callers)
• handleLuaFunctionExprAssignment in src/extractors/lua.ts:280 (3 transitive callers)

@greptileai