Deferred from PR #1924 review.
Original reviewer comment: #1924 (comment)
Context:
function_nodes for Lua in both engines only contains "function_declaration" (crates/codegraph-core/src/ast_analysis/complexity.rs, mirrored in src/ast-analysis/rules/b3.ts's TS equivalent). This covers function f() end, local function f() end, and dotted forms like function M.foo() end.
It does not cover the common Lua module-table idiom local M = {}; M.foo = function(...) end — here the RHS is a function_definition node (an anonymous function expression), assigned via a plain assignment_statement/variable_declaration, not matched by function_nodes or by find_first_function's existing variable_declarator special-case (which is JS/TS-shaped, not Lua-shaped). Confirmed both engines agree (both are missing this), so it's not an engine-parity bug — it's a genuine coverage gap in both.
A fair portion of real Lua codebases using the M.foo = function() ... end idiom will get zero complexity data for those functions.
Why deferred: PR #1924 (which added Lua's complexity/Halstead config in the first place) already explicitly scoped out two closely-related gaps as separate follow-ups (#1922, #1923) to keep that PR narrowly focused on "Lua has zero complexity config at all." This is a third, comparable-scope gap discovered by the same review, in the same spirit — it needs either extending function_nodes with attribution logic for anonymous function expressions, or Lua-specific walk-up handling mirroring JS's variable_declarator case, in both engines.
Deferred from PR #1924 review.
Original reviewer comment: #1924 (comment)
Context:
function_nodesfor Lua in both engines only contains"function_declaration"(crates/codegraph-core/src/ast_analysis/complexity.rs, mirrored insrc/ast-analysis/rules/b3.ts's TS equivalent). This coversfunction f() end,local function f() end, and dotted forms likefunction M.foo() end.It does not cover the common Lua module-table idiom
local M = {}; M.foo = function(...) end— here the RHS is afunction_definitionnode (an anonymous function expression), assigned via a plainassignment_statement/variable_declaration, not matched byfunction_nodesor byfind_first_function's existingvariable_declaratorspecial-case (which is JS/TS-shaped, not Lua-shaped). Confirmed both engines agree (both are missing this), so it's not an engine-parity bug — it's a genuine coverage gap in both.A fair portion of real Lua codebases using the
M.foo = function() ... endidiom will get zero complexity data for those functions.Why deferred: PR #1924 (which added Lua's complexity/Halstead config in the first place) already explicitly scoped out two closely-related gaps as separate follow-ups (#1922, #1923) to keep that PR narrowly focused on "Lua has zero complexity config at all." This is a third, comparable-scope gap discovered by the same review, in the same spirit — it needs either extending
function_nodeswith attribution logic for anonymous function expressions, or Lua-specific walk-up handling mirroring JS'svariable_declaratorcase, in both engines.